On Tue, Mar 10, 2009 at 11:49 PM, Kassen
Tom;
I'm pretty sure there being no Gain-specific functionality is all there is to it. Can you find a UGen that doesn't support "3 => u.op"? I think "Gain" is just the most generic UGen possible.
I agree.
(I should really go verify it in code, but I'm a little busy tonight.) (Same reason I haven't tried my hand at the ChucK benchmarks.) (I'll probably forget about both of these by the time I'm free, though. ;p)
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;
2 => blackhole.op; //it has a .gain() as well, there 's something Zen about that.
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 :¬).
At any rate this shows that the base-costs of adding a UGen at all are there and are quite signifficant compared to the cost a full UGen. IMHO this pleads for the "blob" project.
Or an optimizing ChucK compiler! (heh, heh, any takers?)
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.
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.
That's basically true. Even if the compiler produced machine code as fast as C, it would still issue calls to connect up UGens the same way it is done now. On the other hand, if the compiler really could generate code that fast, it would be worthwhile to implement UGens directly in ChucK. I've been playing more and more with LLVM lately, but still too early to say anything. I was messing around with the ChucK compiler previously, and found a few places to play with its opcode generator. Don't hold your breath though, as I'm way too busy on other things. :) I'd love to spend some more time with it in the summer though. Steve