[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Towards SC 4



On Nov 12, 2013 9:24 AM, "Kuivila, Ronald" <rkuivila@xxxxxxxxxxxx> wrote:
> > Oh, and hot-swapping parts of synth networks (which jitlib does) while still supporting polyphony (which jitlib doesn't, not really).
>
> Could you elaborate on the polyphony issue?

Sure. In a ProxySpace, you can plug and play bits of the synthesis graph more or less at will. Now, if you want to play an arbitrary number of copies of a ProxySpace configuration, you have to figure out the instructions that led to that state and replay them in a new ProxySpace. And I believe you'll be responsible for tracking the end of that event and releasing the structure manually.

What I'm dreaming of is a way to play patterns with overlapping synthesis events and have the option to switch around parts of the graph (as is easy, monophonically, in jitlib now), but *per event*, and as transparently to the user as playing overlapping events with a simple SynthDef. A component-ized SynthDef, if you will.

I have a custom event type that does this in a limited way for control inputs, but it's far from a general solution, a bit cumbersome, and not NRT friendly.

Or, to broaden the question, now we have a bunch of ways of working:

- The canonical SynthDef way (super-easy, ridiculously easy polyphony, but locked into fixed graph structures)

- The Ctk way (to my knowledge, doesn't try to address the problem I'm interested in)

- The jitlib way (flexible graph structures, but polyphony is not transparent to the user)

- The Instr/Patch way (polyphony support through InstrSpawner, but patchability is not as free as jitlib)

Probably others too, but these are the main ones. I'm interested in a way that takes the good stuff from each, so that it could become the new canonical way (thereby not forcing users to learn a new idiom as soon as they get sophisticated enough to want re-patchable SynthDefs).

hjh