SC3 is incredibly useful for scientific work that involves real-time audio processing. It would be a huge setback to ongoing academic work if a future SC4 were not compatible with SC3. Of course, sclang has its drawbacks, but the system shines in so many important ways: quick turnaround, decent speed for an interpreted language, great community, many contributed libraries, some students already know it, etc.
Here is my wish list for any upcoming version:
-
Please don’t break SC3 code in such a way that existing sclang code and UGen code cannot be automatically converted by an upgrade procedure.
-
In SynthDefs, allow functions to be evaluated on an arbitrary audio-rate trigger (on demand) instead of on every sample, maybe with a construct such as {…}.when(trigger), or OnDemand.ar(trigger, {…}); where “…” is any code allowed in a SynthDef that does not need an isochronous history, such as unops, binops, muladds, etc. On samples when there is no trigger, the function would just reiterate its latest output value, without recomputing. Why? There are many examples of processing that is event-driven, such as once per oscillatory period of the sound, especially in voice, speech and physically modelled musical instruments. This would of course increase CPU spiking, so SynthDefs using this mechanism a lot would need to be coded carefully, e.g. with several staggered triggers, but it could reduce server load by hundreds of times for those operations, running once per signal cycle rather than on every audio sample. I know that there is a small repertoire of Demand UGens, but the beauty would be for this to be a general mechanism.
-
There appears to exist a scheme for sharing of memory buffers between the local server and the sclang process, that is used in the Scope classes, but this scheme seems not to be documented anywhere. I would love to be able to use it.
best,
sternsc