[chuck-dev] ChucK plugin for PD

[Martin Robinson]

On Wed, Oct 18, 2006 at 11:18:06AM -0400, Bradford Garton wrote:

> I'd be really interested in seeing the pd code you develop -- I've had 
> requests to port some of the other 'language' objects I've built for 
> max/msp ([rtcmix~], [maxlisp]) to pd, and I honestly haven't used pd much. 
> All of the [chuck~] source code is on the web page, along with the mods I 
> did to the main ChucK code.  Essentially I build ChucK as a shared lib, 
> and then load it into the max/msp environment and find a few entry-points 
> to run it.  I also hacked the sample read/write code to use buffers I 
> pass in from max/msp.

Thanks for the feedback! I've actually been using your code fairly
extensively when developing the PD plugin. I currently have a very
messy version working now. Really the only features missing are
passing non-signal data in and out via inlets and outlets and
getting the text editor working.

> I have been successful in building a (pluggo) VST plugin with [chuck~]; in 
> fact I use a few of them in performances a fair amount now.

I hadn't considered this method before. Do you notice any drawbacks that
could be addressed with a non-pluggo VST approach?

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

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

I was curious about this as well! Currently I have all chuck~ objects
using the same VM (I'm developing on Linux now, so I'm using dlopen,
but I plan to port later). Your approach seems more flexible. Perhaps each
chuck~ object could specify a VM name as one of its arguments. Objects
that connect to the same VM would be able to synchronize. I'll have
to look into the different approaches.

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

I wonder how this will look once I break into the VST plugin-writing...

martin robinson