Which features of the Quartz Composer Editor are most important to you?

What is the "Easily trying to figure out which patch to use" feature. I'm interested in that!

Can the next survey be "The things that Quartz Composer nearly gets right but doesn't…"

Suggested points:

1. Having to type complete words in Patch Library so 'st pr' will bring up nothing rather than the String Printer patch like it used to.

2. The use of settings panel to set Input Splitter Ranges precluding Published to Root inputs from programatic range and index label setting. (This is a big oversight)

3. Published Inputs and Outputs from Macro do not have common labels inside and outside Macros which leads to all kinds of confusion when exploding and creating macros not to mention requiring double entries. Publish to root is interfered with.

4. Search can't be isolated to current Editor Level.

5. Spotlight doesn't seem to work. Try creating a unique string in a note and search for it. Even days later when Spotlight should have caught up.

6. File Versioning as of 10.7.4 does not work. Save a version and it doesn't get saved. Nice integration with a Source Control tool like Git or SVN or both might be an idea here.

7. The Kineme K menu items and prefs — all of which I required.

8. When you edit a Library patch it can screw older comps dependant on the patch — even when it's a transparent edit that shouldn't have any effect. Should be an option to have Virtual Patches that do not auto-update or at provide an option on opening to say updated Virtual Patches detected, wish to update, list, save list to file…

9. Regressing the Escape key input when publishing an input/output port broke Kineme Publish All [in/out] ports function.

This is off top of my head, I'm pretty sure there's many more.

Live coding? I also like the bit where you use nodes instead of code, that's pretty neat ;-)

The one thing I really wish the Editor included is a way to view more of a structure. When you hover over an output/input, it gives you the yellow tooltip box with an abbreviated listing of the structure. If I could scroll through it, that would be amazing.

A better "stop" method on the viewer would be great as well. Sometimes when we're working with a particularly intensive comp, we have to stop rendering to regain control, usually this results in having to force/quit QC.

Search is something else that would be huge, implementation could be a lot better, both in QC from the library, and patches/plugins that are in use.

I know this particular poll is about the editor itself, do you plan on creating a poll around most used patches/plugins? The reason that I ask is that we use a lot of structured data from online or networked resources, and in my opinion that's one of the greatest features of QC, and something that elevates it above similar toolsets. Reading files is great (XML, CSV etc), but with increased reliance on OAuth (which QC doesn't natively support), we're seeing stuff we'd love to use, but are unable to. Although this could be alleviated by a plugin.

one thing i would like back in the editor is for the patch inspector to stay on the last page that was open. for instance if using the inspector with a command 2 or "settings" page open, i would like the editor to remember this when i click on another patch.

it seems the default is now always command 1 or "input parameters". so if you last used "settings" when you click on the patch again i would like to see "settings" and not "input parameters"... i know this seems trivial but QC used to do this. it was handy with cl, js, and glsl patches.

In the top of my whishlist is a native geometry renderer, like the kineme grid built-in the viewer, with options to add remove columns and rows of nodes, with a configurable edge blending for the borders. Moving this up to the viewer will unclutter the compositions (mines at least :)) and deliver a better performance then the usual "Render in Image" -> :)

About notes, I use them all the time, but often wish I could attach them to a patch. I tend to write pretty extensive notes for future reference, only to have to copy paste them when I enclose patches in a macro, as they stay on the original layer and don't follow the patches inside the macro. Doable, but time consuming when you're moving things around often...

This poll got away from me, but I want to chime in for editing text code - if QC didn't have a GLSL patch (and probably JS too), the amount of things one could do within the editor would be severely reduced; you'd always have to make a plugin.

Which is OK, but takes away a good amount of the reason to use QC; to get stuff done quickly. It's shocking that got so few votes since so many of the compositions and "things people seem to do" rely on those patches - I guess it's because a good amount of voters don't personally use them and cut&paste from others, but if the patches weren't there, they'd still probably be screwed.

Taking snapshots in the Viewer is something I do every day. I guess I'd use Grab.app instead, but it's very handy to be built in.

Templates are also extremely useful, as are the notion of protocols; it would be even better if we were able to add our own.

I was thinking about this, this morning, and even though the poll is closed I wanted to throw in for the QC Iterator.

I mean, yeah, it would be better if more iterations ran faster. That said, the abstraction of Iteration into that patch, and the way state works in the iterator is super useful, especially with the publish out functionality.