Case Switch Node


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.

I guess another way would be an output that simply is an index of the first logically true match.

One option is to build a Compare and Select Out (Bool) ladder. Another option is to mathematically derive the output from the input with a Select Out (8) node and some maths. This can be more effective in some cases, and a hell of a lot more confusing, depending on where your break-points are set.

Thanks @martinusMagneson

In my mind, this seems the kind of thing that’s fairly common for people doing interactive design—a bunch of heuristics that produce a single value/event out.

This may not be the right implementation, and perhaps a more constrained version that simply defines cut-off limits per ‘bin’ is the right approach. But I do think this is the kind of thing that’s required a lot when building interactive systems, art, etc. And to implement today in Vuo is quite laborious, or simply too abstract for non-developer-minded people.

Forgive if simple-minded, wouldn’t n<1 + n<2 + n<40 + n<400 set up cases 1-4 for input/output selector?  

@jersmi Sorry I don’t understand.

I just mean that in your example you can calculate something to switch cases using Select Input/Output with an expression something like (revised from above):

n<1?1 : n<2?2 : n<40?3 : n<400?4 : somethingElse

(with output from Calculate connected to the “which” port on Select Input/Output).

“Separate flows” as you might say would be one case from each output on an output selector. Or something like this, in my simple brain.

And do say “what about this scenario where it does not work”!  

Thanks — that would work, if each output path started with an Equals node. Nothing about that says ‘no code’ to me.

I realize Schedule might do the trick, although it’s also a non-obvious solution.

Imagine instead that this was a graphical UI tool. Something like a gradient control, or a parametric EQ, where there were many points of decision.

So, if n<2, A and B would both be True?

Is the premise of the workflow below useful for your use case?

By encoding each Less Than condition with a distinct index value via Multiply, you could determine what set of cases are true given the particular numeric result.

I would usually use a system like this more in the context of “Is Equal To”/“Is True”…where the results of each branch of the graph don’t really intermingle. For example… if a given hit test button onscreen is clicked, you get a boolean, you multiply it by a unique int - which then creates a unique index value. Or you feed time to “is equal to”, and then do similar.

However, in the original post, multiple cases can be true at the same time…so it winds up being a little more complex to interpret what the resulting value should mean.  

I loved the Audio Commander (AC) Bit Logic patch in QC when doing more complicated state engine stuff. Here’s a logic state machine that determines if the inputs are odd (Output 1), even(Output 2), exclusively odd or even (Output 3) or both (Output 4):

What you’re asking for, @keithlang looks a lot like @smokris’s Multi-Expression patch in QC to me, was one of my favourite patches along with the stock Expression patch that inspired it. (alas can’t get DataTools to load in QC on Big Sur).

Any Multi-Expression, Math Expression or Case node will be much more powerful if it can accept multiple (user named) variables, preferably the input ports are autogenerated as determined by the Expression(s) input value named variables (can Vuo auto-generate input port names on the fly the way QC did?! if not, not sure how this can work in Vuo :sleepy:)

While the math expression patch might not immediately look like your classic programming language Case operator, use of the logic operators like OR, AND, IF/THEN/ELSE (||, &&, x?y:z) can turn them into just that. Parenthesises are really important in this equation, it will use order of operation to mess with the logic without them!


I don’t think nodes can reconfigure the ports on the fly in VUO. I was thinking about this same thing the other day for a couple other reasons…code editor nodes, multiplexers.

And another thing is that there is no such thing as a Settings panel view.

I think one shortcoming of QC was that parameters were sometimes buried in a Settings panel when it would be more useful to work with that parameter as an input port. So it led to a bunch of criticism of the Settings panels, and the idea that everything should be able to be accessed by ports.

But looking at a Settings panel on/off grid like that, consider what happens in the settings panel in the Timeline patch, the settings panels in the pics above…considering there is no reason one couldn’t have a more highly developed custom view that might not even be able to be represented as input ports at all…there are valid arguments for each type of workflow. Whether or not it any of that makes sense for the VUO system is another question I guess.  

Yes, @George_Toledo I recall all the discussion around the “⌘2 Settings Panel” and it’s drawbacks and advantages vis a vis Vuo back in the day.

I didn’t think Vuo could have nodes spawning new ports or rename on the fly — but didn’t want to assume, I haven’t really used Vuo 2 much at all.

I wonder if it would be possible without major reworking of the front or back end of Vuo, @jstrecker & @jmcc?

As for a “settings” or custom UI (eg. a timeline animation node) input panels and the like, in special cases like any of the requested code nodes (C code, GLSL code, scripting node) I would think something would have to happen in that department, then maybe other custom setting panels will be more within reach for @teamVuo?

The only thing towards this I’ve noticed in Vuo so far is the ShaderToy node pop up GUI for editing/copy/pasting the shadertoy code. I guess it’s potentially one way to do it with “pop-ups” but perhaps that would mean only Vuo developers and not end users would get to play with the UI if that’s how custom UI panels gets done. The ShaderToy node recompiles immediately — which is lovely! (sometimes I find i need to fire an event into the code port to trigger recompile).  

Now I think about it, maybe the ShaderToy node configures input ports on the fly if you create or delete an input variable? So after it compiles any changes to the code? Or maybe it doesn’t which is why there are 4 “Channel” image inputs unused in the sample comps?!

Edit> Looks like ShaderToy cannot configure input port names on the fly on recompiling the code rereading the manual.

This functionality under the hood will be needed in the requested C and GLSL nodes. Can’t see any way around it.  

perhaps a more constrained version that simply defines cut-off limits per ‘bin’ is the right approach

@keithlang, I could see both a constrained version addressing a specific use case and a more general-purpose version both potentially being useful additions.

Looking at your original example above, for the constrained version, would the list of cut-offs be 1, 2, 40, 400?

In my mind, this seems the kind of thing that’s fairly common for people doing interactive design—a bunch of heuristics that produce a single value/event out.

Could you give some concrete examples of how you’d use the node? If we can picture it in the context of a composition, looking at what its inputs and outputs would be connected to, then the answers to questions like single output vs. multiple outputs will probably become clearer.

Thanks for the comments, @jstrecker. Would you be able to shed any light on the speculative comments in this thread about nodes dynamically setting input ports? Changing the names, adding additional port, removing ports where the input variable has been removed from the expression or C/GLSL code?

Is that functionality a show-stopper ATM for nodes that would need it, or is it a relatively simple change to the Vuo Editor to do something like that?