[chuck-users] zipper noise

[Kassen]

On 11/3/07, Stephen Sinclair <radarsat1 at gmail.com> wrote:

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


That would, I think, be a case where ChucK's dynamic control-rate could
indeed yield savings.
I'm not so sure interpolation would help with swwps either, if we have two
sets of coefficients that both yield a stable filter I'm not so sure we can
interpolate from one set to the other and assume all of the stages in
between will be stable as well.

The only real solutions there (as I see it) would be more "readymade"
(perhaps importable and user constructible?) filters like LPF and so on
where you can just set a frequency and have the C++ code deal with it or a
lot of optimization in ChucK itself. If you want a sweeping filter those
calculations will need to be done *somewhere* every sample in any case.



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



Yes, indeed, and anything that can be re-expressed as sums and
multiplications can be dealt with by a clever network of Gain ugens.

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



I wonder how bad something like the


SndBuf b => dac;
Envelope e => b.rate;

example I gave would be for the CPU. theoretically it shouldn't be that bad
as we have e.last() in the system anyway and the SndBuf would need to take
it's rate into account every sample as well so perhaps some sort of
asignment between the two could be used to get this effect "for free". This
would of course run into unpredictable issues if somebody were to chuck
multiple Ugens to a single parameter.... In that sense it's a lot less clean
then what we have but it would be very powerful indeed.

This would be one of those issues where I'm quite happy we have Ge to think
of consistent solutions :¬)


Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20071103/23c9fc26/attachment.htm