Is there any plan to allow ChucK to have its audio generation turned off? Also, can you give an example of how this would work with PD? Is this just going to be a single object with a script attached? How will this be able to interact with PD objects? Thanks, Mike On 10/16/06, Mike McGonagle wrote:

After using both ChucK and PD, I have noticed that PD is far more efficient at generating audio. I have created two simple patches in both PD and ChucK that were just sine wave generator. The patch in Chuck could only handle 20 voices before it started to generate an audible sputter, while the same patch in PD was able to handle almost 200 voices before there was any audible degradation of the sound. I am working on a G5 Mac Laptop (not sure of the clock speed), I have also run the same things on a Dual G5 1.8MHz machine, and was able to get PD up to about 350 voices before it started sputtering (I wasn't able to test ChucK).

Is the plan to basically use ChucK for the higher level logic, and control PD's audio generation? I see ChucK as a great language, which would be a nice addition to PD, but as far as being an audio generator, that is the whole reason that I have stopped working with ChucK.

Just my $0.02...

Mike

On 10/15/06, Martin Robinson wrote:

...

As some of you may know, Brad Garton has adapted ChucK to run as a Max/MSP external (http://music.columbia.edu/~brad/chuck~/). I'm currently working on porting this project to PD (hoping for Windows and Linux support, at least). I'm collecting feedback from anyone who is interested in this sort of thing. What projects would you use a ChucK PD external for? What features would you like beyond the basics?

In the same vein, I hope to produce a VST plugin with equivalent functionality by the end of the year. Of course, I'm looking for similar feedback here too.

Thanks in advance for any comments.

martin robinson _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

-- Help the Environment, Plant a Bush back in Texas!

"I place economy among the first and most important republican virtues, and public debt as the greatest of the dangers to be feared. To preserve our independence, we must not let our rulers load us with perpetual debt." -- Thomas Jefferson, third US president, architect and author (1743-1826)

"Give Peace a Chance" -- John Lennon (9 October 1940 – 8 December 1980)

-- Help the Environment, Plant a Bush back in Texas! "I place economy among the first and most important republican virtues, and public debt as the greatest of the dangers to be feared. To preserve our independence, we must not let our rulers load us with perpetual debt." -- Thomas Jefferson, third US president, architect and author (1743-1826) "Give Peace a Chance" -- John Lennon (9 October 1940 – 8 December 1980)

Hi Mike and all!

After using both ChucK and PD, I have noticed that PD is far more efficient at generating audio. I have created two simple patches in both PD and ChucK that were just sine wave generator. The patch in Chuck could only handle 20 voices before it started to generate an audible sputter, while the same patch in PD was able to handle almost 200 voices before there was any audible degradation of the sound. I am working on a G5 Mac Laptop (not sure of the clock speed)

ChucK is pretty abysmally slow, but it should handle quite a bit more than 20 sine waves on a powerbook? On my 1ghz G4 12" powerbook, I get about 60 sine waves before things go south, and over 100 on a 1.5ghz 12" powerbook. What is the code you are using to test this? What version of chuck? Also, the SinOsc in ChucK is also not the best thing to benchmark, since it generates the sine wave inefficiently. Though by that logic, not many things in ChucK are good to benchmark, huh huh. One of the these days, after we get stuff more "right", we'll think about optimization. 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? 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? Thanks again to Brad for starting the ~ revolution and to Martin for forging ahead! Best, Ge!

On Tue, 17 Oct 2006, Mike McGonagle wrote:

One thing that might be nice would be to see a couple of screen shots of how these things are connecting up in Max.

I'll try to get my lazy butt in gear and put some on the web page. Good idea!

I was wondering if it would be possible to use ChucK as a sort of scripting language that controls various PD objects. Otherwise it just seems kind of odd to have a self-contained ChucK running inside PD, and if that is the case, why not just run ChucK by itself.

yes, you can do this -- I wrote two new ugens (MaxBang and MaxMessage) that are included in the code. One will send out a scheduled bang, and the other can send out scheduled lists of values that you computer in ChucK. I've used this capability a lot with [rtcmix~], and the ability to use arrays/functions/etc. in [chuck~] suggests that it would be terrific for this kind of application. max/msp is horrible at maintaining any semblance of state.

...

From what Ge described above, being able to send code in real-time, that sounds like the idea is to use PD as a gui/ide interface only. It would be nice if you could leverage the strengths of both ChucK (writing procedural/logic code) and PD (building a gui and interfacing with audio/midi/video[with GEM]).

yeah -- this is the big win in combining these different languages. Use their strengths! brad http://music.columbia.edu/~brad

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

Martin -- 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. 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. brad http://music.columbia.edu/~brad On Sun, 15 Oct 2006, Martin Robinson wrote:

As some of you may know, Brad Garton has adapted ChucK to run as a Max/MSP external (http://music.columbia.edu/~brad/chuck~/). I'm currently working on porting this project to PD (hoping for Windows and Linux support, at least). I'm collecting feedback from anyone who is interested in this sort of thing. What projects would you use a ChucK PD external for? What features would you like beyond the basics?

In the same vein, I hope to produce a VST plugin with equivalent functionality by the end of the year. Of course, I'm looking for similar feedback here too.

Thanks in advance for any comments.

martin robinson _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev