I think your using Pure Data is really cool, and I’ve had some similar setups going before. However, you can use QC to make workable faders, buttons, and other GUI elements by hit testing, using sample and holds, and built in patches like signal, watcher, etc. Just because people may not have openly posted much GUI type stuff on the web doesn’t mean it can’t be done.

So, you can write a qtz that use GUI interface, and then broadcast to your Graphics player for control, or write it all in one window. Whatever you want really. Not limited at two windows.

For you and your scenario, it may have well been quicker to use pre-written Pure Data stuff that you saw was available, and use MIDI (you could have done it with OSC as well). That’s one of the flexibilities of Quartz Composer. However, I just want to correct the assertion that QC has no way to control elements while they are running, as it’s very false. Then you conclude that it makes it less valuable as a performance tool. Really, it’s more that you were trying to learn QC as you were doing whatever you were working on, and for some reason it didn’t occur to you how to make faders, buttons, or knobs.

Besides actually making GUI in QC, which is well possible as I described, one can always create a control parameter interface using Xcode if you’re bundling an app, or just use the built in QC parameter control window.

Particle generators can also slowly ramp up via a number of ways using built in tools.

Not trying to come off as overly vigilant, it’s just that as someone who knows how to use QC, it’s clear that your article is based on many incorrect assertions out of the fact that you were attempting to actually learn QC as you were doing this, and are now conveying inaccurate facts.

By the way, pretty sure you’d already know (and depending on your setup it may not be useful), but if you’re running your QuartzComposer visualisations with the composer (rather than in a Cocoa app or similar) you can view published (to root) inputs with the Patch Inspector, as long as your view is in the root pane.

Another trick which I find handy for live tweaking, is that if you have an element, say, LFO, and you want to tweak the amplitude live – is that if you publish the amplitude value directly, the GUI (patch inspector) will presume that the value can be anything, and just give you a text box with a rotator knob. *However*, if you insert an input splitter on that parameter, then look at the second pane (command+2) of the properties of the input splitter, you can give the element a range. This will display itself in the inspector (if published, or if selected) with a nice little slider, which will map between the values you want from left to right. Just in case you didn’t know :P

There’s also an apps root published ports, although I don’t know how to access them. Some type of Mac voodoo I’m sure, maybe including foodstuffs like Cocoa – so using PureData seems like a nice solution. I’d much rather learn PD than Objective C.

Nice work, btw.