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