Maybe the default in Vuo could be that everything that isn’t hooked to a “Fire On Start” or “Fire Periodically”, gets an evaluation style of “Fire On Display Refresh” by default.
In this concept, a node that isn’t hooked to “Fire On Start” or “Fire Periodically” could still opt to have not every part of the code refreshed every frame (a node could be made to only re-evaluate when a port value changes…an idle patch, basically).
My reasoning behind this suggestion is that when designing a composition, I am finding that many nodes connect to either “Fire Periodically”, “requestedFrame”(window output), or “Fire On Display Refresh”. Overwhelmingly more than not. If it bears out that this is the case for the majority of graphs, it may make sense for that to be implicit, and for things like “Fire On Start” or “Fire Periodically” to be the exception to the rule, hooked to the minority of nodes in the graph. When designing the composition, at the end one would optimize it, by introducing the Fire On Start/Periodically as needed.
It seems more natural, for a “realtime visual” type environment to have a port update immediately cause a node to update by default.
I would like to add that this comment may be wrong.
I do see the value in what has been done, and it seems workable. I like it! I find that I use “requestedFrame” output of windows quite a bit, which results in feedback loop looking graphs. I don’t really have a problem with it, but it occurs to me that I’ve observed QC users have great problems conceptualizing feedback type loops in the past.
In fact, I’m less motivated to make this comment on my behalf, than I make it out of a hunch that other users (especially those coming from background in using QC) would find it more natural, and graphs to be visually simpler looking, while essentially retaining the same Vuo function set. I can see value in the current approach as well.
It occurs to me that the “problem” I’m trying to solve is more about the editing of compositions than being dissatisfied with the current evaluation defaults, or what is going on in the Viewer…
For instance, when updating a parameter on a shader or transform, etc, I want to see that update immediately, without having something hooked to make it fire every frame or periodically. But, after hooking that requestedFrame/display refresh to the patch for editing, then you have to make the judgement call of whether or not to get rid of it… or keeping it so that someone else checking out the composition will already have it there!
If somehow updating a port in the editor could cause a “fire event” implicitly - as opposed to my previous suggestion of it having a “fire on display refresh” type default, maybe that would “solve” the problem I’m having. I suppose I have thrown some variation of this idea out there before, come to think of it.
I was thinking that another way to handle it would be if a node could have a time mode that isn’t “external”, like is the default for everything now. If you could delete the port that takes a fire on start, and it just got timebase from the parent vuo composition, it would be another way of eliminating a large amount of connections.
Hi, @George_Toledo. Sorry I’ve been slow to respond to this. Interesting ideas here — finding ways to improve usability is definitely on our minds. Here are some related things we’ve been thinking about:
In Vuo 1.0, we added the ability to hide cables. My typical setup lately is to create a Share Value node on the left side of the canvas, connect requestedFrame to its input port, then hide that very long cable.
Another alternative to the long feedback-looking cable is to make an Image Generator protocol composition — these fire events through the published input ports on display refresh. (Image Generator compositions are useful, too, for CoGe (and soon VDMX) integration, and for offline rendering coming in Vuo 1.1.)
For both of the above scenarios, we’re thinking about ways to intuitively automatically connect (and possibly hide?) requestedFrame → time cables, to reduce the “everything is external” feeling. There are a lot of usability challenges to work out here; we’re going to try to dive into this soon.
Also coming in Vuo 1.1 is this feature request: [#643]. So, while experimenting, you won’t have to worry about connecting up cables; you can just fire arbitrary events with a single ⌘-click when needed. After you’ve figured out how you want to lay out your composition, you can connect an actual event cable to fire at the frequency you desire.
That paves the way for having nodes automatically fire events when you update constant values — but we want to first try to improve livecoding performance some more, and we need to work out the details of when it would be appropriate / expected to fire such events and when not to. Also planning to dive into that soon.
I appreciate you all looking at those aspects. The Image Generator protocol was a very nice idea.
Maybe some kind of click command or contextual menu on the Refresh or Trigger port could set a node to constantly refresh, and then another command could turn that off.
Yes I second the request for “fire event when constant value is changed” capability (and wired value changes for that matter too). As a learn-by-breaking-it-all kind of student I am finding the absence of QC type editing with instant feedback quite limiting. Preferably using changing a value or using up/down value incrementor arrows should tell the node to reevaluate. I guess there could be an issue with it’s new output not propagating in subsequent downstream nodes. To be honest I’m not familiar with Vuo enough to get a feel of how that issue will play out yet.
It’s a real joy killer. Another option if the Editor becomes scriptable would be to have a simple script that creates a fire on refresh window node and wires it to the selected patch and the window node output refresh port. It all feels cumbersome compared to QC but I guess there were reasons for doing things this way to enable multiple window comps.
BTW, the feature request for firing when constants are changed is over here. We’re going to try to dig into it for the upcoming Vuo 1.2 release.
Maybe some kind of click command or contextual menu on the Refresh or Trigger port could set a node to constantly refresh, and then another command could turn that off.
Oh, interesting; I hadn’t thought of doing that. But assuming we’re able to implement the fire-on-constant-change feature request in Vuo 1.2, would the constantly-refresh option still be useful? (If so, perhaps create a feature request and describe some scenarios.)
I’m unsure. I think it depends on how it’s implemented.
While I think that a node immediately updating when a value is changed is nice for editing the basics of a composition, there are scenarios where it’s handy to be able to adjust multiple values and then engage something to make those values update. I think it’s great that VUO does allow this very easily now.
Attaching current frame or periodic fire outputs are also very functional, it just makes the graph more complex looking since this mode of operation is expressed as a cable.
I tend to think that solving it by a kind of mode of operation that is inherent to the node is the cleanest way to do it visually. It also seems like it would be much quicker than attaching a cable. Maybe refresh port could be a different color when it’s made to constantly refresh, to make it very clear which nodes are constantly refreshing when you look at the graph.
I think reducing it to this would make it simpler for someone new to the system to understand, while allowing it to work basically the same underneath.
You’re obviously much more familiar with the underpinnings of the system than I, and if you see any weaknesses in this line of thought, I’m sure you could be right! The more I think about it though, the more I like it.
" it’s handy to be able to adjust multiple values and then engage something to make those values update"
Yes I agree with that too. Especially if you mistype into an input port and the value results in a Beachball or something random happening that is a distraction or worse.
I like being able to toggle the Fire state with a contextual menu. It reminds me of setting code BreakPoints in ScriptDebugger (3rd party Applescript editor). You can set as many as you like and they show with diamonds beside the line numbers but if desired you can enable and disable ALL of the breakpoints too. That could be a nice touch in Vuo too, doing so from one of the Main Menus or in the Toolbar to toggle all nodes that have be set to constantly fire to do so (or not do so).