jvolker's picture

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.


Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo CE and Vuo Pro


●●○○ — A few weeks of work


●○○ — Appeals to current community


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


carlitos's picture
Submitted by


I would consider option 3 And see this as a “mute” or “bypass” - where input signal passes through unaffected Switching it on and off then lets you quickly see the difference, with or without what the node does


jmcc's picture
Submitted by


Yes, we can see where this would be a great option to implement. We consider several factors when deciding how to schedule a feature request, including community votes and our estimation on how much a feature might make Vuo useful to more people. At this time, we're not planning to schedule this ahead of other feature requests that have received more votes.

Late to the party but here's

keithlang's picture
Submitted by

Late to the party but here's my 2c

RE the 1 vs 2 vs 3 here, I would opt for 1. = Black hole.

Later on, Vuo could add additional functionality.

One problem I see with the current workaround (using a switch between an image-generating node and the Rendering node) is that the image is retained. Ie, even if I switch the input to be null/no connected thing, then the layer is still visible. Alternatively, I switch to a fully transparent layer…which makes me wonder if there's a performance hit to render something which is actually invisible.

My preference would be that the layer/image would disappear from the rendering view as if it had never existed.

Wishing for this again. For

jersmi's picture
Submitted by

Wishing for this again. For me, probably common, it is about a couple things, most likely black hole behavior. One is debugging (ala Paul), i.e., disabling a section that might not be working, or if a comp has passed the threshold of computer processing power. The other is for show time -- being able to have multiple sections of a comp, tested and working, with only one part enabled at a time.

Regaining computer resources is paramount. What is the current way to set up a bypass that saves resources? For ex., say I have A and B parallel processes, same data type, that gets (re)combined further down the chain. Can I effectively take section B offline by blocking incoming events, say using Select Inputs/Outputs on beginning/end of the section? Is this blackhole-like? Sorry, don't have a comp to share but it'd probably be easy to set up.... I guess the audio synth comp posted in the gallery has an attempt at this with the "low drone" section.

In reverse of QC (seeing as

useful design's picture
Submitted by

In reverse of QC (seeing as we both did a lot of QC composing) no events arriving at a nodes ports means no trigger to evaluate. The last values it propagated still sit on the input ports of other nodes though (as far as I understand it) until re-triggered for a new evaluation. Leave for others to clarify that.

Unlike QC, Vuo is push evaluation not pull, so we might need to isolate at both the beginning of the sub-composition(s) to block event propagation and also at the multiplexer or whatever node that recombines the sub-composition data into your main flow.

I would like to (dynamically)

useful design's picture
Submitted by

I would like to (dynamically) enable and disable the Display Console Window node as a debugging tool for sub-compositions I will use over and over (and so don't want dozens of Console windows).

Being able to disable certain nodes dynamically (rather than in the Vuo Editor canvas) with an Enable boolean port would be the simplest way of enabling this from a UI/UX perspective I think.

Maybe we can start seeing this input on a few important nodes rather than every node in Vuo if that reduces the complexity and time estimates for this FR?

So long as certain key nodes could be disabled, other nodes in the chain wouldn't have any impact on the composition state. Although The OP is the ideal option.

I'm looking for a dynamic option, the OP may have been just for some command in the Editor to do this non-dynamically?! For example you right click on the node and there is a Disable/Enable menu contextual item? If that is the case jvolker, I'll post my desired functionality as a seperate FR.

Feature status

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

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.

If anyone would like to help this happen sooner, we're also accepting open source contributions and commissioned work.

Read more about how Vuo feature requests work.


267 votes so far!

Who voted?

pbourke's picture
carlitos's picture
jvolker's picture
dumski's picture
Kewl's picture
parker's picture
zzkj's picture
wilsyl's picture
mixfilet's picture
siakal's picture
rorypickering's picture
DRDN's picture
wiredv's picture
VideoTTH's picture
bLackburst's picture
useful design's picture
Philternaut's picture
alexmitchellmus's picture
scrat's picture
jersmi's picture
Luiz Andre's picture
cwilms-loyalist's picture
visiophone's picture
timwessman's picture
DetAndreTeatret's picture
Joëlle's picture
2bitpunk's picture
vidbeat's picture
Bodysoulspirit's picture
krezrock's picture