Re: [chuck-users] now v.s. actual time

On Thu, Oct 9, 2008 at 11:15 PM, Tom Lieber wrote:

On Thu, Oct 9, 2008 at 10:49 PM, Stephen Sinclair wrote:

...

On Thu, Oct 9, 2008 at 10:09 PM, Tom Lieber wrote:

...

...

In other words, if a function takes 3 ms to complete, you could make sure not to interrupt other shreds by,

while (...) { longfunction(); realnow => now; }

This would ensure that logical time advances during the computation, while not forcing you to guess the actual time that longfunction() takes to execute.

Note that none of this means changing anything in the shreduler.

That wouldn't help at all, though. ChucK has to execute longfunction() to completion (holding up every other shred during that time) before it gets to "realnow => now;".

Sorry, I meant to imply that longfunction() is a short part of a longer, iterative computation. In other words, all meant to say is, "move time along in the middle of your long computation".

Okay, that makes more sense. Still... that only helps with implementations of longfunction() that take much less than a sample on average to complete. If it's about a sample, you may as well replace it with 1::samp => now;. If it's more than a sample, it will cause underruns anyway.

That's true for the audio buffer size, not 1 sample. Usually the time to calculate an audio buffer is less than the time than to play an audio buffer, which is what allows it to synthesize sound in real time. There is always a bit of time left over after calculating the audio buffer to run a bit of chuck VM code. (In fact the ChucK VM is run after every sample, but it just means that "extra time" is interleaved into the buffer calculations.) That's why my initial example on the forum just uses 3::ms. It's generally more efficient to advance a few ::ms rather than 1 sample at a time. Kassen was suggesting that it would be better to know the actual time it takes for the code to run, instead of using a constant duration like that. Steve