Knob for Faster Expressive Results

[useful_design (Alastair)]

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.  

[useful_design (Alastair)]

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 @smokris 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 @jstrecker’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.  

[useful_design (Alastair)]

comment removed  

[jersmi]

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?

@jmcc’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…)  

[useful_design (Alastair)]

everything I posted today was clearly outside of this FR. I’ll find somewhere else to post it!  

[jersmi]

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.  

[George_Toledo]

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.

[jersmi]

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?  

[George_Toledo]

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.

[useful_design (Alastair)]

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.

[useful_design (Alastair)]

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.  

[useful_design (Alastair)]

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?

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

[useful_design (Alastair)]

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.

[jersmi]

Yep, works very well!

[jmcc (Jean Marie)]

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.

[George_Toledo]

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.  

[useful_design (Alastair)]

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.

[jersmi]

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.

 

[George_Toledo]

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