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

Re: [sc-dev] Re: Some 3.3 work

On Dec 19, 2008, at 6:55 AM, Rohan Drape wrote:

On 2008-12-19, Click Nilson wrote:
Perhaps what you actually want is a psuedo-UGen, modules of class =20
code to easily plug into new SynthDefs?

Which can be done already, it just requires managing some meta-data
about unit generator graphs and a naming convention for the bus number
parameters.  Isn't this in fact what jitlib already does?

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.


: H. James Harkins

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman