[chuck-dev] ChucK plugin for PD
garton at columbia.edu
Wed Oct 18 11:26:48 EDT 2006
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!
More information about the chuck-dev