[chuck-users] benchmarking UGens

[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.

Cheers,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090311/c5cf25a7/attachment.html>