[chuck-users] help understanding lisa
mike clemow
gelfmuse at gmail.com
Thu Nov 6 18:53:26 EST 2008
What?! That's sweet! What other methods are there in there undocumented? ;-)
-MIke
On Thu, Nov 6, 2008 at 6:23 PM, Kassen <signal.automatique at gmail.com> wrote:
> 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
--
http://michaelclemow.com
http://semiotech.org
More information about the chuck-users
mailing list