What?! That's sweet! What other methods are there in there undocumented? ;-)
-MIke
On Thu, Nov 6, 2008 at 6:23 PM, Kassen
Mike;
You get a couple more of these trainlets running, and you'll kill the VM. I absolutely love ChucK's concurrency model, but it can't handle too much of this kind of thing. The sample-level intervention is also painful.
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.
=========================== fun void hannGrain( float f ) { SinOsc s => dac; f => s.freq; 0 => int n; 0. => float h;
now => time start; now + N::samp => time later; while( now < later ) { hann( ((now-start)/ samp) $ int ) => h => s.gain; n++; .5::s.period() => now; }
} =================================
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.
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.
Hope that helps. Cool sound!
Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users