[chuck-users] help understanding lisa

[mike clemow]

Kassen,

Here's an interesting by-product of your implementation: the effective
control rate of the enveloping is dependent on frequency.  If you add
the ability to specify the number of cycles per grain, you get nasty
artifacts on low-cycle grains.

fun void hannGrain_cycles( float f, int cycles ) {
    SinOsc s => dac;
    f => s.freq;
    0 => int n;
    0. => float h;
    cycles * (s.period()/samp) $ int => int N;

    0 => s.gain;
    Math.rand2f(0,4000)::samp => now;
    0.2 => s.gain;

    now => time start;
    now + N::samp => time later;

    while( now < later ) {
        hann( ((now-start)/ samp) $ int, N ) => h => s.gain;
        //<<< h >>>;
        n++;
        .5::s.period() => now;
    }
}

Here, you'd have to pick something closer to the sample rate for gain-changes.

Cheers,
-Mike

On Thu, Nov 6, 2008 at 6:53 PM, mike clemow <gelfmuse at gmail.com> wrote:
> 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
>



-- 
http://michaelclemow.com
http://semiotech.org