SuperCollider 4: First Thoughts

[scztt]

@sternsc

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.

Check out the Demand UGen, and the rest of the demand rate UGens - these are even based, and can be driven by audio-rate triggers. This might be a solution for what you’re describing.

@sternsc

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.

@andie

Idea: SynthDefs can “call” other SynthDefs.
Why: code re-use, composability.
Implementation strategy: sclang macros. we’re not calling one bytecode synthdef from another, we’re basically just pasting in the sclang code from the first synthdef when we’re generating the bytecode for the second.

See SynthDef:wrap, which is probably the best-supported way of composing functions together into a single SynthDef. FWIW a compiled SynthDef (e.g. what you get when you do SynthDef(\foo, {}) loses some high-level information about its overall structure - this makes it not ideal / impossible to properly compose inside another SynthDef. The best thing to is write and store SynthDef “components” as functions and call them via wrap or e.g. ~filterModule.value(input, freq).

@andie

Idea: SynthDefs can take an Env as an input.

This is possible now. Envelope passing for Synths and Patterns