Stephen;
>>> 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.
I agree. We need to keep in mind that all of the "now", advancing time and
concurrency syntax is just about the order in which things get executed by a
single CPU. it's not some magical well of CPU power; it all depends on
"having steam to spare". What we are actually pretending to define, having
operations that -themselves take no time at all, is impossible, the whole
illusion depends on this buffer and indeed it's a very pleasant illusion.
In a way you could say that what we are after here is a method of dealing
with the reality that's below this illusion, the reality of finite
resources, in a way that's still syntactically coherent with the rest. I'm
not even sure this is possible because of factors like the fact that
figuring out how much CPU time a certain operation takes also takes CPU
time.
There is a conflict between how ChucK will never let go of "now" and how
we'd ideally prefer audio not to break up. When something has to give (like
when we tell ChucK we instantly want to know ten million square roots) it's
the audio that gives. It's possible to yield to other shreds, and if you do
the shreds will take just what they need and give the CPU back, this is
clearly different from advancing time. I suppose that what I'm looking for
is a way to yield to the Ugen graph,( which is the strongest link between
ChucK's time and the stuff on my clock), give it the CPU to calculate what
it needs to calculate (which may well be nothing right now), then give me
the CPU back.
Maybe this is going too far; this structure would max out the CPU with some
percentage for the Ugens and all of the rest (and no more) for our shred.
That would mean that if the OS would like to do anything at all (and modern
OS's do...) we're in unhealthy teritory. Perhaps we're simply fantasising
about the impossible.
Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20081010/80a61a72/attachment.htm>