Option to temporarily disable/turn off nodes

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:

Vuo Composition Building/Editing

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

Submitted by Steve (@smokris)

on 2015.03.24 14:20

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?

Should they act as a black hole, where all events that go into them disappear, never to return?
Or should they continue to pass events through, and output old data from before you disabled the node?
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:

Block all incoming events?
Continue outputting the old blended image from before you disabled it (ignoring the current input images)?
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)?

Attachment	Size
blend.png	4.15 KB

@smokris: Thanks for your

Submitted by @jvolker

on 2015.03.24 14:39

@Steve: Thanks for your reply!

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

If I disable it, it's just as if it wasn't there. Makes sense to me.
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.
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.

@jvolker, yes, I agree about

Submitted by Steve (@smokris)

on 2015.03.24 23:59

Feature status:

Waiting for more information from reporter

Open for community voting

@jvolker, yes, I agree about option 1. Let's proceed with that route.

I'm opening this feature request for community voting.

Thanks! Looking forward to it

Submitted by @jvolker

on 2015.03.25 04:48

Thanks! Looking forward to it.

Voted!

Submitted by Teo (@dumski)

on 2015.04.12 13:12

Voted!

I think that once I can save

Submitted by @kingluma

on 2015.08.04 21:21

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

Submitted by @jersmi

on 2016.02.17 12:56

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.

@jersmi, no, I believe it's

Submitted by Jaymie (@jstrecker)

on 2016.02.19 21:28

@jersmi, no, I believe it's just two options, regular or "black hole" (according to Steve's and @jvolker's comments).

yeah "bypass" could become a

Submitted by Alastair (@usefuldesign)

on 2016.02.20 18:02

yeah "bypass" could become a blackhole of a different sort with nodes that aren't simple Image Filter type operations. Option one is the way to go I think. Although putting in an event blocker node (a wall) could work to as a workaround in many cases.

I'm not sure what you mean

Submitted by @Bodysoulspirit

on 2017.03.20 09:34 and last edited 2017.03.20 09:36

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

Submitted by Jaymie (@jstrecker)

on 2017.03.29 22:25

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

Voted for this.

Submitted by Paul (@pbourke)

on 2017.07.12 08:18

Voted for this. I see it more as a debugging tool, acts as if the node is deleted ... doesn't pass any events and doesn't create any output. Does not need to be saved.