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.
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 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.
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 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 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.
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.
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
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.
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 me, probably common, it is about a couple things, most likely black hole behavior. One is debugging (ala @pbourke), 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 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) 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.
