[chuck-dev] ChucK plugin for PD

[Bradford Garton]

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