I wanted to come back to this thread to apologize for my tone. I took James’ comment personally because I consider Symbol:kr etc. to be valid and such criticism of my code to be unfair. Still, that was no excuse to fly off the handle and leave some comments that I really shouldn’t have.
There is already too much macho posturing in other music tech Internet communities and I regret bringing that here. I’m sorry to this community for my behavior, and particularly to @jamshark70.
I want to express my appreciation, Nathan. This is an excellent example of how we all can watch our tone and be better. Thanks.
/*
Josh Parmenter
www.realizedsound.net/josh
*/
Hi Nathan,
Thanks for this – I do appreciate the gesture.
I should also apologize for overstating my case. “Clever” is not such a terrible assessment, but “awful” was uncalled for.
Here, I will admit that I still carry some bad feelings from the original “NamedControl: better way” thread. My poor choice of words is largely because I don’t feel that my disagreement with that thread has been heard (which wasn’t a good way to handle that, just explaining where it came from).
It would have been accurate to say that SynthDef function args have certain advantages and disadvantages, and that NamedControl / \symbol.kr has different advantages and disadvantages, and that it’s up to the user to decide on balance which of those they prefer.
I can understand that you were excited about the advantages and trying to convince users to swim against the current of a coding pattern found everywhere in the documentation. Both of those could lead you to overstate the case (which I understand, as I did the same thing). Both of those also mean – be honest! – that the purpose of the thread was partly polemical. Polemics are IMO not quite productive here.
I think it would be helpful to rewrite the earlier post to be more fair. Basically… from this last comment, you’re showing that you understand what it feels like when someone comes for a way of doing things that you like very much. That’s exactly how I feel about “NamedControl: better way.” I know you weren’t deliberately doing that, but – sorry, I should let it go, but – it still bothers me. It’s certainly possible to advocate for \symbol.kr without telling other people that their way is too old-school, but that thread doesn’t quite avoid the temptation.
hjh
I’m no longer able to edit old posts from years ago.
I wouldn’t have edited the post anyway. From what I understand, you dislike my mini-article because in addition to arguing for NamedControls/Symbol:kr, I denigrated the argument style. My points were very specific, by identifying what I believe to be important problems with the argument style:
freqs = (440 ! 8) leads to silent unexpected behaviorAside from 1, these all seem like fairly objective descriptions of real design problems to me. Maybe you have counter-arguments or simply think they aren’t major issues, and if so I’d be happy to hear you out and healthily debate these points. But I simply don’t see where you’re getting “polemics” and “telling other people that their way is too old school” (I never said such a thing).
I fully agree that symbol.kr is better in several cases, and that for some users, it may even be generally better.
For the sake of public record, I’d like to redact some of the comments that had been in this space. I stand by my assertion that the article has an agenda beyond technical analysis, but the way I discussed that earlier wasn’t helpful. I apologize (again) for that.
As for the use cases: I do actually use NamedControl when it’s clearer (especially for arrayed controls). I have not adopted symbol.kr, and I won’t, because I’ve come over the years to feel that readability is more important than less typing (and I’ve had an RSI for 3 decades, if anyone should be looking to cut down on keystrokes, it’s me – but after years of trying to write as syntactically tight code as possible, I ended up preferring to slow down, write things out step by step, use keywords such as NamedControl – yep, spelling it out! – where appropriate to highlight what is really happening). Rate prefixes, I find aesthetically neutral; the prospect of abusing them accidentally is a valid point (yet somehow has never happened to me in a couple decades).
I had considered at one point writing a preprocessor to unify SynthDef input description, but ran out of time and didn’t get very far… so I do recognize that SynthDef function arguments are not an end-all be-all solution. But I like them for standard kr, non-arrayed controls, which (at least in my typical usage) counts for a large majority of synth inputs. As such I see no need to change it just because another style supports features that I’m not using.
hjh
I personally loved @nathan’s legendary thread on NamedControl: a better way to write SynthDef arguments… to date it’s the top thread of ALL TIME!
I’ve only used NamedControls since the day I read it.
While they certainly add a touch of mystery to the uninitiated… for them a var is far less distracting & wizardly at a glance.
If they ever need a solid primer to understand the genius of using them, @nathan’s article is the definitive source, just send them there.
However, at the same time I couldn’t agree with @jamshark70 more… early users come here for education, not to be mesmerized by the esoteric & enigmatic.