jvolker's picture

Submitted by on

I would like to be able to disable nodes temporarily.

Just like in any textual programming languages you sometimes want to keep things you've done before for later use or reference, but don't want to delete it. Which can be done by uncommenting lines.
It would be great to have the same option here, where all nodes are visually preserved including their lines, but their functionality becomes inactive. Maybe this state can be indicated by out greying those nodes and lines.

Component: 

Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo and Vuo Pro licenses

Complexity: 

●●○○ — A few weeks of work

Comments

@jvolker: Cool; we agree that

smokris's picture
Submitted by
Feature status:
Waiting for review by Team Vuo
»
Waiting for more information from reporter

@jvolker: Cool; we agree that would be handy (it's been on our to-do list for a while).

One logistical issue we haven't figured out yet — how should disabled nodes behave?

  1. Should they act as a black hole, where all events that go into them disappear, never to return?
  2. Or should they continue to pass events through, and output old data from before you disabled the node?
  3. Or should they somehow pass current data through without modifying it? But what if the inputs and outputs don't match up?

For example, say you have this snippet:

When you disable this node, should it:

  1. Block all incoming events?
  2. Continue outputting the old blended image from before you disabled it (ignoring the current input images)?
  3. Output one of the current input images? But how do we decide which one to output (and how do we decide this in the general case, for all nodes)? What if none of the input ports have the same data type as the output port(s)?

@smokris: Thanks for your

jvolker's picture
Submitted by

Steve (@smokris): Thanks for your reply!

The answer seems to be rather obvious to me. I would definitely expect option 1!

  1. If I disable it, it's just as if it wasn't there. Makes sense to me.
  2. Don't think that's a good idea. If I restart the application, in what state are those nodes in? This could be confusing. They are deactivated and so shouldn't show anything.
  3. If I wanted to have direct lines between input nodes and output nodes I could create them (and disabled them, if not needed).

Maybe that's too easy and not thought through in all directions, from your point of view.

I think that once I can save

kingluma's picture
Submitted by

Maybe it's a slightly different request, but I think that once I can save / export a comp to use as a self contained node or something roughly equivalent to the Quartz Composer create macro command (which is a different Vuo feature request listed here on the website), then I can build my own "bypass" feature that would give appropriate / desirable behavior options for each node I make / customize - otherwise I agree that depending on the type of node or the context the desirable behavior isn't always clear - for example what I was just wanting was a bypass for straightforward video processing nodes where events and the unfiltered video would pass through (without me having to recable or create a switch using additonal modes)... but I can see how for other kinds of nodes I might want a different behavior... but I'd be happy to build such switches / alternate behaviors if I only had to do it once and didn't always have to look at them taking up screen space - hence the save / export a comp to use as a self contained node feature (with the ability to publish, name, and define ranges for parameters to that node and step in and out of it from the "parent" comp to make adjustments etc.) would give me what I want : )

If I understand correctly, I

jersmi's picture
Submitted by

If I understand correctly, I would vote to have the ability to choose from three states for most things in a comp, something like "Process", "Disable" or "Bypass", to allow disabling or bypassing hungry areas of a composition as needed.

I'm not sure what you mean

Bodysoulspirit's picture
Submitted by

I'm not sure what you mean with "regular" beside black hole Jaymie but from the question Push rendering optimisation I still could think something like "allow data to passthrough without modifying it" could be cool.

Perhaps the available options could be hardcoded in the nodes because for all nodes that have 1 single input / output that would still be cool. And as Jvolker stated "what state would those nodes be in when I restart the application" I assume compositions could save the state just like other ports, exported apps would need some kind of preferences plist or something ?

Why would the 3 states not be possible generally, but some nodes only have 1 or 2 of the 3 ?

But if a node had a bypass like "continue to flow the data without modifying it", would the node still have to process or will it not process and therefore spare hardware usage ?

@Bodysoulspirit, I meant that

jstrecker's picture
Submitted by

@Bodysoulspirit, I meant that the tentative plan for this feature request was to provide just 1 way of disabling a node (the "black hole" behavior). So a node could either be enabled or disabled.

The issue of "what state would those nodes be in when I restart the application" is that when you restart (meaning hit the Stop button and the Run button) the composition starts fresh. It doesn't carry over data from the previous run. (The ability to save state and resume later is covered by FR A UI for storing and loading the state of running compositions.) If nodes had the ability to continue outputting their current data when disabled, then things would work OK if you ran the composition and disabled the node, but the next time you ran the composition the node wouldn't have any meaningful data to output.

I guess it would be possible, though probably beyond the scope of this feature request, for certain nodes, when disabled, to optionally pass their input data through to the output without processing it. For select groups of nodes (image filters like Blur Image and Ripple Image, for example) the expected behavior seems pretty obvious (don't filter the image). For a lot of other nodes, it's either not so obvious (like Blend Image, as pointed out above) or, even for many 1-input/1-output nodes (such as Convert Text to Image), not feasible.

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

50 votes so far!
Vote

Who voted?

pbourke's picture
jvolker's picture
dumski's picture
parker's picture
zzkj's picture
timwessman's picture
mixfilet's picture
bLackburst's picture
Philternaut's picture
alexmitchellmus's picture
Bodysoulspirit's picture
scrat's picture
jersmi's picture