Knob for Faster Expressive Results

Those are good ideas Jean Marie for Vuo developer/users but for those of use publishing comps or especially applications for macOS for novice users, external controllers and the like aren't really an option.

I'm keen to prototype a knobs UI in Vuo and Adobe Illustrator when I get some time for it. Perhaps Magneson can help me to wrangle some C code for me to build a Custom Node when I've finished a prototype in Vuo.

As you say jersmi to have a UI module that works both in the Vuo Editor and exported apps we'd need a new Vuo feature class to pull that off.

A UI option for custom and special nodes might be a floating panel such as QC had with the ⌘2 panel for each patch or something on the editor canvas itself appearing as a sub composition with dials and data, but I'm sure @Steve poured ice-cold water over this kind of idea many years ago or in the window bar or dropdown from editor/composition window bar.

jersmi,

Our developers created the node. It's a team effort!

Another way that GUI in VUO could work is for users to publish ports they want to hook to GUI.

Another app (a VUO interface builder?), or maybe a built in feature, could cycle through the published ports and programmatically spawn GUI for published ports.

It could be that the user adds a specific key to published name or something to control whether a knob, slider, etc, is created…or they could be presented with a set of options that they then choose from via an interface.

If you look at the sample code for Apple’s QCTV project, and I think QC Performer (or some name like that), you will see a very simple concept along these lines. The GUI is programmatically spawned by the QCTV host app, according to published port types.

That said, I think there is a strong use case for exposing a way to see something like a knob or slider (and other GUI objects) as a node itself, within the VUO editor.

I'd have a preference that for a subset of published input ports that represent some of the simple native types could be arranged in a window in horizontal or vertical fashion as a kind of minimum feature set for exported apps.

Those types would be

• bool
• int
• real
• text
• color
• is gradient a native type? if not make it a Vuo type
• enumerated list, not a Vuo type I don't think would need making (think indexed list in QC)

A user choice of horizontal or vertical arrangement would be the easiest to implement but it's conceivable more advanced arrangements as discussed above would be possible.

I'm just focusing on exported apps at this point, because some of the good ideas expressed in the last couple of days are for the interface of the Vuo app itself, and there's overlap with exported apps UI and developer space UI but also differences to the Vuo Editor and how it may offer enhanced for UI design which might be unique to the Vuo and not easily translate to the current automatic app build routine of Vuo.

I think as a minimum for UI in Vuo Editor and development process, the same published input port UI window that gets used for the exported app could be present as real time controls for the Editor though? A lot of coding overlap with the exported app.

I prefer my published ports in one place, but I'm not speaking against any of the ideas to have them in on the editor canvas itself, it could be awesome to have that too. I'm just looking at what might be more easily achieved (I suspect) as a 'Minimum Viable Product' UI for exported app developers. And for the Editor UI as an after thought (and what QC had built into the Viewer Window and root level Published Ports viewer pallet from day 1 IIRC).

And here's the FR i made around dynamic values for published port settings

Dynamic shared values node that can dynamically expose/hide and change published value inputs that composition/app users interact with

@TeamVuo have tabled the above FR for now until A UI for storing and editing published input port values but people can still make comments on it 🙂. My reading of a comment on the other post by Steve is that it's also a FR to have published ports exposed in exported apps in a preferences type window (think Kineme's Quartz Builder for those who were around in the day).

There's a lot of overlap with some of these FRs. I'll leave in Jaymie's capable hands to figure out the best taxonomy for all these ideas as discrete FR. I may assist with a listing and tagging exercise at some point soon as it seems to be a hot topic.

Ok, sorry I misread the original FR as being in a compiled Vuo composition runtime window.

I might try and map out all the different UI/UX FRs and sort them into sets or tag them so we can see where there are synergies between ideas and where they are completely orthogonal/unrelated.

I missed the point of this FR because i didn't watch the GIF image in the OP attachments.

is this something that happens for all Real type input ports (some have no bounds other than the system min/max) or is it something that only happens when you drop the Fire When Value Changes node onto the canvas jersmi?

Ah it actually works! (Doh)

I downloaded but only looked at the C code and the GIF… thought it was a mock up not actual thing.

Just to clarify: "It’s hard to gauge the complexity of implementation of various tiers of this idea because the editor is closed source". The editor is open source.

News to me too about Vuo's open source Editor. Thanks for keeping us up to date and reading all our musings on these threads, Jean Marie. much appreciated.

First thought is, why not just a slider on the editor. (The mockup does look very well done!)

I have had the VUO team tell me how they don’t want to be bound by QC, probably more than once and recently again…so I look at that and I think “should building sliders into the face of a node that looks like QC be the solution?”.

Maybe!

But the node look of QC (and now VUO) is its own GUI object. I’m not of the sure the functionality of mashing them together.

max/msp is popular, and all of those gui objects are a strength. If VUO team truly does want to break from their QC shackles, it’s probably good to consider the best parts of various node languages. I know that has always been done to some degree, just what comes to mind here again.

Maybe that mockup look IS the best kind of solution layout, I was just surprised. I also thought it would be a single slider, or single knob.

It is cool though jersmi! I wouldn’t mind something like that at all. :-)

chris, I don’t think I understand the second and third sentences. I read them, and I am unsure if it means one thing, or the exact opposite. Just stating that before I blather some more…

I was thinking the use case for this would be, when you have made a composition and someone else needs to run it who isn’t extremely literate in VUO. For a use case where there are contextual reasons you wouldn’t want to compile as an app for whatever workflow, but the person who will be using the composition would likely be intimidated by objects that aren’t universal (like typical VUO node look, “ports”, etc).

So, for this use case which I was thinking was the context of discussion, I would just say that welding the QC Patch look onto typical type GUI objects would probably seem very confusing to many non-VUOers, and I am not sure there would ultimately be much to be gained.

There might still be some convenience gained for me…or rather US, as users.

If the GUI element has to be in a QC looking rounded rect with input and output ports always showing and such, one wouldn’t be able to put a bunch of sliders and knobs in some area, and have it clearly look like just sliders and knobs. There would be node graph with QC looking boxes that have sliders or knobs IN them, and I think some people’s minds shut down when they see that stuff…if they aren’t super into these kind of node graph systems.

If sliders and knobs were built into banked groups - non dynamic, it seems like there would always be scenarios where you have extra sliders left over or need one or two more. So, that is a little concerning as well.

@GeorgeToledo I cleaned up my wording a bit in the rest of my post, hope it makes more sense to you now. Basically I don't want the editor to get cluttered as more features are added.

Just a quick observation — Seems like different people are talking about different end-users of the composition. Could be the composition author themself, or a composition operator who uses someone else's composition within the Vuo editor, or the user of an exported app. While general principles of UI design (if anyone in the world can agree on what those are) would apply to all, the solution that seems most intuitive or fits best with the composition author's + end user's workflow could be specific to each.

I agree with those comments Jaymie. Also Chris sort of slipped the idea into this thread that a knob or slider node/control object sitting on the Editor canvas (that's always visible and "tweekable" without click on any ports) would also have some kind of replication in rendered window with enhanced graphical properties that allow for skinning or whatever. That means the slider/knob/switcher object would need an input to accept a cable from a GUI object properties node ( I think a few of those exist now like Text).

I'm not sure that was ever part of the conversation prior to now and that's another permutation of the three or more different ideas of developer vs Vuo user of 3rd party comp vs Exported app and how any published inputs get manifest across the three different user case scenarios, or four if you count the idea that you can adjust on the Editor canvas but also in some rendered window object.

This whole shebang needs mapping out to make sure future use cases aren't precluded in the rush to get something by way of "ready to tweak" published ports. Im thinking here in terms of the same way "published to root" inputs had native controls in QC and then in Quartz Builder apps when that happened.

We made Fire when Value Edited a built-in node in Vuo 2.4.0. Leaving this feature request open for discussion of the other points.

As much for myself I tried thinking about how all these interrelated UI controller possibilities crossover and differentiate. This is my first stab in the dark at where the different ideas might seperate into different feature requests around conceptually different end user requirements.

You can access the Numbers table for your own use here on iCloud.

Features listed below	Knob (and other controls) on Editor Canvas (Feature request)	Value port shared to root level (as currently exists it’s possible with no UI sophistication without something like VDMX, CoGe hosting the composition)	Dedicated UI controller node (knob/slider/dropdown enumerated list/color/gradient) Some other FR
Mock up	by jersmi. Screen Shot 2021-12-01 at 6.34.44 pm.png	TBA	TBA
Adjustable in Vuo Editor canvas as composition is running	✅	✅	"✅ Full UI experience only in the composition runtime. To adjust value in Vuo Editor the value adjustment canvas UI operates similar to Fire when Value Changes node in Editor "
Is duplicated in the Composition runtime window(s) automatically for adjustment in runtime window(s)	❌?i	❌?v	✅?ii
Is placed in a second Runtime window reserved for UI controller nodes	❌?i	❌?v	✅?ii
Is built into compiled Vuo apps. Appears in the titlebar area of the composition window (if applicable)	❌?i	❌?v	✅?ii
Is built into compiled Vuo apps. Appears in a second window or floating UI panel)	❌?i	❌?v	✅?ii
Value can be controlled by an external device or OSC as well as within VUO	✅	"❌ only when Vuo composition is hosted in another app that can rig it"	"❌ only when Vuo composition is hosted in another app that can rig it"
Value would be visible/adjustable in Motion/FCP and any other FXPlugin hosts with enhanced UI features	❌?	✅	✅?iii
Control over knob/slider adjustment value mapping and ramping /sensitivity	✅?iv	"❌ No way of describing info about published ports without some kind of protocol page within Vuo"	"✅ Several input ports on node allow us to control its appearance, functionality and behaviours "

i. Would it be desirable to edit the values in the runtime window or have a second window, maybe a floating panel automatically created to host the controller? Possibly not, build a separate UI node for that kind of controller.

ii. Should these sit in the same window as the composition run time? Either:
 in title bar, with scroller left and right if there’s a lot of them
 dropping down from title bar as in Quartz Composer “Viewer” window
Or in a seperate panel like a floating panel like “Kineme Quartz Builder” or something made using Vuo nodes e.g. Render UI Controllers to Window.

iii. Maybe it can pass more sophisticated information about the controller(s) to hosting apps the way mimoLive passes QC file info through a new Vuo Protocol Template info. E.g. groups controllers into sub-groups that can each be revealed and hidden (see mimoLive for how it works).

iv. Right-click to adjust control sensitivity/direction, mapping etc?

v. Possibly published ports do nothing in exported apps to distinguish from UI Nodes?

Can access the Numbers table for your own use here on iCloud.