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

[Hans Aberg]

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