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

Part of the attraction of Visual Programming is the instant feedback derived from adjusting a value input to a node.

An edit might be as simple as adjusting the X position of some text. Opening up demo comps and making adjustments to node inputs to get a sense of how they work I am frequently frustrated by the need to restart the composition just to see the adjustment rendered. If the node could just be made to fire as one adjusts values one could see what’s happening — the essence of visual programming. The work around seems to be to wire up a machine gun trigger node (Fire on Window Refresh) into the patch I’m working with which is pretty boring to have to do repeatedly. (I guess if the Editor was scriptable one could assign a hot key to a script to do this).

There could be a pref for either fire when enter key is pressed to input a value or to fire every time the up/down arrows or a value that makes sense is inputed (i.e. if it’s a number input an accidental alphabet character would not cause it to fire just input values that check out on first parse of input). This would differentiate between constant feedback and slightly less feedback but more than we get at present.

@useful_design, I agree the current situation can be inconvenient.

Another option (besides restarting or connecting a Fire on Display Refresh node or Requested Frame port) is to re-fire your existing Fire on Start node (⌘-click on the trigger port, or right-click on it and select “Fire Event” from the menu).

I’m interested in the behavior you described (automatically fire an event every time a constant value changes). But there are still a lot of UX details to work out — for example, in the Count node (whose Increment and Decrement ports have special port actions), should changing the value cause an increment/decrement to happen (which would happen if you fired an event into that port), or should it just change the port value and not increment/decrement until it gets its next real event?

For the Vuo 1.2 release, we’re planning to dig into this. So I’ll go ahead and mark this feature request “Chosen to be implemented”.

Thanks, yes not to sure about that, as +Vuoworld+ is still very new and unusual to me I’ve got only questions.

Control + Click fires an event but I’d still have to go to the other node to do that. I think I’ll try the image filter protocol idea you mentioned on another thread about this that George started and then publish/unpublish inputs.

Oh look the floaters stayed over browser… is that supposed to ahppen?! see image…

Control + Click fires an event but I’d still have to go to the other node to do that.

@useful_design, in Vuo 1.1 we added the ability to manually fire an event to any input port, so you don’t need to hunt for a trigger port anymore.

the floaters stayed over browser

No, that’s not supposed to happen. I just tested on my system with Vuo 1.1.0, OS X v10.10.3, and Firefox 37 / Safari 8 / Chrome 41, and it isn’t happening for me (the detached port popovers properly go behind Firefox).

Could you create a bug report and fill in any additional details you can about under what circumstances that happens, to help us reproduce the problem so we can fix it?

Well it doesn’t consistently do that, so I might leave it for now. I do recall as I selected each Chrome window (Focused) in turn, they came in front of the Vuo floating palettes. It’s the least of my concerns vis a vis +Vuo+ today!

Double post. This site really needs like and delete comment buttons. Since the website is quite slow by the time it gets to my side of the Indian Ocean, and the Save button has no button_down state skinned, I often end up clicking it twice.

In the case of the Count node, and generalising for all nodes, I would say yes make it re-evaluate with the new value(s). If that changes the output then well and good. Perhaps nodes can have some kind of flag (internally in the node’s C code) for full reevaluation on input constant editing to determine if it does the full reevaluation thing or if the flag is set, do nothing or some alternative method that can be coded for in edge cases.

This leads to another feature request I’m considering making, more QC like behaviour for comp Run windows. Having our Count node get messed up may mean we need to restart the composition to get initial state values ( I guess in case of Count node we could just re-enter the Initial Value constant to reinstate initial composition state but it might be too late in a complex comp).

Having Run/Stop/Pause buttons on the Runtime Window would be nice, not sure how hard that would be. Also if windows could remember their positions when Run that would be great, I’m constantly dragging the output window to my second display (MBP) away from main display with usually several Editing windows. Either or both those things would be great for me.

I would really enjoy it if there was just a way to turn constant evaluation for a node on or off via the Refresh node on each patch, designated visually by the trigger turning a different color.

I think those are the two most basic desired modes of operation for a node, and that if more fine grained behavior is desired, then one of the Fire patches, or Requested Frame could be attached to whatever is needed.

I think that making the behavior an editor setting, or a hot key combo, while not being the worst thing in the world, has potential to lull one into thinking that a composition works a certain way, then making an app, and not having it work the same way.

It still wouldn’t solve the problem of having values update constantly (or not) either. Because at the end of creating the composition, one would still need to go and attach one of the Fire patches or Requested Frame to things that need to update when a user adjusts that port.

So I think the hot key or global editor mode ideas would still not solve the real problem, which is too many cables being needed to control the evaluation of the graph when it doesn’t really need to be visually expressed that way.

Thinking about it a little more… if it’s much easier to just have it so that you hold a key down, enter a value in a port, and the node updates, then I suppose just go with that! I understand that sometimes things have to take baby steps…though I don’t think it’s the best way as far as making the overall system instantly way more intuitive and usable.

What would be the resource impact of continuous evaluation of all inputs? NIs Reaktor use 400Hz for their default evaluation of the event stream. In Vuo, connecting all the lines to do this from the reqFrame, it would be at ≈60Hz.

If the impact isn’t too great, what about having continuous evaluation unless you connect something to the fire in port?

further to email discussion with Vuo team, adding the feature request include the matter of one typing a value into an input port field and without typing return clicking on a new node and the typed value gets lost. I realise this is probably ‘safer’ but for me just assuming an enter and applying the entered value would be helpful. I do this all the time, although i’ve started training myself to always click Tab key even if I’m not interested in adjusting the next port value.

So, if entering a new value into a port automatically updates in the near future…what would one do to enter a value, and then have it update at an arbitrary time? I guess if the feature is linked to an unlikely key combo that has to be held down, it would be ok(?). Would that interfere with programming that makes use of the keyboard?

I guess there is much that could be said about different approaches, pros and cons…

It’s all subjective, but I mention this since I see it has been chosen as a feature to implement, and I’m curious.

To me, it is not necessarily that the current behavior is bad - it is desirable for many instances. It would just be nice to toggle something on the node itself to set behavior, instead of connecting things. But I would rather connect things to define evaluation than have it be an either/or scenario.

I guess I’m a little muddy on what this actually entails, as it is planned :-) I’m wondering if now one would have to add more nodes in order to get something to not update…and how that could work, if putting a new value in automatically updates? It would seem to have a cascading effect, pushing the data through no matter what. (?)

Just my perspective out there, I’m guessing that the possible loss of function is something that has already been thought about.

" I guess if the feature is linked to an unlikely key combo that has to be held down, it would be ok(?). Would that interfere with programming that makes use of the keyboard?"

the Editor and the View are separate apps so not clear to me how editing values in nodes could interfere with Viewer app interactions. This original request was just that when a node port changes value due to user interaction with the node port it fires an evaluation. Just like QC patch would re-evaluate, even JS patch which could be deathly if you broke the code as you typed something ;-)

I think what you’re talking about @George_Toledo about node auto-firing is something completely higher level and could be good. Was thinking about it last night and looking at all the event wires I had dragged around to try and make my comp work (I think i found a bug with Build a List or Make 3D Triangle node but more on that elsewhere). And it occurred to me that if nodes say without cables coming to the input ports defaulted to auto fire so they evaluated machine gun style (what would they actually get assigned as the rate?) you might end up with a comp with a massive amount of over-evaluation wasting CPUs.

I always try and remove event wires once if have a bit of code working to establish the minimum number of event cables required, partly just because i’m still learning how this puppy rolls. It’ would be great if one day there Editor had enough AI to do it for you!

Having millions of hidden cables for events to all the nodes on the left hand side of the flow could be counter productive. I still am too inexperienced to have a strong view on this.

typing a value into an input port field and without typing return clicking on a new node and the typed value gets lost

Alastair, it shouldn’t get lost though. If you can reproduce it, could you file a bug report with detailed steps and/or a screen capture?

So, if entering a new value into a port automatically updates in the near future…what would one do to enter a value, and then have it update at an arbitrary time?

@George_Toledo, I think we discussed this on Facebook, but to avoid leaving the question dangling here — we’re thinking the automatic updates would be turned on/off with a Vuo Editor setting.  

1 Like

Reading the the topic. One thing I’m not sure of, a bit like Martinus mentioned, when a node already would be connected live, for example a Requested Frameattached to the Time Port of a Curve, changing a port value in “Loop” for example.

If I change the value of “Loop”, it changes instantly and smoothly.

When I refire the port manually, the run button of the editor spins for 1 second.

What’s going on in the background ? When connected to Requested Frame, does the node refires without spinning the start button, or is it managed differently ?

So my question actually is "if the methods are different, will the editor be able to detect that a cable is already connected and prevent the node from refresh + spin (with short pause) ?

Sorry for this basic question, I have no real idea what is going on in the code background.

When I refire the port manually, the run button of the editor spins for 1 second. What’s going on in the background ?

@Bodysoulspirit, in the background, the Vuo Editor is adding an invisible Spin Off Event node with cable connected to the input port. This requires the composition to be rebuilt (recompiled), same as if you were to add a regular node. An event is fired from the Spin Off Event node’s trigger into the input port.

will the editor be able to detect that a cable is already connected and prevent the node from refresh + spin (with short pause) ?

For this feature request, the composition won’t rebuild each time you edit a constant value. Instead, Vuo will find an existing trigger port upstream of the the input port and fire an event from there. Simply firing an event doesn’t cause the composition to rebuild, so there won’t be a pause. With automatic event firing enabled, it should be possible to rapidly edit constant values, including using sliders.

2 Likes

We (Vuo team) have realized that we’re not going to be able to fit this feature into the next release. We’ve made some progress, so I’ve bumped the Complexity rating down a notch. But we still need to figure out some open questions on how to make it behave intuitively and not slow down compositions.

I’m reopening this feature request for voting so we can see how important it is to the community compared to other feature requests. Since this feature request went immediately to “chosen”, I’ll add 20 votes from Team Vuo to represent the folks who commented favorably but never had the chance to vote.

Interested to hear the situations where it slows compositions down unnecessarily. Glad this FR is a step closer to being included in Vuo.  

How about, just put it back as chosen.

Why does inability to implement for this release knock it off of chosen, after the overwhelming positive response…and it actually being chosen.

That has funny implications for the entire voting system.

Can’t it just still be “chosen”, and get pushed to the next release, or whichever one it is feasible to do it for?