Mike;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(I know, I know -- I&#39;m crazy.)<br>
<br></blockquote><div><br><br>:-) this does remind me that I need to document and file a big relating to assignment and -probably- over-zealous GC that I found Friday night, a few hours before show-time.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

It&#39;s 9:25am here on the East Coast of the U.S.  We&#39;re onstage at 2pm<br>
and 8pm.  I have a script that receives OSC messages from a Java<br>
program.  The messages contain the string name of a file to play.<br>
It&#39;s a simple stereo file (I&#39;m already working with a very kludgy way<br>
of playing stereo files--loading it twice into two buffers).  But<br>
every time I spawn a new thread, the file loads from disk and there&#39;s<br>
an audible click, or drop in audio.<br><br></blockquote><div><br>Ok, I don&#39;t have the time to hack at your code as I need to help clean up from Friday&#39;s party this afternoon. Also; my systems aren&#39;t your systems, being equipped with different drives and CPU. As this is a system-specific issue it makes no sense for me to test fixes here. But;<br>
<br>* First place for speedy fixes of system-overload-related clicks is increase the buffer size when starting ChucK. The price is latency, of course, but we&#39;re on a deadline. <br><br>* I think SndBuf can block-load parts of the file instead of fetching it all at once. Look into that. This sounds like the most structural solution to me but I think few people use that feature so it might have bugs.<br>
<br>*Pre loading all files into a big array of SndBuf&#39;s that aren&#39;t chucked to the dac will not cost CPU, just memory. In this case you&#39;d play them by connecting them and sporking the relevant shred (remembering to disconnect them later). This won&#39;t grind things to a halt cpu-wise. It might cost a lot of memory. Verify you don&#39;t happen to have that much ram. If not consider batch-converting them all down to CD quality if they aren&#39;t already. If they are already at CD quality you could see what happens when the computer would get down to virtual memory; the OS might have special tricks there to speed things up that ChucK lacks.<br>
<br>Good luck!<br>Kas.<br></div></div>