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
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!