Knob for Faster Expressive Results

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 and it might not surprise you to hear that George and I (IIRC hope you agree, @George_Toledo) 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.  

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?

If I understand your question, the Fire When Value Changes module that @jmcc 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.

1 Like

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.

Yep, works very well!

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.


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.  

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, @jmcc. much appreciated.

1 Like

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


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

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, @cwilms-loyalist , 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 — 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, @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 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.)?  

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.