On 26 Apr 2009, at 18:26, Kassen wrote:
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.
Sure.
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.
Since there are no such limits in Chuck, I want in principle enable the same generator to do note-on effects emulating real instruments.
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.
By that I mean that it Chuck does not have a built-in mechanism to schedule and reschedule future events. If you want that, it must be built by hand via halted threads.
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.
You mean apart from scheduling decay cutoffs and the like.
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.
It seems that problem that folks try to program around is that Chuck returns references of class objects, without having a root tracing mechanism that could be used for a GC.
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.
Chuck probably just gets its threads from the OS rather implementing in effect an OS on top of the one already there, so that determines what it should be capable of. Hans