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

[Kassen]

Sorry, this was meant to go to the list, not just to Hans.


---------- Forwarded message ----------
From: Kassen <signal.automatique at gmail.com>
Date: 2009/4/26
Subject: Re: [chuck-users] polyphony (what happens after note off)?
was: Killing thread from without
To: Hans Aberg <haberg at math.su.se>


Hans;

> 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.

>
> 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.

> 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. 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.

> 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). 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.
While it may sound like a complicated extra layer to implement "a new
OS" 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.

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,
Kas.