Time Mode/Evaluation Changes

Feature Requests
,
1

I think that evaluation style of VUO needs to be changed to make it easier to use, reduce visual clutter, and need to attach so many noodles.

Nodes should have time modes and execution modes, maybe that are able to be manipulated via a parameter, designed in a way that keeps users from having to connect Fire to everything.

There just needs to be a global fire/current time per composition that everything can be assigned to by default. If one needs more control, they can change node mode, and then connect to more fine grained control of evaluation via the current Fire system.

Maybe I’m wrong, and it probably seems like a big change, but I think this is one of the biggest things that VUO could introduce to make it easier to use. While the options and fine grained control has been very nice, now that it is all done, it is obvious harder to design things with the system and get that same live visual feedback that was had with QC.

I am always having to interrupt the meat of my coding, to attach a Fire to something and see my updated values. Or finding that I have dozens of things connected to Fire patches of some sort, or the Current Frame…which just doesn’t seem to make sense, because they are all doing the same thing, which could be accomplished without a single connection at all.

To some degree, I also wish that rendering to a single window was a default of sorts, with the ability to opt into more. So many connections, and hard to convert sometimes when you want to render compositions offline.

I don’t think that a push evaluation system, or all the fine grained options that have been presented, has to go hand in hand with having to consider those options at every turn.

2

My two øre; I think a lot of the confusion regards the nodes having different ways of accepting events, obfuscating the flow. Taking the “Build List” and “Hold Value” nodes as examples, the first requires events fired through the input port, and the latter at the refresh port. I think it would be a lot more consistent if you only delt with the refresh port when it comes to events.

When that is said, I also think event firing nodes should be visually distinct from processing nodes, and the different types of processing nodes should be visually distinct from each other (input, math, layer, object, image, etc.). The gray matter of the editor as it is now demands time for making it understandable with a limited palette of colors. The option of coloring is nice, but there should be some default coloring scheme declaring the type of node at least so you don’t have to spend time doing it if you don’t want to - but still have a minimum of visual identification of the general patch.

I think a lot of the issues with fire nodes everywhere stem from the input control. As no share value node or port of any other non-frame-updated node gets updated until it gets an event, this requires an excessive amount of event connections. I know there is a feature request for this somewhere that will update a node when you change a port value. That simple (in use, not sure about the code for it) change would make the editor feel a lot more intuitive, and less reliant of a nest of fire connections.

I agree that the requested frame port can be a pain to work with, but there is a “Fire on display refresh” node that can be used instead. I keep forgetting that it exists, and I curse myself every time I have a bunch of wires that has to be moved. However, I’m not sure that using the current frame as a default time source is a fit-all solution. With music I think using the clock from the beat-detection works a lot better, for working with serial, the “fire periodically” is a better and more consistent option, and I can assume that for audio generation it wouldn’t be the best either.

3

I don’t disagree with that, but for me, the answer is that I don’t want to be dealing with these Fire nodes at all, unless I need it to fire less than refresh rate.

4

I also agree that consistent color coding is useful. It is especially odd to open example patches and have color standards be different between them.

Fire On Display Refresh seems to make a composition work slower than connecting to Current Frame from a window output, for whatever reason, last time I was trying it out.

But all this is sort of side issue to the feature request. I want to use VUO and not be frustrated, have it flow, and for others to feel that way as well.

5

There just needs to be a global fire/current time per composition that everything can be assigned to by default. If one needs more control, they can change node mode, and then connect to more fine grained control of evaluation via the current Fire system.

Oh hey, that’s something we’ve actually had some internal discussions about. Often I’ll create a composition that has several Time input ports (Receive BCF2000 Faders, Smooth with *, Curve, etc.) and only one port that makes sense as the time source (Render * to Window : Requested Frame). It would save time and avoid confusion to have the “Requested Frame → Time” cables automatically created and hidden.

Another common case is connecting a Fire on Start to a bunch of nodes. Somehow doing this automatically and hiding the cables would also save time and avoid confusion.

Do these cover what you had in mind for this feature request?

To some degree, I also wish that rendering to a single window was a default of sorts, with the ability to opt into more. So many connections, and hard to convert sometimes when you want to render compositions offline.

That’s maybe a separate topic if it’s going to get into a longer discussion, but I can briefly mention that one option for a more QC-like / single-window feel is to create a protocol composition (image filter/generator). Then you don’t have to put in the Render * to Window, you just make the image and it renders automatically. If you think that could potentially satisfy your desire for default single-window rendering, and you have ideas for how it could be made better, feel free to post those to a separate feature request or discussion.

I also agree that consistent color coding is useful. It is especially odd to open example patches and have color standards be different between them.

Oops, if you mean the built-in example compositions, those are supposed to be consistent — yellow for event sources, green for rendering nodes, violet for the node being demonstrated. If you notice inconsistencies, feel free to file a bug report.

6

Taking the “Build List” and “Hold Value” nodes as examples…

The Hold Value node might be a special case — we were actually discussing recently whether it’s a good use of the refresh port, or whether we should modify that node to be less confusing. Are there other examples you have in mind?

The option of coloring is nice, but there should be some default coloring scheme declaring the type of node at least so you don’t have to spend time doing it if you don’t want to - but still have a minimum of visual identification of the general patch.

Cool. After seeing how helpful the color scheme in the built-in example compositions can be, and having to manually tint nodes to go with that color scheme, I personally think that could be helpful. There’s currently a feature request Set default tints in the node library, or feel free to create a new one if you have something different in mind.

I know there is a feature request for this somewhere that will update a node when you change a port value.

Fire an event from Node when an input value is changed in the Editor

With music I think using the clock from the beat-detection works a lot better, for working with serial, the “fire periodically” is a better and more consistent option, and I can assume that for audio generation it wouldn’t be the best either.

Yes, thanks for bringing that up. If Vuo is going to automatically choose a time source for you, you need to be able to easily change to a time source different than the default.

7

(waiting for replies)

8

Hey there.

I felt like maybe I had overstepped some sort of bounds by this suggestion from something I saw on FB, even though I really meant it to help out the VUO effort overall.

I will respond in detail tomorrow.

9

I just think that the node itself should be able to accomplish whether or not it is enabled or not, or something more fine grained (fire at start, fire every X seconds).

In QC, you put a consumer patch at the end of a chain, and if it is enabled, that’s it - the rest of the chain evaluates. You don’t have to hook something to every Enable in order to get things to evaluate.

I would just like for there to be some similar metaphor, on a patch level.

Maybe I’m asking the wrong question.

Can I make my own node that causes the rest of the chain to evaluate without hooking to Fire…and/or put a port on my own custom node, that allows me to make it Fire On Start, Fire Every X Seconds, or Fire at Requested Frame Rate? Just lumping that functionality with a node that provides textures, or a shader, or whatever?

On another note, thanks for the suggestion about the image protocol. I have been trying to fit many compositions to that anyway since it is needed for offline rendering.  

10

Hah, I have no idea why that text is gigantic in that one place in my post!

1 Like
11

In QC, you put a consumer patch at the end of a chain, and if it is enabled, that’s it - the rest of the chain evaluates. You don’t have to hook something to every Enable in order to get things to evaluate.

OK. I think what I proposed above would address that. Instead of you having to hook up cables from a trigger into the left side of the chain, that would happen automatically. The cables would be hidden. So it would look and behave as if the Render * to Window node were pulling from the right side of the chain.

I’ve opened this feature for voting.

Can I make my own node that causes the rest of the chain to evaluate without hooking to Fire…and/or put a port on my own custom node, that allows me to make it Fire On Start, Fire Every X Seconds, or Fire at Requested Frame Rate? Just lumping that functionality with a node that provides textures, or a shader, or whatever?

You could. Subcompositions (and of course C nodes) can have trigger ports. For example, if you had a subcomposition that generated an image, you could make it fire the image out the trigger port every frame. Depending on your workflow, or how you use the subcomposition within the rest of your composition, that could be really handy. (Or it could get in the way, if you already have a trigger in your composition and need to insinuate your subcomposition into the existing trigger’s event flow.)

Hah, I have no idea why that text is gigantic in that one place in my post!

Well, this was new to me, too: In Markdown, if you put the “—” right after your paragraph instead of leaving a blank line, it treats the text as a header.

12

This is all nice food for thought.

But with the feature request, I think there still would need to be a metaphor for turning the chain off, just like with the Enable.

Maybe it’s all too much trouble and not worth it.

I guess that maybe the most constructive thing for the VUO team that I can say, is that the real problem I’m trying to solve for myself, is what seems to be more setup work to get things evaluating than in QC.

Looking at my compositions and noticing the repetition of Fire connections at the beginning of chains, or even when making them, and I’m hooking the majority of things to a Fire, why can’t that somehow be made to be a default behavior, or just have it be “sucked into the node”, as a sort of, uh, node mode? This keeps all the connections at bay, and especially the need to make them. So, that’s my summary.

But I think that having the functionality of something NOT updating until you Fire, is a good one to have, and shouldn’t be sacrificed at all.

The more I think it over, my dream behavior for VUO would be to be able to enable the chain, disable it - directly at the start of a chain, or be able to hook something like “Fire Every X Seconds” up to induce the least likely (subjective, for sure), but still useful behavior.

Another way to look at it, coming from a QC background -

In VUO, you have to get all the branches of a chain, and attach something to push them through to a single renderer. That’s one Fire for every branch, usually.

Whereas if you have a single thing rendering in QC, it kind of goes up all the branches and sucks up the info, with just one Enable(fire) involved - that is built into the patch itself. So in VUO, with the Fire itself being a separate thing from the “patch/node”… it results in way more connections, and having to think about connections, at least that I have observed.

Sorry if I have been repetitious in my effort to explain my thoughts on this.

I’m definitely willing to concede that my thoughts on this might just be wrong, and it may be worth hooking things to Fire the majority of time, as the clearest metaphor. I just thought it was worth some dialogue, and that some constructive ideas might come from it… maybe this even should have just been a “Discussion”.

13

There’s a feature request Option to temporarily disable/turn off nodes. Does that cover the enabling/disabling you have in mind?

14

(More discussion on https://www.facebook.com/groups/vuoflow/permalink/554601344702951/)  

15

(That Facebook post was deleted by the poster, but discussion can continue here on this feature request.)

16

I’m kinda with George on this. Wiring to Fire nodes every new branch is sometimes feels a bit tedious. Though not sure his point about an auto-fire mode is being understood completely (perhaps like him I’m not sure it could work either, it might create an avalanche of events on some occasions throwing some unexpected results which wouldn’t be good, but if it could work would make for nice training wheels and less “coder” mindset for experienced users).

One thing that might be good is that if you create some kind of node that is in the “likely-candidate-nodes” list like a Share Value or Share List it automatically gets wired to a Fire at Start and that wire is hidden (as Jaymie suggested but just for certain node types). I know George is asking for something beyond that with an automatic mode but as a start it would be helpful, or even two shortcut keys that find the nearest Fire at Start/Fire Periodically and wires it.

Also auto wiring Time Inputs automatically to a default Time Source node (like system time) that can be changed at Composition level to a different source like Window Frame Refresh or whatever for audio. Could be a shortcut key for that too instead of automatically, but that would make it more effort for new users to understand.

Bottom line is Vuo is potentially much more powerful* but less follow-your-nose and definitely engages less of an artist mindstate (“play” could sum it up) than QC, I think. Perhaps when it is learned sufficiently the sense of play emerges?

  • Having said that, one of the ex-Apple-QC now-FB employees made an incredible Machine Learning brain in QC to recognise emoticons drawn by hand that you can train to recognise a set of emoticons drawn freehand onto the window. Pretty impressive stuff for a visual coding app!
17

In Vuo 1.2.6 we added a menu item, “New Composition from Template.” The three templates put several nodes on the canvas, including a Share Value node, labeled Time, which outputs events with the time at which the frame will be rendered, so that a constant stream of events can be used within a composition. Does that in any way help with this issue?  

18

Well a little bit I suppose but it’s 1% of a fix I think b/c we still need to do loads of wiring to Fire and Time while making a complex composition :-)

Not really the same as auto-wiring any Time input ports on new nodes to the default Time output source, nor is it auto-wiring a Fire at start to Share Value nodes.

I re-discovered the FR for detachable constant flags, that would solve Share Value node issue.

If we ever were to get Vuo Editor scripting and rules (which I’m first to admit is miles off given the many other features and expansions needed more urgently) it could do this automagically maybe.

I think this FR is about a much more fundamental change to Vuo, or at least in a ‘mode’.