On Tue, Jan 4, 2011 at 5:18 AM, ronni montoya
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 well-timed. 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; <<<now>>>; 0.5::samp => now; <<<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 processing: $ cat test2.ck <<<now>>>; 100.55::samp => now; <<<now>>>; $ chuck ~/test2.ck 0.000000 :(time) 100.550000 :(time) Steve