I'm currently needing to build something like this—where I'd like to route flow depending on conditions. In Vuo, this can be quite tricky to do.
In code, you'd use something like a Switch statement. Where the logic would compare each statement until it finds one that is true and then compute that flow, else follow the Else flow.
It seems like a generally useful flow…since lots of interaction design is based on various flows with some heuristics to decide on behaviour.
I'm not set on the name or implementation, but hopefully the basic desired function comes through.
I have to go try building something like this now, but it's not going to be easy to achieve.
Working on a large Vuo composition, I find myself using, ahem, Find, a lot.
Currently, when Find shows a search result, it seems to pan the current document in way so that the word is on the screen somewhere (minimal amount of panning to show it?) This will often mean the result is in the corner of the screen.
Not sure if this is a behaviour macOS gives for free, but I'd much prefer if the result was always in the centre of the screen.
Especially with the very subtle highlighting, I find it sometimes hard to spot the result.
So I am building a number of large Vuo compositions, spending many hours in Vuo every day.
I find that the result of anything that has interactivity tends to get very tiresome and fragile to work with.
This is, because from my experience (and yours may be different) the main cause of wires that runs across the composition in a crazy way, tends to be contextual information and internal states.
For example, this may be:
the current app window. Many patches require this, in order to know current rendering size, or for mouse input
Various variables/states of the app. For example, is something active, or in a current performance mode. This often has cascading effects in a bunch of things buried at various places
There are cases where it may be more efficient to reference a single node (say mouse position), but it's far more convinient to simply drop in another Mouse node. Is this costing efficiency? I don't know.
The solution, at the moment, is to add a Share node and then drag that to the spot where it's needed. Potentially hiding the connecting cable as well.
This has many down sides.
It's very labour intensive to create a new node, name it appropriately, drag it potentially a long way, connect up, and so forth
Error prone: the nodes need to be copied each time, and named accurately initially otherwise they might be assumed to be something else which is now duplicated requiring manually renaming across a big document
inconvenient. If you want to utilise one of these commonly shared values, you need to remember what it was called and find it in the Vuo composition and go through the steps again
If you DO choose to hide the cable, then it can be very tiresome to unhide, follow the cable across a large composition to check that it is in fact connected to what you think it should be and rehide it.
Now, of course, in code/language-based programming this is handled by variables inside a certain scope.
In Vuo, of course, knowing the order of functions is important to the graph, so there are cases where you can't simply connect the output of node X to the input of node A. However, it is always possible to use a Spin Off Value (or Event) node, accepting that you no longer will have exact serial/synchronous processing.
In Quartz composer I seem to remember some third party node called 'Broadcast' or similar that allowed for this.
I'd love something similar in Vuo. Perhaps it can be smart enough to warn me if the current instance breaks processing order, so there's (invisibly) a Spring Off Value/Event inserted.
The benefit of having a small set of easily accessible (and choosable from a list) variables for lack of a better term I think would have a massive impact on the ease of building any larger Vuo composition.
Perhaps there's some way of doing this today. If so, please let me know and forgive my ignorance.
