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.
2 Likes
Thanks for the input, @jstrecker. Yeah, the convo here has expanded and contracted, demonstrates the power of the underlying concepts.
The original FR focuses on productivity while building a comp.
But as pointed out, having a few well placed “graphical objects” in a comp would also help the “readability” of a comp. In this regard, think Vuo before and after being able to add comments. GUI is a tried and true tool in the UX/UI toolbox.
Regarding “if anyone in the world can agree” on general principles of UI design, that sounds hopeless. I consider most FR’s to be about hope and promise for something I really love – Vuo.
1 Like
Come to think of it, as the OP I feel a little responsible for wrangling the concepts as well, to not lose sight of my awesome FR. :-)
I was super excited when @jmcc presented Fire When Value Changes, even felt a little bad for saying, “That’s great, but…”. So I’ll just point to my last suggestion from above:
Since
Fire When Value Changeshas already proven itself awesome, what about the knob that stays on screen version asFire When Knob Changes(which then of course spawns other Vuo graphical nodes that could fire when changed, slider or button or color, etc.)?
1 Like
Some other ideas for GUI:
• I was also wondering if maybe nodes like the slider and future rotary slider (knob) could have the option for increment steps via a list input
That would be accomplished with a minimal increment (or step) value.
So a min: 1, max: 10, step: 1 knob or slider would just output numbers 1 to 10 and nothing else.
and min: -10, max: 10, step: 0.5 knob or slider would just output numbers {-10, -9.5, -9.0,…10} and nothing else.
I have a few ideas for other ways to improve the usability of sliders and knob, can’t wait to mock up this weekend.
I agree with those comments @jstrecker. Also @cwilms-loyalist 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.
@jersmi regards you reiteration of the OP FR. I was wondering if like the tool tips, we could click on input sliders, knobs whatever and they then stay on the canvas until we close them, and we can drag them around out of the way or into a group to access for example the Attack, Decay, Sustain and Release sliders in the one spot on the canvas.
I guess unique knob and slider, 2/3/4 throw switches etc would be nicer to look at and guessing not a hugely dissimilar amount of work to making existing input sliders and knob version of same persistent, but maybe not @jstrecker? TeamVuoUserBase could help with the graphic design aspect of it I imagine.
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.
1 Like
We’re taking a look at this, including the comments.
1 Like
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. [](https://community.vuo.org/t/-/6865/34) | 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.
This discussion has explored ideas around UI/UX in Vuo, and we’ve appreciated the robust exchange. In order to help the community prioritize how we’d implement some of these ideas, we’ve connected these ideas to specific use cases. We’ve then mentioned actions the community can take to further these ideas. That way it will be easier to assess what the community sees as most valuable, and it will make clearer what specific functionality a feature request will add. This feature request and comments, although quite informative, is too broad to help guide implementation.
Here are four use cases that we came up with:
| Use case | Ideas | Community actions |
|---|---|---|
| Control values within the editor | a GUI node, UI nodes with knobs/sliders, a separate GUI panel, special moveable tool-tips, UI using published ports | vote on the existing feature request: Node GUI view; create new feature requests for other distinct approaches for controlling and viewing values within the Editor. |
| Control values within the editor and through external means (OSC, devices) | Explicitly mentioned in a few comments | vote on the existing FR: Map controllers to published input ports in Vuo apps; create a new feature request for a different approach. |
| Control values in an exported app | vote on the existing FR: A UI for storing and editing published input port values; create a new feature request if there is a different approach. | |
| Control values within VDMX, Resolume, Motion, FCPX, etc. | Possibly bypass published ports | Create a new feature request for this approach. |
I made a 3D Knob GUI element for rendering in a window, not necessarily in the editor. It’s a step in the right direction. I too would like to see fader or little knobs in the editor. It seems like some values present with a slider in the editor I presume if they have a min and max set. something like that but a dial or knob would be handy.