[chuck-users] chuck posibilities at sample level

[Stephen Sinclair]

2010/12/30 Kassen <signal.automatique at gmail.com>:
> Hi, Ronni!
>
> On 30 December 2010 08:28, ronni montoya <ronni.montoya at gmail.com> 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