I’ve kept quiet because of other obligations, but feel that the class library is where I can help out the most. (However, due to time zone, and also the fact that semesters get extremely busy, I don’t anticipate joining very many calls.)
On the question of breaking compatibility: If we want to do something about the long-standing complaint of “too many ways to do things,” I suppose that a gradual approach might be best.
First, identify areas where there are “too many ways,” and decide what should be the standard way going forward. (Here, there’s a SC-community cultural problem: Often, when someone asks a question on the forum, the answer is of the form “you could do it this way, or that way, or if you also need this, then there are these other three ways,” often spread out among several responses. This cultural bias toward multiple solutions would have to shift toward “here is the standard way, highly recommended.”)
Then, document recommended approaches and make the user community aware of that. (Tricky, because, as noted elsewhere, an unknown number of SC users don’t engage with the forum at all.)
Then start chopping. I’m not sure if it would be better to do this all at once (one big set of changes for everyone), or to do it incrementally.
~~
Now, here’s a big idea.
Something I’ve thought about for a long time, but don’t have the bandwidth to develop solely by myself, is a modular DSP approach built on top of nodes and buses.
Pain points such as: For many new users, buses are confusing. Groups and node order are confusing. “I have a synth argument and I want to set it to a UGen” is confusing. “I want to swap out the oscillator in my SynthDef” is currently possible only by rewriting the entire SynthDef and trashing the old node.
We could conceive of SynthDef as just one module in a larger structure, say, a PatchDef that defines connections between modules and provides named access to some or all modules (to support hot-swapping). Currently we make a Synth from a SynthDef. Making a Patch from a PatchDef would automatically allocate buses for each connection and create nodes in the right order. When the Patch ends, buses would be released. (Probably needs a different name, because crucial library already claims Patch.)
myPatch.set(\ffreq, Module(\myLFO)) could automatically grab a control bus and map.
myPatch.setModule(\oscModule, Module(\squareOsc)) or something would hot-swap.
JITLib already does a lot of this, but AFAIK there is no way to make multiple independent instances of a ProxySpace short of re-running the code. I’m proposing Synth is to SynthDef as PatchOrSomeOtherName is to PatchDef, but there is no “ProxySpace is to ProxySpaceDef.”
The broader point is that one of the hurdles in learning SC is that users have higher-level needs, but we are addressing them using low-level abstractions that are tightly coupled to scsynth’s architecture. So every user eventually runs into these problems, and every user has to grapple with manually managing buses, node order etc. But the whole point of abstraction is so that we can talk to the machine on our terms, and let the software handle the specifics. Of course, eventually you’ll run into a situation where you have to understand the architecture anyway – but currently, users hit that barrier early. Better abstractions could push that barrier further down the road, when the user has gained more knowledge. (That is, there would be a culture shift as well. Currently SynthDefs are normal – but what if Modules and Patches were normal, and you use SynthDef directly only for special cases where there is no way other than to dig into the guts?)
I guess… take it or leave it…? I haven’t done this myself because it would require very good object design, and I’m just not good enough at software design for this (I’m aware of my limits here). I’d be willing to participate.
hjh
)