Mike;<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;"><br>
You get a couple more of these trainlets running, and you'll kill the<br>
VM. I absolutely love ChucK's concurrency model, but it can't handle<br>
too much of this kind of thing. The sample-level intervention is also<br>
painful.<br>
<br></blockquote></div>True. Here's a small mod. the trick is that it only updates the osc's gain at zerocrossings, making it relatively glitch-free. The price is that CPU cost will now depend on the frequency used. <br>
<br>===========================<br>fun void hannGrain( float f ) {<br> SinOsc s => dac;<br> f => s.freq;<br> 0 => int n;<br> 0. => float h;<br><br><br> now => time start;<br> now + N::samp => time later;<br>
while( now < later ) {<br> hann( ((now-start)/ samp) $ int ) => h => s.gain;<br> n++;<br> <span style="color: rgb(255, 0, 0);"> .5::s.period() => now;</span><br> }<br> <br>}<br>=================================<br>
<br>This strategy is not at all perfect but I feel this gives a decent trade between CPU efficiently and sound quality. We can trade those using ChucK's timing but with clever trading we can get a better deal. Note this only works because we know the phase of the oscilator and we know the rate won't change. If you need changing frequencies this will have to be extended. <br>
<br>I'd also think about sporking a static number of shreds and re-using those with signalled events as your current strategy is probably generating a lot of garbage.<br><br>Hope that helps. Cool sound!<br><br>Kas.<br>