I am copying this code from a you tube video , from an obviously verry talented user , which I think is user Nathan here on this forum
The only thing that I have not included is the safetylimiter ( which is an extension ) and a different out
The user is using a symbol as the first argument which I have no iead what that’s referring to .
Anyway , as expected the code does not work …
Here 's the og code
And he video in action at 06:13
\name.kr(0) is a shortcut for NamedControl.kr(\name, 0).
Personally, I do not like this shortcut syntax at all – for exactly the reason it’s being brought up in this thread: it confuses the xxxx out of users who aren’t in the in-crowd.
Readable > clever. \xyz.kr is clever (and IMO awful).
As a general rule of thumb, I’d suggest that it usually is not useful merely to say “it doesn’t work” on a tech forum. Usually it’s more useful to say “I expected x but it did y” – more specific.
NamedControl is great! And I do use it, particularly for arrayed arguments. (So I wasn’t saying that NamedControl is bad – if I did say that, I’d appreciate it being pointed out where I did. I’ll admit, however, to over-stating the case for dramatic effect – for which I’m willing to apologize.)
I was trying to say that \name.kr(default) requires explanation, and that the source of this explanation is unlikely to be obvious just from reading the code. If we take that as a hypothesis, then the beginning of this thread is evidence supporting the hypothesis: “The user is using a symbol as the first argument which I have no idea what that’s referring to.”
I’m aware of the linked thread, and I think it’s a bit of an overreach to suggest abolishing Symbol:kr as a general replacement for function argument lists to build SynthDef controls. I simply don’t agree.
It’s fine to disagree.
For another example, I also noticed in the past that many new users get confused over { |i| i * 2 } ! 10 and made it a point in my own code to write Array.fill(10, { |i| i * 2 }) instead. I fully expect a lot of users to disagree with me on that – I only maintain that Array.fill is more readable, and thus more inviting for new users. I think it’s hard to dispute that claim. It’s fine to prioritize ease of typing in one’s own code – just because I have an opinion doesn’t mean anyone else has to follow it (so likewise, the linked thread states an opinion and I’m not obligated to switch my code over, either).
For me, readability is a very high priority, so I tend to avoid shortcuts that save a few keystrokes at the expense of "what-the-heck"s down the road later.
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).
(so likewise, the linked thread states an opinion and I’m not obligated to switch my code over, either).
I like bus mapping…