[chuck-users] Urgent shot in the dark -- Audible clicks when spawning shreds when SndBuf reads from disk
signal.automatique at gmail.com
Sun Nov 8 16:38:54 EST 2009
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 :-).
> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users