Keeping SuperCollider evolving with minimal impact on users work

Development
73

Ugens do know the size of their inputs and outputs (numInputs and numOutputs). It is therefore possible to add new (optional) UGen inputs; the UGen only needs to check the number of inputs, just as in your example above.

74

FWIW, I was unable to crash it by mismatching scsyndef and plugin versions.

  1. Using the develop branch, create a synthdef:
    (
SynthDef(\randID, {
	RandID.kr(1);
	Out.ar(0, PinkNoise.ar)
}).writeDefFile;
)
  2. Switch to topic/MultipleRandIDs, make, sudo make install.
  3. Relaunch SC, boot the server – no crash during GraphDef loading.
  4. x = Synth(\randID); – no crash.

^^ That is using new RandID plug-in code, which expects two inputs, with a SynthDef produced by the old library code, providing one input. x.trace shows just one input. I don’t have time at the moment to doublecheck the ZIN, ZIN0 macro set, but this test does suggest that ZIN0(1) isn’t guaranteed to crash when there is no input 1 – which is a significant finding because the question seems to assume that it will necessarily crash. (Perhaps it would have crashed at some point in the past.)

I also tried the other direction – using the topic branch:

(
SynthDef(\randID2, {
	RandID.kr(1, 0);
	Out.ar(0, PinkNoise.ar)
}).writeDefFile;
)

Then switch back to develop, rebuild, reinstall, and run the synth. Again, no crash. (In this case, the struct for RandID would be defined without enough space for the second input that exists in the SynthDef.)

So it would be worth investigating: Has the code changed to handle this situation more safely? Because I can’t reproduce the problem in this case. (Or, maybe it’s fine for control rate inputs but mismatched audio rate inputs might crash.)

hjh