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.
@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?
For example, say you have this snippet:
When you disable this node, should it:
@smokris: Thanks for your reply!
The answer seems to be rather obvious to me. I would definitely expect option 1!
Maybe that’s too easy and not thought through in all directions, from your point of view.
@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.
Voted!
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.
@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 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.
Voted
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
Option 1, disabled node acts as if it was deleted.
Keep it simple.
Any news on this? Such basic important option…
Orbit,
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 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.
– removed comment to prevent confusion; got this thread mixed up with a different thread –
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.