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

[Stephen Sinclair]

On Thu, Oct 9, 2008 at 11:15 PM, Tom Lieber <lieber at princeton.edu> wrote:
> On Thu, Oct 9, 2008 at 10:49 PM, Stephen Sinclair <radarsat1 at gmail.com> wrote:
>> On Thu, Oct 9, 2008 at 10:09 PM, Tom Lieber <lieber at princeton.edu> 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