nwhetsell
commented
7 years ago I agree that something like this would be beneficial, but one issue that may arise — and I may be mistaken about this — is that while names of opcode arguments are documented in the manual, opcode arguments don’t really have names under the hood. Implementing this may entail adding names of arguments to all opcodes so that Csound would know something was amiss with, say
asig = mincer(atime, kamp, table: ktab, pitch: kpitch, BAD_ARGUMENT_NAME: 2048)Also — and this is a bit of a corner case — there may be some grammar ambiguities here because line breaks are permitted after commas. So, if written this way
asig = mincer(atime, kamp,
table: ktab, pitch: kpitch, fftsize: 2048)table: would be treated as a label (for a goto statement). Now, one could have a rule that you can’t have labels in parentheses like that, but if written this way
asig mincer atime, kamp,
table: ktab, pitch: kpitch, fftsize: 2048you’d have the same problem. That might still be fixed by paying attention to trailing commas, but the point is that this would have far-reaching effects.
gesellkammer
jpffitch
vlazzarini
berntisak
joachimheintz
stekyne
I know that this subject has been brought up before, but I would like to insist: how difficult would it be to add named arguments to csound (maybe csound 7?), so that something like the following would be possible?
Right now we rely on the name of the variables or on comments to understand what is happening.
This would make code much clearer and readable and would make debugging easier. It could even be optional and would work only for opcodes which define names for their arguments.
Opcodes with a great number of inputs would benefit from this greatly. In such cases, when the user needs to set a value for one of these arguments, all arguments which come before must also be defined.