[chuck-users] zipper noise

[Stephen Sinclair]

> I would be bouncing up&down with happiness if we got this but there *must*
> be some catch. For one thing the whole "pull model" for samples would have
> to be re-written and we need some sort of protection against double
> connections to single parameters.

Max/MSP and Pd handle the double-connection problem by just adding.


> "b.rate" above is probably just a single number but "my_filter.freq()" is a
> call to a more advanced function and running those, as we debated earlier in
> the topic, every sample will put a drain on the cpu and there I wonder how
> much cheaper a C++ implementation will be then a ChucK one.
>
> What we could also consider is enable the chucking of signals only to those
> member functions that cover for simple single values (with a cast to int
> where needed).

Yeah, I guess like I said it's a difficult problem to generalize.
Since the "control" loops in Chuck can go right down to the sample
level, I find the semantic difference between connecting two UGens and
explicitly programming a connection in a while{} loop is actually
somewhat of a gray area, the difference being more implementation.
For instance, the decision is usually that if you chuck, say, a SinOsc
to an LPF, what you are chucking is the audio signal.  However, you
could just as easily consider that you might want to chuck something
to freq().  With the fact that you can then use a while{} to modulate
freq() at the sample rate, you could argue that the only real
difference between these two operations is syntactic.

But of course, that's not to say that these choices are arbitrary
either... Obviously they are made to maximize efficiency.  Chucking
something at freq() would imply a great deal of extra calculations per
sample.

However, maybe the answer is simply to program some extra UGens that
allow these kinds of connections, when they are wanted.  For instance,
that is why we would not want to reprogram the STK synths using Chuck,
and would rather keep them as UGens.

I think a good solution for the zipper noise problem however, aside
from the idea of chucking to object parameters, would be to have UGens
automatically at least ramp their values, when they have been
modified, for some determined number of samples.  (Or with a certain
"inertia".)  This would greatly increase sound quality, imho.

I guess this inertia value would have to be variable, either globally
or per-UGen or per-parameter since otherwise it might interfere with
single-sample computations (since it implies a certain frequency
response), but ...

well basically what I'm saying is that it would be nice to have this
as an option to preserve sound quality without requiring the user to
run his loop at 1::samp.

Maybe one day I'll have time to look at the Chuck code and see how
difficult it would be to implement.


cheers,
Steve