<div dir="ltr">Dear list,<br><br>In this forum topic <a href="http://electro-music.com/forum/viewtopic.php?t=29358">http://electro-music.com/forum/viewtopic.php?t=29358</a> there 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.<br>
<br>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.<br>
<br>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.<br>
<br>I have no solutions to this but thought this forum topic at least gave (yielded?) a new look at the question.<br><br>For what it's worth,<br>Kas.<br></div>