[chuck-users] zipper noise

[Stephen Sinclair]

Hi,

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

Yup, I understand a lot of the issues involved.  The problem comes in
when for example trying to compute filter coefficients, it's not
something that is really wanted at every sample.

On the other hand a possible part-solution might be to have it
re-calculate the coefficients only while the value (e.g., cutoff) is
actually "sliding"..

Anyways, I know that this is not an easy thing to answer, and in a lot
of cases will depend on the particular UGen and so is difficult to
generalize.  I'd think though that enveloping less demanding values
(FM parameters, for example) should be possible..

I dunno, anyways I thought I'd toss the idea out there.  The reason I
guess it seems to be a bit of a problem with Chuck specifically is
that you tend to want to abuse the sample-accuracy of it by doing
things like frequency modulation or LFO-based effects in a simple
while{}.  But when you actually drop down to 1::samp, the CPU really
starts spiking.  I guess maybe the answer is to just build that kind
of thing into a UGen, but it sort of defeats the idea of doing nice
effects quickly using =>.

Steve


But then when you do this in Chuck code instead of building it into a
UGen, you get