On Thu, Sep 24, 2009 at 8:41 AM, Stefan Blixt <stefan.blixt@gmail.com> wrote:

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@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@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

--
Release me, insect, or I will destroy the Cosmos!