Keeping SuperCollider evolving with minimal impact on users work

My 2c on ‘users work’. scsynth has currently no way of allocating the correct memory structures for UGens, instead relying on the SynthDef sent to them. Rather than addressing this issue when thinking about extending the UGen APIs, i.e. making scsynth aware of the number of arguments and pre-filling the structure with a sensible default (e.g. zeroes, what would have to be taken into account then in UGen evolution), it’s far less work (a magnitude less work) to just quickly “patch” the system.

Current example: RandID was until now only a global setting per SynthDef; now discussion comes along, it would be nice (agreed) to be able to use multiple RandIDs; how to do it? Add another UGen argument “force” to the UGen; no problem for 99% of users because you can break the binary API if you co-evolve scsynth and sclang; 1% of users (me) will have to deal with the fact that the (different) client would now have to produce two different synth-defs depending on which version of scsynth is running. This is not to accuse anyone, just saying, this is simply how do-ocracy works.

1 Like