jersmi's picture

This is about supporting creativity and expression. Vuo lacks tools for working quickly -- it can be difficult to set something up and see expressive results right now. In one sense this is a UX/UI issue -- modular software is particularly difficult when it can cover so many use cases -- how do you decide what to highlight?

Scenario: say I have a creative thread I wish to follow, a sketch, a seed. Like having a sketchbook close by, I want to be able to set up and explore possibilities ASAP.

To this end I wish I could load a simple 'knob' -- a Share Value in the form of a knob UI element, could just be a float value normalized to 0 to 1 range. Then I could quickly refine it with Calculate to set up an expressive range.

This idea applies to a majority of Vuo scenarios, here's a simple example: say I want to play with thin line widths on a 3D Object, say a Make Grid Lines Object -- I wish I could load a knob and quickly type an expression into Calculate, knob * knob * .01, connect and go. Two things get in the way -- event flow and parameter ranges on modules. The more parameters a module has, the more difficult it is to use as an expressive object. A tool like this would help.

Features (in order of importance):

  • Don't need to consider event flow because it will just work.
  • The knob could simultaneously be published (for creating comps to load in other software, VDMX, CoGe, Resolume) and still be used in a running Vuo comp.
  • The knob could be assigned to an external source via either OSC or MIDI.

Some think all parameters in modular software should be normalized. In lieu of this, it would be great to have some solution that considers these basics. Pretty sure these concepts have been hashed out a kajillion times by now from various directions....



And include knobs in a nice

useful design's picture
Submitted by

And include knobs in a nice macOS GUI window when we go File Menu> Export to App… Bonus points for being about to click on the knob with mouse/stylus and drag up/down or left/right to edit value on the fly… like many Adobe apps and DAW tools.

maybe the knobs could appear horizontally in a dropdown in the Composition runtime window the same way "published to root" inputs did in the QC Viewer window. Multi-position switches would be a welcome addition to sit along side knobs. On/off switches too.


jmcc's picture
Submitted by
Feature status:
Waiting for review by Team Vuo
Waiting for more information from reporter


How about a Fire when Value Edited node? You could then create a protocol composition where you could publish the input port. That way you could change the values by exporting your composition as an FFGL plugin, or importing it directly into VDMX.

You could also use it with Receive OSC Messages or Receive MIDI Events.

If you don't want to connect/disconnect cables when you switch between in-editor testing (using the Value port's input editor) and a production mode, you can use a Select Latest node to switch between the two.

Does that meet your needs?

In the spirit of Vuo right

jersmi's picture
Submitted by

In the spirit of Vuo right now I think it's great, I will use this a lot! Thank you!! I appreciate seeing how it was made as well.

Alastair 's point is important, because his point revolves around output (to Mac App, etc.). (Where input is successfully covered for host app/external control).

I guess the next level up would be a larger task, though. For example, I can imagine a subcomposition with n knobs (or sliders), with the knobs (and ports) published and visible in the subcomp UI (thus in the Vuo editor), which could then be published/available as one (or part of a) UI for export to Mac app, etc. Knob position --> subcomp UI would need to be addressed -- dragging knobs around in some "edit UI" mode would of course be awesome, or just knob xy pos from the right click menu like for published ports. "Skinning" (or just coloring) the knobs for export would also be in play.

I'm keen to prototype a knobs

useful design's picture
Submitted by

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.

Haven't tried anything lately

jersmi's picture
Submitted by

Haven't tried much lately, is there an acceptable way now to get UI up and running in a Vuo Mac App?

Regarding knob UI, was wondering about GLSL + "Is Within Circle". @GeorgeToledo 's arc generator node is a shader, for ex. Maybe?

At any rate, Jean Marie's solution is nice for a lot of my needs. Thanks again!

Coincidentally…I was just

George_Toledo's picture
Submitted by

Coincidentally…I was just thinking last night about the way that nodes in Max/MSP can look like sliders, knobs, etc, in the editor, and be hooked to “whatever”.

There is also a mode to the editor where all of the non GUI nodes get hidden, and the end user only sees the GUI node objects. This allows one to code GUI in the editor and then wrap the graph up in app form, all in the same environment.

I had also recently mentioned that I thought custom plugin/node views would be a very good idea for VUO, and this thought about the knob seems very much related.

Another way that GUI in VUO

George_Toledo's picture
Submitted by

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.

Huge use case for seeing GUI

jersmi's picture
Submitted by

Jean Marie, your (very nice) example .c node opens up in a text editor when I double click on it from inside the Vuo editor (in my case BB Edit). No problem, really.

Yeah, George, I agree, I think there is a strong use case for seeing GUI objects. Visual feedback is a powerful tool. Like being able to see (and edit, wow!) an audio waveform on a computer -- imagine that before and after!

Since we're using examples of other software -- there is a modular audio app called Audulus (currently in beta for version 4) that uses an effective approach with knobs.

Audulus was originally directed towards iOS for iPad, then to macOS + AU plugin version. In Audulus users create modules (which would be subcomps in Vuo) for sound stuff then "expose" knobs and other elements from inside the module. Then in the editor (root view) key command an "edit UI" mode to drag knobs around. (Can also cable directly to the knobs to modulate, which makes a lot of sense for modular audio world.)

I like that the dev for Audulus is committed to strong visuals all for UX -- he just introduced a shader node for GLSL, and already has for the current beta other clever ways for supporting custom visuals, SVG and PNG support, using demux to animate PNGs specifically for knob UI's, etc.

Audulus screenshot, users create/customize modules:

So yeah, I do think think the

jersmi's picture
Submitted by

So yeah, I do think think the heart of this feature request is for a visual GUI element in the editor that could:

  1. Have the same behavior as Fire When Value Edited.
  2. Be viewable in the editor.
  3. Be viewable in a subcomp UI (with the ability to position them).
  4. Export as part of a GUI menu for a Mac App.

What about this FR being one

jersmi's picture
Submitted by

What about this FR spinning off into one for a "UI protocol"?


  • UI elements could be arranged (and resized?) in the comp loader by dragging UI element bounding boxes with the mouse. (Perhaps isolating Viewer mouse interaction to a UI protocol could relieve some "what about this scenario" confusion?)
  • When used in a parent comp the UI comp GUI would show in the editor window. (Maybe a "show UI" true/false toggle in the protocol ports?)
  • The UI comp could be saved to modules as a library item.
  • Protocol output would be the combined UI layers that could then be used as part of a larger comp view as an overlay or sidebar, or not. (Generating output ports for UI values would obviously be part of it, to connect to other parameters in a parent comp.)

I'd have a preference that

useful design's picture
Submitted by

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).

One thing I really want to

useful design's picture
Submitted by

One thing I really want to make clear, I know I've talked about before and suspect i have lodged FR around published ports of my own. But I'll repeat it here because I think it's of critical importance to understand before any voting or working on this gets done.

The way published ports in Kineme's Quartz Builder we created as input ports for the application, there was no way to dynamically change their appearance or min/max/step/significant-figure values in the case of sliders. That precludes greying out or hiding irrelevant inputs or changing slider value inputs to be relevant to state, or update the text (and greyed out/hidden status) of enumerated lists.

mimoLive has the most sophisticated example I can think of for how a macOS host application executes binding between a QC file's published inputs and the host application. They use the file protocol interface of QC where a bunch of protocols which (amongst other mimoLive specific things) organises things like the min/max/step values for sliders and arranging groups of ports into distinct regions of the mimoLive UI which have the little triangle (think folders in macOS Finder) which can flick open more settings and be opened/closed/hidden in mimoLive.

The mimoLive Custom Layer docs explain it pretty well for those interested, it's stood the test of time at Bonix, though they must be plotting a path away from QC at some point, the main developer of mimoLive is running QC on a virtual machine with an old macOS where QC is stable. I used to make custom layers for mimoLive/BonixTV and using protocols for binding is less than ideal but at least Vuo already has a file protocol system built in (Image Generator, Image Filter). EDIT QC had the additional feature of a protocol definition table, goes Vuo would need some kind of Composition Info dialogue to do that, or a node that loads a text file that accomplishes the same purpose.

In the example images below you can see for "Transition": when it is a cut there's no other input, when it's a transition period is revealed. Crop similarly reveals and hides published input ports according to state of other inputs. (The Vuo composition runtime itself could controlling this state logic in case of exported apps or the Editor UI experience).

It also permits the binding of more sophisticated GUI controls that allow users to interact with geometry directly with mouse clicking/dragging, as in the rotation, scale and position arrangements of a logo in this interface. That's outside the bounds of what I'm asking for here, it's not in the set of native macOS controls, but something to think about if the UI of exported apps is enabled some another way, such as incorporating UI builder Xcode template files or something that we, as Vuo developers, can alter to suit our own purposes. That was another post I was going to make but I've probably worn out my welcome on this thread for now!

EDIT: Added images again for the third time. Not sure why they keep disappearing?! maybe I need to change the files names after accidentally erasing them with the "remove" button the first time thought it just removed the button appearance at bottom of post but removes the file. Reloaded then came back a day later and gone again. weird.

And here's the FR i made

useful design's picture
Submitted by

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.

Hmm, I think being able to

jersmi's picture
Submitted by

Hmm, I think being able to include ports in a UI does seem like a separate issue?

For the FR as stated above, sure, skip bells and whistles -- namely window interaction, dragging UI elements around with bounding boxes, etc. Just having x/y position for elements would do. The core of the matter for this one is to be able to show UI elements in the editor as part of user created library module.

With this idea doesn't it seem possible that a user might be able to design hideable or fold down areas for a UI, perhaps even a window resize (that the user would know would be cropped if not properly arranged in the parent UI)? Though not sure about a min/max slider UI, seems straightforward, maybe that would be a separate FR to add that to the current slider?

Jean Marie's contribution above is a UI element in the viewer after all, no? (Just have to click to open and change the value then it gets closed when not in use....)

Well, what do I know, don't

jersmi's picture
Submitted by

Well, what do I know, don't you think it worth the effort to add focus? I love the conversation and trading of ideas, and abs no disrespect for your ideas, clearly born of experience! It's all Vuo, after all.... and who knows, maybe the overlapping ideas will spark something for Team Vuo.

UI elements in the editor

jersmi's picture
Submitted by

GUI elements in the editor window is the original idea, yes. But above I asked about spinning this off into a FR for a "UI protocol", so users could generate their own modules as library items of UI elements that would be viewable in the editor and also be available in the parent comp as GUI if so desired. Dumb idea?

Personally, I think it makes

George_Toledo's picture
Submitted by

Personally, I think it makes plenty of sense.

I think that getting a knob and/or slider actually working in the editor as distinct nodes, but with the appearance of GUI widget interface, would just be great first steps that could probably make plenty of workflows much easier.

It feels like getting something basic like that inevitably reveals areas where performance enhancements need to happen after initial implementation. User feedback on the real world thing becomes non-hypothetical.

It’s hard to gauge the complexity of implementation of various tiers of this idea because the editor is closed source (maybe older versions of editor source got published at some point?). But it seems very useful workflow wise.

If more complex versions of the idea seemed possible to address initially, by all means, would be great.

Ok, sorry I misread the

useful design's picture
Submitted by

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.

it's not a dumb idea jersmi

useful design's picture
Submitted by

it's not a dumb idea jersmi and it might not surprise you to hear that George and I (IIRC hope you agree, @GeorgeToledo) had discussions with Kosada about this kind of thing in the very early pre-beta maybe even pre-alpha days of Vuo. I think it took some flack from one of the core dev team, especially the idea user definable skins and stuff like a music Digital Audio Workspace effects rack (breaking with the Vuo brand look and feel i guess is the concern). At any rate Vuo was never going to have this in early versions so it's good to visit the discussion now that Vuo is getting some maturity in it's feature set and native data types.

If I understand your question

jersmi's picture
Submitted by

If I understand your question, the Fire When Value Changes module that Jean Marie presented above is a special .c module that works in the editor like the sliders on many modules. It requires the min/max in the module to do its job. Real type input ports do not do this as designed -- need to publish then set min/max to access a slider.

Thanks Jean.

George_Toledo's picture
Submitted by

Thanks Jean.

No need to sidetrack on this point, but I remembered earlier in VUO history when a friend wanted to do a lot of editor work, and it was not possible. Maybe it wasn’t published at that point, or there was just an incorrect conclusion that stuck with me.

I did remember some form of the editor eventually got published…I must have incorrectly thought it was an old version in order to get by with satisfying the licensing requirement of open source code used, as had been done with some of the kineme stuff.

Pictures can help

jersmi's picture
Submitted by

Pictures, food for thought. First example, Vuo style, inspired by the Fire When Value Changes example because I could imagine the sliders inside the precomp being these modules, with the ability to port their sliders to the precomp UI. (slider was easier than a knob to quickly mock up. And wouldn't really need the input ports).

Realizing that there is a line to be drawn -- I am not asking for Vuo to be like TouchDesigner or VDMX or CoGe, et al. -- here is a pic of max/msp graphical objects.

First thought is, why not

George_Toledo's picture
Submitted by

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?”.


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. :-)

One thing I don't want to see

cwilms-loyalist's picture
Submitted by

One thing I don't want to see is the editor become to busy and feel pieced together. I really like how clean and simple the look of the editor still feels and don't want to lose that. So I was thinking, what if the editor had a very simplistic representations for GUI nodes showing a default look of the GUI elements built right in the node, not showing the custom themes or looks that have been applied and would be seen in the render window. This would keep the clean VUO look to the editor but still offer full composition control for many GUI elements, it could even be a collapsable feature so you don't have to use/see it if you don't want to. This could work for future GUI nodes too.

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.

  • Also, would it make sense for a rotary slider GUI node be able to switch from a chosen range to an unlimited rotary encoder when it just sends events out one output port for left rotations and another output port for right rotations?

chris, I don’t think I

George_Toledo's picture
Submitted by

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.

Taking in this discussion, I

George_Toledo's picture
Submitted by

Taking in this discussion, I would like to inquire about this set of hypotheticals, to the VUO team. My main intent is to basically outline what I perceive to possibly be an easy and visually straightforward path.

What would be the level of difficulty of taking the sideways slider element, and having it actually be a node that always renders on the editor canvas, with the appearance basically being just like the slider part that pops up in Jean's video? 0-1 normalized output implicit, and would create a fire event, just as the Fire When Value Edited node currently does.

What would be the level of difficulty of making it vertical?

What would be the level of difficulty of a knob?

Most importantly, would that even appeal to the VUO team as an idea to implement at all, or is there some aesthetic or functional objection?

I feel I should really restate - though I have voiced some concern about GUI widget type functionality being embedded in a stock node type look, if that prevails as seeming like the wisest choice to everyone, or somehow is the easiest to implement, I don't have strong objections. Anything is probably more useful than nothing.

And to look from another perspective entirely...maybe there ARE parts of that approach of building GUI "into" the face of a typical appearance VUO node object that could aid in an overall system, allowing there to be the existence of some kind of input port that could be published, and then later bind to programmatic GUI on an app level, Interface Builder GUI objects, or whatever. Yet that gets into a level of overarching complexity that may not be worth biting off to start with.

Chris , I respectfully

jersmi's picture
Submitted by

Nice response to the mock up -- it was a thought that came together in a few minutes. Occurs to me that the response demonstrates a point of the FR -- potential strength of visual tools, a picture is worth a thousand words and all that.

Of course the Vuo editor is a visual tool as well. In that, Chris , this FR is based on the premise that well designed GUI clarifies and strengthens and makes things easy to read. The FR speaks to the idea of using all available tools for translating information into human readable stuff, where it all adds up, synergistically speaking.

Simplifying again -- since Fire When Value Changes has already proven itself awesome, what about the knob that stays on screen version as Fire When Knob Changes (which then of course spawns other Vuo graphical nodes that could fire when changed, slider or button or color, etc.)?

That is, this idea for a new "UI protocol" could/should be a separate FR.

It occurred to me how this request developed across repeated use of Vuo, often/always wishing a Share Value node could just be a knob or slider that I could tweak asap, like max graphical objects, I guess.

Just a quick observation —

jstrecker's picture
Submitted by

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.

Thanks for the input, @Jaymie

jersmi's picture
Submitted by

Thanks for the input, Jaymie. 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.

Come to think of it, as the

jersmi's picture
Submitted by

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 Jean Marie 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 Changes has already proven itself awesome, what about the knob that stays on screen version as Fire When Knob Changes (which then of course spawns other Vuo graphical nodes that could fire when changed, slider or button or color, etc.)?

Some other ideas for GUI:

useful design's picture
Submitted by

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

useful design's picture
Submitted by

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.

jersmi regards you

useful design's picture
Submitted by

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 Jaymie? TeamVuoUserBase could help with the graphic design aspect of it I imagine.

As much for myself I tried

useful design's picture
Submitted by

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. 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.

Feature status

  • Submitted to
  • Waiting for review by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for.

Read more about how Vuo feature requests work.