On 24 Jul 2009, at 23:53, Stefan Blixt wrote:

I don't follow all the theory and reasoning here, so I don't know if you're suggesting something different, but I constantly make use of the exact timing in stuff like this:

fun void shred1() { while (true) { // Play note 50::ms => now; } }

fun void shred2() { while (true) { // Play note 50::ms => now; } }

spork ~ shred1(); spork ~ shred2();

With the timing model in ChucK I can depend on these to run in sync forever, and when one note is initiated the other has either been initated just before or just after.

The discussion was about how to change the timing in more fine-grains below what Chuck does. So in your example, in "Play note", you want the notes to be initiated at the exact same time. But do you need the notes to play exactly in phase, say? This would be important if you want to combine different shreds into a single sound generator, say in left and right channels. But suppose you have built your sound generator, and combined them in different music lines, or as several strings in the same note as in a piano. Then the timing of the notes on should still be exact, but not of the individual generators. So the "Play note" can "out-source" the playing of the sound of the note :-).

I don't know how SuperCollider and CSound and others work, but I feel that with another timing module based on threads, these beats would start to drift apart in a manner that would be noticeable fairly quickly (minutes or tens of minutes). Also, I can speed up sequences into audible range and back again in a reliable manner. I don't need to kludge with some synchronizing event or stuff like that. I wouldn't want this feature to be broken.

It is a good point that Chuck syncs forever, even if there is a long concert. Here is a program with a different approach http://impromptu.moso.com.au/tutorials/time.html It is a good question what happens with that model in long sessions. Perhaps there results unwanted phasing. Hans