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

[Hans Aberg]

On 26 Apr 2009, at 22:04, Kassen wrote:

>> Since there are no such limits in Chuck, I want in principle enable  
>> the same
>> generator to do note-on effects emulating real instruments.
>
> Well, I'd argue that modern computers do have the same limitation that
> hardware synths have; a finite amount of CPU resources. To complicate
> matters further; there are big differences between how various
> acoustical instruments deal with "voices"; a guitar is rather
> different from a harpsichord there even when the way of creating the
> sound is quite similar.

Though I mainly had keyboard instruments, it is quite uncommon to have  
a large number of generators on the same pitch set off in rapid  
succession. You can try that effect with two generators on my keyboard  
layout by tremolo between the tuning reference key and the key that  
sets it off. It sounds not bad, but resetting the generator might be  
somewhat more distinct.

>> You mean apart from scheduling decay cutoffs and the like.
>
> Yes, well, those are implicit in UGen behaviour and not so much
> "scheduled" as such, I feel.

If you want to automate that, then the Ugen must be able to generate a  
signal to do the disconnect. The future scheduling is just a  
workaround in the absence of that.

>> 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.
>
> Sorry, that's beyond my expertise.

It seems Chuck avoids C++ "automatic elements", in favor of returning  
references. This is what is causing the cleanup problem, because when  
the function has finished, there is no way to tell which references  
are used and which are not. One way to do that is to trace or  
references from the function stack and global objects. This way, the  
unusued elements can be removed.

> I don't think we lack devices that
> "could be used for GC" as GC is being implemented right now. The
> issue, as I understand it, is that combining GC with realtime
> performance is tricky. Beyond that one of the DEV's will have to help
> you.

Yes. A tracing simple GC is a two-space copier. Have two memory  
chunks. Allocate new memory in the one by moving a pointer. When it  
fills up, trance the root and copy it over to the unused space.

Now the problem is that it runs fast until GC time. when a lot of  
copying is made. So it needs to run in a thread, and do a little GC  
now and then, when the CPU admits it.

>> 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.
>
> Sorry, that's not quite right. ChucK runs in a single thread from the
> OS perspective and several "shreds" may run on the ChucK VM. The
> purpose of shreds is mainly to determine execution order in a
> deterministic yet convenient manner. We can't depend on the OS for
> that as not all OS's that ChucK runs on are capable of realtime
> performance (why MS and Apple don't implement this at least a s a
> option is beyond me but they don't).

The both use the Mach kernel, I think (at least Mac OS X does), which  
uses preemptive multitasking. Mac OS X may still have support for  
cooperative multitasking, where each program must release time to the  
others - I have a vague memory that may be better for time-critical  
situations, though a chore from the programming point of view.

> In short; there is a very real
> difference between "shreds" running in the ChucK VM and "threads"
> running on the OS (and supported by cores, etc); we don't just use
> those funny words because they are cute, even when some of us may
> enjoy such exercises in creative linguistics.
>
> In short that means that ChucK shred timing should be completely
> deterministic and extremely precise and when it's not that's a bug, it
> also means that for chucking multi-core cpu's won't do you much good.

Aha, so you may get a timing problem, there.

> While it may sound like a complicated extra layer to implement "a new
> OS"

Sorry for exaggerating :-).

> on top of systems like Linux, OSX or Windows it does mean that we
> can share code across OS's with little regard for who runs what; I
> think that's quite nice.

A VM though usually means an overhead.

> For a more in depth treatment on the how and why of ChucK's internal
> structure I'd like to refer you to this;
> http://www.cs.princeton.edu/~gewang/thesis.pdf
>
> Hope that helps,

Yes, thank you. That timing aspect of threads (or shreds) is important.

   Hans