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

[Kassen]

Dear list,

In this forum topic
http://electro-music.com/forum/viewtopic.php?t=29358there is some talk
about the time that a operation takes as compared to how
it affects "now". As I said there; we may want to calculate a lot of numbers
before starting synthesis (say in the case of a algorithmic score) and only
start synthesis after we have those numbers. Right now you can't. You can
tell ChucK to calculate those numbers, advance time by some amount estimated
to be about as long as our CPU takes to do that and only start synthesis (by
connecting to the dac) after that, but this will depend on a good estimate,
which will of course differ with the CPU we may be on.

Aside from this question there is the matter of how long a operation takes
in a "strongly timed" language. In the past I have -unsuccessfully- tried to
benchmark different versions of a operation  using "now". We have a lot of
ways of dealing with time, there are probably few languages that deal with
time in as much detail as ChucK does but we have no way at all of dealing
with time as registered by the clock next to the programmer.

There is a paradox here; I'd like to be able to advance time by exactly as
much time as was taken (by the cpu) since the last advancing of time; the
problem with that is that determining this might itself take quite a few CPU
cycles while this is the sort of operation we would use when trying to do
things as quickly as possible. Another question is that we can't yield to
the UGen graph if need be. A loop of just repeated yielding will stop the
Ugen calculations.

I have no solutions to this but thought this forum topic at least gave
(yielded?) a new look at the question.

For what it's worth,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20081009/eef81301/attachment.html>