[chuck-users] chuck posibilities at sample level

Stephen Sinclair radarsat1 at gmail.com
Tue Jan 4 12:57:00 EST 2011

On Tue, Jan 4, 2011 at 5:18 AM, ronni montoya <ronni.montoya at gmail.com> wrote:
> hi, what does it means sample accuracy in chuck?
> In other programming languages for synthesis as supercollider and pd
> you can change the default block size from 64 to 1.
> In that way you can make operations per sample.
> wouldnt be this the same as chuck "sample accuracy"?
> or which are the different between this?

You're using "sample accuracy" to mean "per-sample computation".  But
sample accuracy really means that you can specify that events should
occur at specific times, precisely down to the sample number at which
it should occur.

> other question, what do you mean with sub-sample?

So in terms of my above description, you can specify that events
should occur at partial sample times.  Like, "trigger a pulse at
sample 500.55."  Except that in ChucK you don't have to deal with
scripting events as such, you just "wait" until the correct time
passes and then do something.

So in SC, the client would send a message ahead of time to the server
saying, "do this at time T".  (The client then waits in "logical
time", but the server continues to process audio.)

In ChucK, the program (which is called directly by the audio renderer)
says "wait until time T; do this."

In both cases, T can be precise enough to specify a particular sample
number, or even smaller.

A major difference is that in SC, if something gets in the way of the
server being able to wake up at time T, so that it only gets to doing
"this" at time X, then the event will be delayed by time X-T.

In ChucK, the audio renderer steps through samples one at a time
watching for bits of program that need to run.  When it gets to T, it
will wake up the program and do "this".  If "this" takes a long time,
audio processing will be delayed, leading to glitches.  It's the
programmer's responsibility to make sure this doesn't happen.

So both SC and ChucK are sample accurate because ChucK runs exactly at
the correct time, and SC uses timestamps to ensure that events are

In a hypothetical language like SC that didn't support timestamps,
events would occur as soon as messages are received and it would be
entirely up to the client to determine timing.  Since the client isn't
clocked to the audio rate, and since it has no control over the
latency for messaging, it would not be called "sample accurate".

> Is is possible to make sub-sample operations , never heard of that, is
> there any examples on this?

If you have code that says something like:

"wait 0.5 samples; do X; wait 0.5 samples; do Y"

then in reality only one sample will be updated.  However logically
the program works with sub-sample accuracy, and the audio routine is
basically down-sampling it.

In SC and PureData there is a concept of 'real time' and 'logical
time'.  Real time passes as the audio buffer needs to be fed.  Logical
time is the time used to update variables and whatnot that affect
audio rendering, and it passes conceptually asynchronously to the
audio clock rate.

When you set Pd's block size to 1, you are sort of setting logical
time to the same as the audio rate.  (Because logical timesteps are
usually executed between audio vectors.)  The sort of special thing
about ChucK is that logical time can be faster than the audio clock if
you wish, and it guarantees that everything that needs to be done
before the next sample is processed will be done.

$ cat test.ck
0.5::samp => now;
0.5::samp => now;

$ chuck ~/test.ck
0.500000 :(time)
1.000000 :(time)

A neat thing that I was trying to point out is that just because you
can do things every sample doesn't mean you have to.  The following is
also "sub-sample accurate", but has nothing to do with per-sample

$ cat test2.ck
100.55::samp => now;

$ chuck ~/test2.ck
0.000000 :(time)
100.550000 :(time)


More information about the chuck-users mailing list