we ran the 2pm show with some difficulty. mixing all the files to
mono and pre-loading everything worked (using almost 1gb of RAM).

Oh, well, that's what the RAM is there for :-).

the
mono bounces were all clipped.

Whoopsie. It happens.

of course, it's supposed to be a 4-channel piece... ;-)

:-)

we had some sensor and code issues. We stopped and started over a
couple of times. but basically the ChucK part worked perfectly. :D

For all of it's crash-prone-ness I do find that ChucK is quite predictable; once you have your code working it'll keep working. I don't think I ever had a crash or glitch on stage (aside from livecoding).

Thanks SOOOOO much for all your help, everyone. I think that the 8pm
show will be better.

No problem; I enjoy this kind of thing. If any pictures or recordings materialise do post; I'd like to see what you've been up to but don't stress for my sake.

Kas, I was using buf.chunks(1024), but it looked in Activity Monitor
like it was loading the whole file anyway. hrm...

Lovely! Another bug found. We need to keep Ge on his toes; I hear he eats quite a lot, let's keep him busy to compensate ;-). I have actually been working on a similar problem lately ( http://bottomfeeder.ca/top/?p=71 ). It's quite hard. I said it before but I feel that ChucK could use a syntax for "load this file as quickly as you can without glitches but no quicker". The matter has been debated on the wiki with regard to fileIO but I still feel that the interaction between the highly abstracted ChucK syntax (that assumes a infinitely fast computer even while meant to facilitate a good trade between sound quality and CPU usage) and the finite resources of the underlying system could use some attention.

More soon!

Good luck!
Kas.