Removing the spaces inadvertently changed the way it parses.
Another opinion: Many users, particularly new users, I guess wish to save some typing by deleting as much white space as possible. I find that it hurts readability to have a large mass of undifferentiated characters (I strongly dislike reading such code) – and as you found here, spaces are sometimes syntactically significant.
The shortcut is also fine. It is documented and its usage is sufficiently widespread. The alternatives are to write out NamedControl.kr(\freq, 440), which is absurdly verbose for the amount SynthDef arguments are used, or to use the argument style, which has serious problems when it comes to specification of rate.
Again, agree to disagree. It’s documented, but, “I have no idea what that’s referring to.” I guess the solution to that is an RFC to change the synth control style throughout the help system.
I did this with my live coding system loaded (actually missing one file, but close enough):
Arrayed controls clock in at 12/1465 < 1%, and scalar rate at 22/1465 ~= 1.5% scalar. It’s hard to count tr controls this way but I don’t use them frequently. Perhaps that’s why I don’t mind to write out NamedControl in the 0.8% cases of arrayed controls (where there’s really no good other way) or the couple percent other cases.
For the majority of cases, it’s a nice optimization that function args collapse into one Control unit.
If efficiency is a concern, ir controls are significantly better (these require NamedControl). The peak cpu of this is 0.5%, where your other two examples peaked at 18% and 42% for me:
SynthDef(\namedControlsIr, {
var ctl = \ctl.ir((0..100));
Out.kr(0, ctl.sum.poll);
}).add;
Somewhat unrelated but - for what it’s worth, I’m not totally sure what you’re doing with sending an array to a non-array control is valid? Setting a single control, ctl0, with an array works only because the server blindly writes all the data from that array into memory without looking at where it’s writing. It happens to be the case that the synth args are ordered in memory like ctl0, ctl1, ctl2, … etc, but I DON’T think this is guaranteed to be the case - probably this would be considered undefined behavior that just happens to work right now.
Overwriting the bounds of controls like this can cause subtle and very nasty bugs (and IIRC crashes as well) so to be honest scsynth and supernova should probably have checks in place to make sure this doesn’t occur.
I’m using the DSP CPU testing methodology of creating the same number of a lot of something, and measuring CPU for those.
My test 1: 250 independently-named single-value controls, created in a single Control unit, x 101 synths = 101 Control units, 25250 active controls.
My test 2: 250 independently-named single-value controls, each with its own dedicated Control unit, x 101 synths = 25250 Control units, 25250 active controls.
… and found from this test that the overhead of entering and exiting 25149 additional Control_next() functions is not exactly trivial.
To compare ir, you would need two tests: test 1 architecture, and test 2 architecture, just changing the rates.
(Actually, as I was doing that, I found a mistake in the oneControl synth – it should be .kr((1..250)) – fixing this mistake reduces CPU for test 1 to about 6%! So the margin is even larger than I thought at first.)
kr
Test 1 (fixed) = 6%
Test 2 = 18%
ir
Test 1 = 0.2% (probably within margin of error?)
Test 2 = 0.2%
I can’t find the bit in the code that’s responsible for this, but I’d have to guess that scalar-rate controls simply don’t call the nextfunc at all. In that case, it wouldn’t matter how many there are.
But “make all your controls ir” isn’t really a solution, is it? I like bus mapping…
Not true – arg i_out is used in many places in the class library. Also the construction in my test 1 is valid to create ir controls as well. (IIRC Control.names(array_of_symbols).kr(array_of_defaults) is how the function’s argument list is converted into Control channels – it is a valid usage, though not common, and not particularly user-friendly, which is why NamedControl was introduced.)
James, would you mind explaining what is actually happening here versus with the NamedControl?
Is it that an array inside of NamedControl ends up returning a Control unit per each element within an array, versus when using an array inside of an argument, Control encapsulates the entire array within one Control unit?
I use NamedControls everywhere, and really like them. I even tend to declare most of them toward the top, where I’d normally use args. One of the subtle things I appreciate is the IDE’s syntax highlighter doesn’t recognize args as such, but symbols pop right out for me.
But I also use a lot of arrays within them. And like making efficiency mods. The CPU difference is striking here!
So it seems like it’s the naming that’s preventing them from being bundled? Which is odd, because it seems like in Control’s source code, they’re being associated with a name, anyway…?
Another thing that I noticed:
(
SynthDef(ugenGraphFunc: {
Out.ar('bus'.kr, SinOsc.ar('freq'.kr(440), 'phase'.kr) * 'amp'.kr(0.1))
}).children
)
// -> [ a Control, a Control, a Control, a SinOsc, a Control, a BinaryOpUGen, an Out ]
(
SynthDef(ugenGraphFunc: {
Out.ar('bus'.kr, SinOsc.ar('freq'.kr(440), 'phase'.kr) * 'amp'.kr(0.1))
}).children[0].values
)
// -> [ 0.0, 440, 0.0, 0.1 ]
(
SynthDef(ugenGraphFunc: {
Out.ar('bus'.kr, SinOsc.ar('freq'.kr(440), 'phase'.kr) * 'amp'.kr(0.1))
}).children[1].values
)
// -> [ 440 ]
So it seems like the first Control bundles them up anyway?
First, it would be helpful to understand the purpose of the test.
I wanted to demonstrate the performance difference between a single Control unit with a large number of channels, and a large number of single-channel Controls.
Note at this point that there is no need to consider arrayed arguments for this. In fact, it would be bad to use arrayed arguments here. A good test eliminates unnecessary variation in the cases. If I want to measure the above-stated performance difference, then I want everything to be the same except for the Control structure: same number of controls, same names etc. So I do not want non-arrayed Control vs arrayed NamedControl, or vice versa.
(
e = SynthDef(\oneControl, {
var ctl = Control.names(Array.fill(250, { |i| ("ctl" ++ i).asSymbol }))
.kr((1..250)); // fixed the earlier mistake
Out.kr(0, ctl[0]);
}).add;
)
… which is exactly the same. We can prove that:
d.asBytes == e.asBytes
-> true
This demonstrates that function arguments in a SynthDef will be collapsed down to the smallest number of Control UGens. That’s all.
For \namedControls, I could have written:
(
SynthDef(\namedControls, {
var ctl0 = \ctl0.kr(1);
var ctl1 = \ctl1.kr(2);
var ctl2 = \ctl2.kr(3);
var ctl3 = \ctl3.kr(4);
var ctl4 = \ctl4.kr(5);
var ctl5 = \ctl5.kr(6);
var ctl6 = \ctl6.kr(7);
var ctl7 = \ctl7.kr(8);
var ctl8 = \ctl8.kr(9);
var ctl9 = \ctl9.kr(10);
// ... OK, here I won't be 250-lines level of pedantic
// ... snipped
var ctl245 = \ctl245.kr(246);
var ctl246 = \ctl246.kr(247);
var ctl247 = \ctl247.kr(248);
var ctl248 = \ctl248.kr(249);
var ctl249 = \ctl249.kr(250);
Out.kr(0, ctl0);
}).add;
)
Instead, I constructed the identical NamedControl structure in a loop.
The coding style in that test was simply because, why should I post 300+ lines of repetitive declarations, when I can do it in about 15 lines?
Anyway, NamedControl produces one Control UGen per NamedControl object. An arrayed control has one name, one NamedControl, and multiple values. So, no, the array will not be split out into multiple Controls.
Oopsy, five controls were declared but this array has only four values.
That means this array is not reliable for anything (i.e. “the first Control bundles them up anyway?” = no).
When an array stops at size 4, usually that means something is .add-ing to it without reassigning the result back into the variable. I can’t find where in the code this is happening, and I don’t know why this is being done only for the first Control to be created. It does look a bit like unintentional behavior, though.
I suspect this is likely to be trickier than one might expect.
Because Control outputs will be used in many, many other units’ inputs, you would need to take each of these OutputProxy objects and mutate them so that they belong to a single Control. (It’s too risky to try to make new OutputProxies and substitute them in other units’ inputs.) I suppose it’s possible, but mutating the graph after the fact… I would expect pitfalls. Probably all of the problems could be solved though.
Note that the function-argument “collapse to one” happens before the function is evaluated, so in that case, there is no need to mutate anything afterward.
In my post above, when I explicitly called Control to create arguments, instead of using function-arguments, the results are similar to using NamedControls: They did not collapse down into a single Control unit. In your example, this worked out a bit differently.
These all did collapse down into one -
Actually, I’m a bit surprised by this…
Is there anything preventing from it being possible to allow for this behavior for NamedControls?
Looking through the source code, it seems like Control.names can/does process names as an array, thus is able to collapse them down into one, like your earlier example.
NamedControl has a name method instead, which works with only a single entity.
If you do SinOsc.kr 4 times, you would expect 4 SinOsc units in the SynthDef.
It’s actually the same for Control: you have an example which called kr on Control 4 times, and you got 4 Control units. My example calls Control...stuff...kr once, and it produces one Control unit.
Control itself does nothing to collapse them. It allows you to prepare the names and values in a way that can handle multiple differently-named controls within one Control unit. But it is up to you to prepare it that way.
For function arguments, the preparation happens before even calling into the function.
In my opinion, it may be solvable, but difficult.
Understand the process first. The SynthDef builder reads the function arguments and groups them by rate and lag, clumping similar inputs together. Then it makes a UGen for each group, and parcels out these units’ OutputProxy channels into the function’s argument list. (Inside the function, every argument will receive either an OutputProxy or an array of OutputProxies.)
The key here is that these Control / AudioControl / TrigControl / LagControl objects are constructed before function evaluation, and these objects do not change during function evaluation.
To collapse NamedControls – this would be working with objects that are created during function evaluation, not before. So there is no way to prepare static objects in advance. There are only two ways to fold the second NamedControl into the first:
At the moment of creating the second one, go back and find the first, and mutate its data structure to contain two channels with different names. (Then the third would do this again, and so on.)
Or, during SynthDef post-processing, analyze the NamedControl collection and replace the individual units with a smaller number of units. (IMO this may be riskier – it would touch not only the Controls but perhaps most other units’ index etc.)
Mutating UGens isn’t impossible – the math operator optimizations do this, on a small scale – but it is a bit delicate and the code would need to be tested carefully. Every time a UGen’s internals are modified after it’s already integrated into the graph is another source of risk.
Note that SynthDef.wrap also creates additional Control units, instead of folding the new ones in with the old ones. That’s James McCartney’s code, and he didn’t want to tackle the problem of after-the-fact UGen manipulation. This is probably why NamedControl just says “yikes, that’s too hard (and besides, it’s not 1996 anymore, we don’t have to worry about CPU so much)” and goes with the less efficient option.
It would be nice if someone tackled this. It won’t be me, though (since I’m mainly satisfied with function arguments).
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 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.krwithout telling other people that their way is too old-school, but that thread doesn’t quite avoid the temptation.
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:
that the i_/a_/t_ prefixes are ugly
that the i_/a_/t_ prefixes can be invoked by accident
that the rates: parameter of SynthDef splits the specification of arguments in two places
that literal arrays in SynthDef arguments require repetitive code
that trying to avoid repetitive code with something like freqs = (440 ! 8) leads to silent unexpected behavior
Aside 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.
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.
I like bus mapping…