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.

QC equivalent: 

pull-based execution

Component: 

Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo and Vuo Pro licenses

Complexity: 

●●●○ — A few months of work

Potential: 

●●○ — Could expand community

Comments

My two øre; I think a lot of

MartinusMagneson's picture
Submitted by

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.

I also agree that consistent

George_Toledo's picture
Submitted by

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.

There just needs to be a

jstrecker's picture
Submitted by

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.

Taking the "Build List" and

jstrecker's picture
Submitted by

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.

Hey there.

George_Toledo's picture
Submitted by

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.

I just think that the node

George_Toledo's picture
Submitted by

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.

Moderator note: 

Adjusted formatting

In QC, you put a consumer

jstrecker's picture
Submitted by
Feature status:
Waiting for more information from reporter
»
Open for community voting

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.

This is all nice food for

George_Toledo's picture
Submitted by

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

Feature status

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for. Vote your favorite features to the top! (How do Vuo feature requests work?)

  • Submitted to vuo.org
  • Reviewed by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released

Votes

56 votes so far!

Who voted?

Kewl's picture
.lov.'s picture
jersmi's picture