[chuck-dev] ChucK plugin for PD
mjr at cc.gatech.edu
Wed Oct 18 12:22:32 EDT 2006
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...
More information about the chuck-dev