[sc-dev] SynthDef variants supported now

[James McCartney <asynth@xxxxxx>]

SynthDef variants as discussed on sc-dev are working now, but not 
tested extensively.
rebuild both the client and the server or otherwise your old server 
will not understand the synthdef files that the new client writes.

d = SynthDef("vartest", {|out=0, freq=440, amp=0.2, a = 0.01, r = 1|
	Out.ar(out, SinOsc.ar(freq, 0, EnvGen.kr(Env.perc(a, r, amp), 
doneAction: 2)));
});

d.variants = (
	alpha: [a: 0.5, r: 0.5],
	beta: [a: 4, r: 0.01],
	gamma: [a: 0.01, r: 4]
);

d.load(s);


Synth("vartest");
Synth("vartest.alpha");
Synth("vartest.beta");
Synth("vartest.gamma");


> There are two possibilities when creating a library of synthdefs.
>
> A. create a few synthdefs with lots of parameters to customize the 
> sound.
>
> B. create a lot of synthdefs with some parameters hard-coded as 
> constants.
>
>
> With A, you have more flexibility but more of a burden when using the 
> synthdef, since you need to supply a lot of parameters. You need to 
> know more about each synthdef you use.
>
> With B the /s_new events can be simpler but you have to store a lot of 
> synthdefs on the server and you have less flexibility with each one 
> even though many are near duplicates of the same algorithm.
>
> Here's a way to provide the flexibility and space savings of A with 
> the simplicity of B.
>
> SynthDefs can store alternate sets of default argument values as a 
> "variant". When sending an /s_new command, the synthdef name is 
> extended by the name of a variant with a "." separating them. For 
> example "zing" might have variants "zing.soft", "zing.med", 
> "zing.harsh".
> The variants are simply different sets of defaults for the arguments, 
> so arguments can still be set to override the defaults. By specifying 
> a variant, lots of arguments needn't be sent. I hesitate to call them 
> presets, because presets are handled differently in other environments 
> (e.g. saving in separate files,  librarians, edit/store/recall, 
> distinctions between preset parameters and other kinds of parameters, 
> etc.) and I don't want that kind of complexity nor the expectations 
> brought by the connotations of the word "preset".
>
> Variants would be saved along with the SynthDef. This would require 
> incrementing the SynthDef file version to 1 so the server could parse 
> additional info.
> On the server, variants can be supported with zero additional runtime 
> overhead for starting new events.
>
> SynthDef("borp", {| freq=440, amp=0.1, bus=0, gate=1, phatnis=0.5, 
> defnis=0.2, outnis=0.7 |
> 	blah...
> },
> 	[..lags..],
> 	nil,		// prepend args
> 	(		// variants dictionary
> 		mosdef: [phatnis: 0.3, defnis: 0.9], // unspecified arguments have 
> the defaults in the ugenFunc.
> 		lophat: [phatnis: 0.1, outnis: 0.9],
> 		wayout: [outnis: 2.0]
> 	)
> );
>
> thus with the above you could call /s_new with:   "borp", 
> "borp.mosdef", "borp.lophat", "borp.wayout"