[chuck-users] Time doubt...

Kassen signal.automatique at gmail.com
Wed Aug 1 08:19:09 EDT 2012


On 01/08/2012, John Gamboa <vaulttech at gmail.com> wrote:
> Hello again...
>
Hey John,

> Sorry for asking "foolishness": reading the Thesis I think I found the
> answer.

It's not "foolish", it's a important question, at the core of ChucK's
structure. It's easy to miss the "formal" answer, because the behaviour it
leads to is quite natural most of the time and makes it "just work". Let's
Have a look.

>
> (The answer, in case I wasn't alone -- please, correct me if I am wrong):
> It seems that there will just be one shred that will "win" (i.e., that will
> be the last one shreduled by the shreduler and thus the last one to change
> the variable). It seemed that the shreduler simply doesn't care with this
> case: it has a list of waiting-to-be-shreduled shreds and it shreds them
> blindly until the end. I was also surprised that it also only has as "time
> information" the number of samples passed since the beginning of the
> program (I didn't know: I was very curious about how Chuck does its
> "strongly timed magic").
>

Yes, that is correct. Only one shred runs at a time and our syntax specifies
in what way they take turns. All the above is correct, but it seems to imply
that if shred A and shred b are "shreduled" to run at the same time T then
we just get whatever. That is not true; if shred A was handed to the shreduler
first then it will also run first, in your particular case that will mean
that shred B gets to set the variable. Whether doing that in such a way is
smart is another question, of course. When no shreds are computing the UGen-
Graph gets to use the CPU.

This leads to some interesting things. You may have noted that "dur" and
"time" are double-floats (like many things in ChucK), making us able to
reason about time spans considerably shorter than the period between two clock
pulses of your CPU. That sounds silly, until we realise that we are really
talking about the order in which stuff runs, not the moment at which it does.

So; ChucK's execution order is (or should be...) deterministic at all times
and better yet; with some care in writing it will also be easily predictable
to you.


>
> Anyway... very nice! I am really excited about the language lately \o/

Great! Have fun, share results and tricks, report bugs :-)

Yours,
Kas.


More information about the chuck-users mailing list