[chuck-users] now v.s. actual time
afterthebeep at gmail.com
Thu Oct 9 22:25:44 EDT 2008
On Thu, Oct 9, 2008 at 6:31 PM, Stephen Sinclair <radarsat1 at gmail.com>wrote:
> The problem that was brought up on the forum was how to do a bunch of
> intensive computation before starting the audio synthesis running,
> without causing problems. I think I took the liberty of generalizing
> the question into how can we do a lot of computation _anywhere_ in a
> chuck program without stalling the other shreds and causing havoc with
> the dac.
Hi, I was the original poster in that forum thread, and I'd just like to
chime in with my thoughts. At first I was merely wondering about what will
happen with heavy processing loads; I had no specific timing scenario in my
mind, but I did suggest the "compute all before audio begins" method, but
that certainly isn't all that interests me. Everyone's responses so far
have shed some much needed light on the situation, thanks.
I REALLY like the idea behind this code:
me =< now; // step outside time
me => now; // step back
but I guess using OSC would be a similar method, wouldn't it.
However, (and maybe my chuck newbness will start to show in this question)
what if I was working on an algorithm that required the previous audio
sample's value before the next audio sample could be calculated, and those
calculations were extremely computationally intensive? The physical
constraints of the computer simply wouldn't be able to keep audio flowing at
audio rates, but would chuck be able to output the sound to an audiofile?
If I chuck both this mythological algorithm file and the rec.ck (from the
examples) to the same VM, will the audio file output slowly fill with the
correct sequence of audio samples (my gut tells me yes)?
Hmm, now to go build a Beowulf cluster to OSC a bunch of code to...
Thanks again for the wonderful ideas/perspectives/thouhts.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users