[chuck-users] benchmarking UGens
signal.automatique at gmail.com
Tue Mar 10 13:39:35 EDT 2009
Also, recommended reading:
> If you skip the first half, there's actual information down below.
Yes. The first half implies being tall should lead to less problems with
women. At 2 meters I must count as "tall" and I didn't find this at all.
It does get interesting and relevant right after that though (and as
opinionated as it is; it's quite pleasant to read). Fortunately we are quite
safe from one of the major complications; optimisation. If ChucK would have
a optimising compiler, for example, we'd be in serious trouble.
As for Gain & Pan2; you are quite right. Here we could say that Gain is
more or less like the "base cost" of all UGens. Still; a modest little Gain
is capable of adding, multiplying and so on. Clearly Pan2 needs it's own
code but it's not clear to me yet why that code has to be so much more
expensive than just two Gains. One explanation would be that the base cost
of a Gain doesn't account for everything; a Gain set to multiply might be
more expensive than a plain one or maybe stereo adds cost. I suspect there
are hidden issues that we haven't evaluated yet.
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. For example a crossfader is a device that we
could quite easily make ourselves out of other UGens, so is a clipper and a
state-variable filter (the list goes on) but this table already shows us
that desipite these being possible to create already there would be
signifficant benefits to increasing our range of available low-level
building blocks. This should in turn cut down on the costs of implementing
more advanced/ interesting synthesis techniques in ChucK.
Oh, and SndBuf is very cheap indeed, far cheaper than I thought it was,
that's nice to know.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users