[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