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