[chuck-users] UGen v.s. code in timing; very tricky

Kassen signal.automatique at gmail.com
Wed Sep 17 19:14:10 EDT 2008


Dear list.

Suppose we have a SinOsc named "s", connected to the dac,  that has been
playing for some arbitrary amount of time at a arbitrary frequency. Suppose
we'd like to disconnect this from the dac while minimising the "click".

One thing to try would be this;

(1 - s.phase() )::s.period() => now; //strong timing to the rescue!
s =< dac;

Quite ChucKian, I thought, however this still clicks a bit. Some clickery is
to be expected as not all frequencies will have a period that can be
expressed in a integer number of samp's but this seemed like a bit much.

On a whim I tried;

(1 - s.phase() )::s.period() + samp => now;
s =< dac;

This clicks less and when I print the s.last(), the value is on -average-
lower in magnitude. I then tried lining up the shred's timing with the UGen
graph's;

samp - (now % samp) => now; //yes; that's quite anal
(1 - s.phase() )::s.period()  => now;
s =< dac;

This doesn't affect matters quite as much as simply adding a samp to the
time advanced; waiting a extra sample generally seems (to me) to decrease
the magnitude of the s.last() right before we disconnect it.

This would lead us to ask; "where does this samp come from?". I'm a bit at
loss here, does anybody have any insights?

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080918/f4792985/attachment.html>


More information about the chuck-users mailing list