On 17 Apr 2009, at 19:38, Kassen wrote:
Yes, that is most surely the reason. The tricky part is know exactly how advanced ChucK is, knowing what has to be done by hand. It would have been cool if one just fed those patches into the output, and the program figured it out.
Yes, I see. I had a quick glance at your code and with your setup you'll end up with a lot of connected yet silent series of UGens. On top of that you'll be creating double connections so even if your CPU could keep up you would run into clipping.
I think both may happen (by my testing): the CPU load may increase to the point that it is the delays that causes the crash, but also before.
The most obvious strategy might be disconecting the UGens again at a isButtonUp() event but that would mean cutting off the envelope's decay which is likely undesirable.
Yes, or having fewer generators, and letting the keys circulate assignment around them, which may have the same effect (which, when I read ahead, see that you are mentioning, too.
What ChucK is doing here indeed isn't very "smart" but on the bright side it is behaving according to the specs and this behaviour can be useful in other cases. For your needs I'd suggest looking into voice cycling; there are examples about polyphony in the /midi/ directory. I know you aren't using MIDI here but the strategy for dealing with polyphony without overloading the CPU will be useful, at least as a strating point.
In the case of MIDI, it may be necessary, due to a limited number of channels. Scala uses complex algorithms for that. But on a first, try, I was hoping to void that.
Give a shout if you get stuck there.
Sure. Hans