Szilveszter;<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;">
This is what I thought:<br>
When Mike's script sporks a new playFile() shred, this tells Chuck to read in two SndBufs and connect them to dac _before_ the next sample is calculated.<br><br></blockquote><div><br>Yes, that's right. However, that doesn't mean ChucK needs to do it before a samp has passed. ChucK needs to calculate -say- 1024 samples as well as do things like loading a file in the time-span of 1024::samp. The longer the block becomes the more any sudden peaks in system usage can be spread out.<br>
<br>In ChucK syntax we pretend things like loading files are instantaneous, but of course they are not in reality; even a simple multiplication will take some time to be calculated.<br><br>This convenient and expressive way of looking at the computer that we use works very well.... until the underlying system can no longer cope with the strain at which point we'll see the reality below it shine through.<br>
<br>BTW, your test of writing to a wave file to see whether there are glitches there won't work; ChucK will always write to wave files correctly, even when it runs out of cpu. In that case the audible sound will glitch but all samples will be calculated and written. In the mini you can see this happen; the displayed value of "now" will start lagging and as soon as the processing intensive bit is over "now" will be increasing faster than a second per second until it has caught up.<br>
<br>Hope that helps,<br>Kas.<br></div></div>