On Dec 19, 2008, at 6:55 AM, Rohan Drape wrote:
An important point, and it ties back to the discussion I was having with felix about higher-level synthdef factories.
I think in this case, as in the other about noncontrol inputs, there's a very strong temptation to make SynthDef do things that perhaps SynthDef should not do. I understand why the temptation is there -- because SynthDef is by far the most commonly used abstraction for a ugen graph on the server. But the mere fact that it's commonly used doesn't make it the only, or best, abstraction for users.
JITLib allows audio patching because it's a higher-level abstraction that creates SynthDefs as part of its implementation. Instr/Patch also allows audio-rate patching... by (wait for it) creating SynthDefs as part of its implementation. Why is it a bad model, to use objects that use SynthDef for us?
I realize SynthDef is entrenched in people's minds, but in my view, it really is primarily a direct representation of a server-side construct. I'm not sure that the convenience we expect to derive from folding this new feature into SynthDef is worth the potential for confusion. That is, not only confusion in terms of implementing the requirement, but also the conceptual error of assuming that anything having to do with audio should be done in SynthDef.