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.
2 Likes
Is this about a knob on the editor surface or a knob in a rendering window? I thought this specific conversation was more about GUI widgets on the editor.
1 Like
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?
2 Likes
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.
2 Likes
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.
2 Likes
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.
2 Likes
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. :-)
2 Likes
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.
2 Likes
@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.