On Mon, 16 Oct 2006, Ge Wang wrote:
Hi Mike and all!
Hi Ge! :-)
One thing I'd love to see in chuck~ is the option to route code from various chuck~ instances to the same chuck virtual machine. I guess this is a feature request to both Brad and Martin?
This was actually one of them thar 'design decisions' I made when I built the object. I have some "~" objects that do in fact communicate with a single virtual machine, but I decided to go with individual (separate) ones for [chuck~] because it would enable me to route the output from one [chuck~] object, through some additional external processing, and then back into another [chuck~] object for further fun, etc. I wanted to be able to keep each instance relatively isolated from the others, and I wasn't as interested in the concurrent aspects (I am old and slow now). The other (possibly more compelling) reason to set it up as separated instances was to allow VST plugins to be built. I think everything has to be very self-contained in VST-world.
With this capability, it'd be possible to leverage chuck's concurrent programming model to synchronize different pieces of code. Alternately, each chuck~ could be its own virtual machine (this is currently the case in chuck~ for Max, I think), and the programmer would be able to send different code in real-time to chuck~ via an inlet. Thoughts?
One thing -- each [chuck~] object has 20 separate buffers that can contain individual scripts, but they all communicate with the virtual machine common to that particular object. I do use this capability, and concurrency should be preserved using this approach. You can also send in ChucK code 'on-the-fly' via a [text] or [chuck] message, although there are some max/msp-related constraints on what you can send, blearg.
Thanks again to Brad for starting the ~ revolution and to Martin for forging ahead!
Onward! Upward! Sideways! brad http://music.columbia.edu/~brad