Tom;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
</div>I'm pretty sure there being no Gain-specific functionality is all<br>
there is to it. Can you find a UGen that doesn't support "3 => u.op"?<br>
I think "Gain" is just the most generic UGen possible.<br>
</blockquote><div><br>I agree.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
(I should really go verify it in code, but I'm a little busy tonight.)<br>
(Same reason I haven't tried my hand at the ChucK benchmarks.)<br>
(I'll probably forget about both of these by the time I'm free, though. ;p)<br>
<div class="im"></div></blockquote><div><br>Well, there are UGens with no input (SndBuf, the STKInstruments...) I'm not sure what good .op() is for them but I do believe the docs claim they have it. That's not actually useful, but then again; this compiles as well;<br>
<br>2 => blackhole.op; //it has a .gain() as well, there 's something Zen about that.<br><br>While we're at it; dac has a .op as well, I found that earlier. This can indeed be used to create terrible noises after sporking a few shreds as the dac is the same across all shreds, in case you were wondering. In my experience it's best left for those situation where you were planning to end your set anyway :¬).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> At any rate this shows that the base-costs of adding a UGen at all are there<br>
> and are quite signifficant compared to the cost a full UGen. IMHO this<br>
> pleads for the "blob" project.<br>
<br>
</div>Or an optimizing ChucK compiler! (heh, heh, any takers?)<br>
<div></div></blockquote><div><br>That would mean re-compiling the whole UGen graph at any additions as we can hot-swap running UGens, I posted about that when we were talking about more advanced uses of casting. This would be a spectacularly bad idea unless we could also somehow preserve state of individual UGens to prevent glitches.<br>
<br>We may be able to have a optimising compiler but we can't (preserving current functionality) condence the UGen graph like some digital modulars do (simplifying groups of UGens internally). Well, maybe we could but even thinking about it makes my head hurt. IMHO we need more facilities for hot-swapping UGens, not less.<br>
</div></div><br>Cheers,<br>Kas.<br>