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, 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?”.
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. :-)
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.
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.)?
• 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.
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. [
?i