Mike; 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.