On Thu, Oct 9, 2008 at 6:31 PM, Stephen Sinclair <radarsat1@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
 doallwork();
 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.
-Eric Hedekar