BTW, no longer needed:
hjh
1 Like
It’s usually simple to turn warnings off if you prefer (-w in both gcc and ghc, for instance).
The way the graph builder works is subtle, and it’s easy to make a mistake.
It’s a lovely analogy, function arguments as graph control nodes, but it’s not particularly simple to understand when things go awry.
The question here concerned arrays, but it needn’t’ve.
{ arg freq = 69.midicps; SinOsc.ar(freq) * 0.1 }.play // silence!
It’s possible it’d be less difficult for people who know SuperCollider well to run Preferences.noWarningsPlease, than for people who know it less well to find out why the above is an eccentric thing to write.
Ps. This one is nice too!
{ { arg freq = [440, 441]; SinOsc.ar(freq) * 0.1 } }.play // sine tones!
For that matter, James McC has said more recently that it may have been a mistake to promote function arguments to synth controls automatically.
Also for that matter, the problem didn’t exist at first because early SC versions didn’t allow expression defaults at all (for any functions) – so arg freq = 69.midicps; would have been simply disallowed in the compiler = simpler confusion to explain.
As I stated earlier, I don’t object to configurable warnings as long as they work properly. I think false-positive warnings are just as confusing as the behaviors they’re intended to address. I also think programming is just hard – it’s a noble impulse to want to make it easier but in practice, it’s very likely just shifting the confusion to another place.
hjh
The other way of looking at it is that the below are all just ordinary everyday mistakes.
{ arg freq = 69.midicps; SinOsc.ar(freq) * 0.1 }.play // silence
{ arg freq = [440, 441]; SinOsc.ar(freq) * 0.1 }.play // silence
{ arg freq = 'a symbol'; SinOsc.ar(freq) * 0.1 }.play // silence
They’re simple to make and it’s confusing for people when they make them.
It’d be helpful if the interpreter would point directly to the mistake.
It’s simple for the interpreter to do this.
The documentation can be quite concise.
People who want to avoid typing = 0 just turn the warning off, and the warning could say how to do this.
Warning: SynthDef functions require literal defaults for arguments,
either numbers or literal arrays of numbers.
To turn this warning off run: Preferences.dontWarnAboutSynthDefArguments
Writing programs is much easier than writing music, but I’m not sure that’s a reason to make it harder!
Ps. These are nice too!
{ arg freq = "a string"; SinOsc.ar(freq) * 0.1 }.play // error!?
{ arg freq = #[[2],[3]]; SinOsc.ar(freq) * 0.1 }.play // error?!
Pps. I guess the correct thing to do would be to store argument initializer expressions at FunctionDef so that the system can distinguish between Nils in the prototype frame that are from non-literal initializers, and Nils that are from there being no intializer.
Then’d you’d only warn about the former.
I wonder if this’d be quite a simple thing to add for someone who knows the interpreter well?
It’d make things like the below nicer as well.
{ arg x = 1; x }.def.argumentString == "x = 1"
{ arg x = 1.sqrt; x }.def.argumentString == "x"
Perhaps somewhere around line 3900 of lang/LangSource/PyrParseNode.cpp?
But, I don’t know how to do that, apologies.
Sure, if someone wanted to do that, I wouldn’t object. Or even just include a flag indicating that an initializer is present (the class library might not even need to know what the initializer is, only that one was given). Such a flag could be anything that isn’t a literal (since otherwise only literals are written into the prototypeFrame).
We’re kind of going in circles now – me: “I don’t want a warning that will print a lot of false positives”; rdd: “couldn’t you accept it and just turn it off?”; me: “no, I think it shouldn’t false-positive” ad nauseam. At this point, I’ve said my piece: if it doesn’t warn about unsupplied arg values, I’m totally ok with it. I’m not ok with taking shortcuts with the engineering and pushing the impact onto unsuspecting users.
hjh
Thank you, sorry that I wasn’t fast enough.
I ran into this one a few days ago.
Perhaps an optional “beginner” warning mode would have helped, but whether or not this would have prevented me from asking here, is a different question.
But I also do like the idea of updating the SynthDef help description with a beginner section of “best practices” or “potential pitfalls” (at least this is how I understood the proposal being made, apologies if I got it wrong), with things like
- recommending using
NamedControlinstead of arguments - telling why arguments in SynthDefs need to be handled with care, like in case of arrays, or why instructions don’t work in arguments
In any case, I really learned a lot in this thread, thanks again to everybody who answered!