On 11/2/07, Stephen Sinclair wrote:
Has anyone noticed this? What measures do you take to fix it?
Hi, Steve!
It's quite normal for audio-programing languages to have a sample-rate for
audio and a rate at which modulation takes place. Modulation in that case is
slower then the audio rate in order to save CPU. Setting the two to be the
same leads to no zipper noise (but it may still cause aliasing) yet high CPU
costs. ChucK is no different, except that in ChucK the "control rate" (as
it's called in CSound) can be set depending on the context and be changed at
will (and there can be many at the same time as well).
So, in order to have no zipper noise at all you will have to set the
controll rate to 1::samp, you can use "Envelope" to do the interpolation for
you but you'll have to write the values to the actual parameter yourself.
That's where we are right now, better then many of the other languages and
systems (at least more flexible) but not quite perfect.
There was some talk on the forum about this, for example SuperCollider
interpolates such values over the size of it's block. That's relatively easy
for SC as SC uses block processing (which is cheap on the cpu) but we don't
(expensive but it pays off as soon as you want to use feedback, in that case
using blocks means hell, IMHO).
I think we could use a solution there, I think everybody does. We could
simply wait for CPU's to become so fast we don't notice such tight 1::samp
loops anymore, we could have some sort of build-in interpolation or we could
support things like
SndBuf b => dac;
Envelope e => b.rate;
Or perhaps somebody very clever will come up with something yet better.
I realize I'm not giving you a true solution but hopefully this will explain
a little about the problem? In the meantime you can try to get clever, for
example when modulating a oscillator's pitch you could make the modulation
run at the same rate as the oscillator and try to only set it at times when
it crosses the zero, that could save CPU while not zippering.
Yours,
Kas.
