No, it’s just stated incorrectly.
You can pass any array into a function, on the client side – no problem with array passing.
The problem is that in a SynthDef, function-call passing of objects is not the right model. Looking at them as function arguments leads to misunderstanding.
In a SynthDef, there are no arguments, only control inputs, and control inputs do not behave exactly the same as function arguments.
There have been a few recommendations in this thread to create array-style control inputs using NamedControl (or its shortcut syntax, \name.kr(array)
). This recommendation is correct IMO, because it shows what is really happening, and it also supports arrays that are given as an expression, not only as a literal.
What hasn’t been clear in the thread so far is that the SynthDef builder uses SynthDef function arguments to create control inputs automatically. They look like function arguments, but they are not behaving as function arguments. The format of the control input depends on the hardcoded default value for the corresponding argument in the function. This is where the literal array requirement comes from – because it must be known that the default is an array without executing anything inside the function, and this is not possible if the default is an expression.
My suggestion is to use NamedControl for all arrayed control inputs, always, and then the literal-array distinction disappears.
f = { |x|
"x = %\n".postf(x);
};
f.([1, 2]);
// prints:
x = [ 1, 2 ];
I don’t quite see what’s non-standard about that.
if(this.isOddball) {
"I'll eat my hat"
} {
"I'll go on coding happily"
}
hjh