Re: Building a Racket client for SC

> You could define modulation as control-rate by default, and send a new
synthdef only when it's necessary to promote a control to audio rate.

Yes, I think I'm gonna go with this.


> This is almost certainly `optimizeGraph` -- in it, the graph is
> optimized, but the algorithm to perform the optimization is not
> well-optimized -- I'd expect O(n ^ m) where n is the number of UGens
> and m is some figure > 1. (SynthDefs are executed in the server many
> times, but compiled infrequently, so it's a reasonable trade-off.)
>
> You could test this theory -- go to SynthDef.sc and comment out line
> 276 (`this.optimizeGraph;`).
>

I'll try that. Speaking of optimizations, there's an optimization I've
noticed is not being performed, perhaps for a reason: if we leave random
UGens aside in a different subclass, is it safe to assume two UGens with
the same name and arguments are the same?
Say I have two or twenty SinOsc.ar(300,0) as modulators to other
oscillators - is it safe to collapse them into one and just have different
input-specs refer to the same UGen?
I'm not doing any optimizations for now, just asking.

Also, I've noticed the input-specs for EnvGens are crazy. Last night I was
trying blindly, building synths with different envelopes, changing the
curves, the releaseNode, etc... and I think I can figure it out by myself,
but it would be much easier if there was a reference somewhere, like this
document was incredibly helpful when I began:
https://doc.sccode.org/Reference/Synth-Definition-File-Format.html
If not, I'll swim into the code of Rohan Drape's Scheme client to see if I
can find it.