2010/12/30 Kassen :

Hi, Ronni!

On 30 December 2010 08:28, ronni montoya wrote:

...

Hi, im new in this list,  i was using supercollider before, somebody told me about something about  the posibilities of chuck for making sample level operations. Can anybody explain me about this?

That's a bit of a big topic, because there are of course many things we might like to do to samples. I also believe (not offering proof) that we can do all of those in ChucK. Not all of those will be efficient or practical but they should work deterministically. The easiest way of seeing this is probably looking at the Step and Impulse UGens, which allow us to set the value of a sample in the audio chain using code. If you match that with loop running at a rate of 1::samp you can generate any signal.

I think this is probably what he means by "sample level operations", but another interpretation could be just to talk about the fact that ChucK allows sample *accuracy*. This is pretty interesting in itself, the fact that in ChucK you can time things to the sample (or sub-sample if you're talking in microseconds), instead of control signals being asynchronous. SuperCollider allows this through timestamps in its control signals, of course. ChucK allows you to specify guaranteed sample accuracy, at the expense of real-timeness guarantees. SC will continue performing the signal processing routines even if it doesn't get the control messages fast enough--they will simply be delivered late, whereas ChucK's semantics _require_ all processing to finish before final samples are generated for the DAC. There are advantages and disadvantages in both cases. Steve

2011/1/3 Kassen opined:

In SC you know the sound will stay coherent for longer, in CK you can recover from such issues [...snip...]

One thing I really appreciate about ChucK is its ability to drop out of real time gracefully to render arbitrarily complex, sample-accurate data to a sound file. (Of course, SC may offer this as well, but I got imprinted with ChucK first.) - rdp

On Tue, Jan 4, 2011 at 5:18 AM, ronni montoya 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 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

Rob;

As an aside: which version of ChucK are you using? I ask because I've been bitten by a bug (documented in the archives) where the event mechanism appears to truncate sub-sample times to an integer sample. I'm wondering if that's been fixed.

I believe that bug is still in there. BTW, I also believe that "sample accurate" could be seen to mean both interpretations that Stephen gave; I think both are valid and ChucK supports both. By that I mean ChucK's specs do, as Rob rightly points out there are issues with that in practice in the form of this bug. Yours, Kas.