[chuck-users] polyphony (what happens after note off)? was: Killing thread from without

[Kassen]

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.