Hans;
The answer is "yes" -- it behaves one of those two ways. :) But it's a trivial change -- about four lines of code -- to make it behave the other way.
These are different musical effects, I think. I want to have one generator per key. I think of keeping it when doing transpositions.
Yes, and you may simply want to code in a way that suits your perspective on the instrument. For what it's worth; commercial synths tend to cycle (or steal...) the voice that was already associated with this key the last time it was played if we re-trigger a voice before the decay has finished, even when they don't have a absolute link between voices and keys in general.
I also spawn one thread for each key - at the release. Then fundamental problem is that Chuck cannot schedule and re-schedule events in the future; this must be done by creating a new thread.
Another way of phrasing that would be saying that the only thing ChucK can shredule is ChucK code and that this code inherently needs to be in a shred. I really don't see how that is a "fundamental problem", it's just a perspective and a syntax. We need to express anything we want done in code anyway. If you absolutely must re-schedule events then the only solution I see right now comes down to homebrew functor style objects with timestamps and making your own scheduler. That would be a interesting experiment though I don't think there is any need for that here.
Also, the idea of keeping threads alive in order prevent memory leaks seems an unwanted workaround, though perhaps it may be necessary if not possible to do it otherwise.
Well, as you are basically using a single STKInstrument per voice here I don't think there is a need to have a shred per voice at all in this case. Just a array of a dozen or so UGens with some infrastructure to keep track of which ones are free and similar voice-cycling infrastructure should do the trick. That would mean a single shred and no garbage at all.
As for killing threads, when dialing a phone number, already one and a half decade ago, the computer could create thousands of threads, each one doing a search path. When one is found and reporting back, it would be a waste of resources letting the others hanging around. So I think killing threads would be normal programming.
That's a quite different sort of system for a very different type of application though. I don't think ChucK is particularly well suited for managing phone company centres. Kas.