[chuck-users] Grains make garbage:(

[Stefan Blixt]

I would definitely use events here instead of sporking:

Instead of this:

fun void voice(){
    ...
}

while (15::ms => now){
    spork ~ voice();
}

do this:

Event voiceEvent;
fun void voicePlayer() {
    while (true) {
        voiceEvent => now;
        ...
    }
}

while (15::ms => now){
    voiceEvent.signal();
}

Besides losing any overhead that sporking causes, it also makes it a bit
easier to manage variables - this way you can keep the SndBuf in the the
voidePlayer function, before the while loop starts.

/Stefan

On Wed, Sep 23, 2009 at 10:39 PM, Kassen <signal.automatique at gmail.com>wrote:

> kurt
>
> > I guess I am wondering if there is a way to release Ugen references or do
> I
> > need to wait for garbage collection to liberally spork Ugens?
>
>
> I think you can assign "null" to objects to have them garbage
> collected forcefully but I'm not sure there.
>
> However in this particular case there is a easy way out. Since you are
> dealing with linear envelope segments and sample-based grains LiSa
> will suit your needs perfectly (see /examples/special for docs and
> tutorials). LiSa will contain a single buffer for you that can be
> played back multiple times at various rates with per-voice start, loop
> and so on settings. It will handle most voice cycling for you.
>
> For a more general case there are questions here. I think grains are a
> especially interesting case for resource cycling as we will likely be
> doing rather a lot of that in the case of grains. Off list i talked
> with Mike (probably our residential expert on using grains in ChucK)
> about proposing a sensible way for using non-linear envelopes with
> LiSa however neither of us could come up with a coherent approach.
>
> Perhaps somebody else has ideas; the exact volume envelope of grains
> matters a lot for the resulting spectrum.
>
> There are, BTW, no free rides here. For voices or grains (and assuming
> finite computational power) we will need to somehow cycle resources.
> This is unavoidable. The question is how much of that should be build
> in and how much we will need to do ourselves. I don't think all of
> this can be build into ChucK without sacrificing versatility and so I
> don't think that arrays with some infrastructure need be such a bad
> option here. It may be laborious but it also forces us to contemplate
> in depth what we need and gives us power to specify that in a very
> precise way.
>
> Yours,
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>



-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090924/6c65bee4/attachment.htm>