I found myself struggling a bit to work out the logic for an IF-ELSE kind of statement. Eventually I worked out a solution (See pictured). I’m an OK developer, and extremely QC noodler. However, this one was a bit of a brain twister, for what is rudimentary in code.
What I’d love is an Are Equal patch that has an Else output.
If you want to filter an external event stream from another compared-if-equal list is true, I would do it the way you did it too.
If you just want to output an event from either false or true, until implementation of this request, you can try an attempted custom node I uploaded to the custom node gallery (and joined in the composition below) (must be in the same folder as your composition in a sub-folder called modules, or install it system-wide in your Vuo User Folder, or embed it in exported apps).
PS : As you can see I only used “event-only” wires (shift-drag) from the output ports, to avoid feeding the boolean data (which would be converted to reals) into the Count node.
Are Equal with Doors 1.1.zip (5.22 KB)
Oh, this is great, thank you. I didn’t know the shift-drag wire-only trick.
Couple of thoughts from someone relatively new to Vuo, so forgive my n00bness…
I cannot understand why this is not a standard node? Seems like the simplest thing ever, but is technically tricky so solve for otherwise
I find managing nodes (add to user library etc) a little unintuitive
The thin/thick wires make sense to me since I remember the concept from MaxMSP back in the day (bangs?). The concept in Vuo must make this pretty difficult for ‘virgin’ users to understand. Especially since it’s a pretty foreign concept in code. I don’t have any suggestions, but hope it’s helpful to hear a new user’s impression. Easy to be a critic, I know! 
Mmm, yeah, great feature request to submit. Don’t know how the perfect node for this should look but I thought I could give it a try until official request implementation.
The node managing I find hard a bit hard too. There is a related feature request if I’m right to load custom nodes not only in specific folders.
And I also remember speaking with a team member about double clicking a custom node to install it, instead of moving it manually (would need to be a compiled node though as opposed to my c code node. Will create that request).
Also it annoys me the go to the User Library menu shortcut in the menu bar only appears in Vuo when an editor window is actually open.
For the thin wire, mmm, don’t know any better way though one could symbolise big data+event wires, from thin-event-only ones. At some point a software can and should always be simplified and made better for a better grasp, but a software that allows a certain complexity of tasks will always have a certain degree of complexity one should learn, is it not ?
@Bodysoulspirit instead of thin and thick I suggested dashed or dot-dash-dot-dash like architectural/engineering drawings use. But yes, @keithland, the concept of events, triggering and event flow is not as straight forward for novice users as one might hope. It’s inherently a little bit complicated, I can’t see any way to simply it, other than build a pull evaluation Vuo mode on top of the existing one (which was talked about in the early days). Push-evaluation gives more discrete control of performance optimisations, and was chosen for that reason. Sometimes you don’t want a node firing off every time the screen refreshes (say 30 or 60 Hz) — if it takes 0.1 seconds or more to execute there goes your screen refresh rate.
If it’s numeric (not say text or list comparison) the Calculate node has If, then, else logic. This example is from the node library explanation text.
For QC users the equivalent is Math Expression patch, one of my favourites of all time which Kineme suyperchared!
Related Feature Requests:
Edit node C code in the Vuo Editor have it do all the Qt wrangling for the node
Allow more data types in Calculate node
There’s one about loading user complied nodes IIRC but cannot find, I think you find that the documentation does cover loading 3rd party nodes pretty comprehensively.
@useful_design “Edit node C code in the Vuo Editor have it do all the Qt wrangling for the node” will definitely be cool ! Will put more people to code nodes for Vuo I hope, and make edits real quick.
But now that Vuo already supports .c files, have you tried making changes already ? Really easy, if you make some changes, you can just duplicate an existing Vuo node, put it in the User Modules folder, and I open them with the Atom Editor and each time I hit cmd-s, they get automatically reloaded in Vuo, without having to restart anything.
And for .c nodes already in your User Folder, clicking on a node in the Node Gallery there is an “Edit Node” URL that automatically opens it in your default editor.
I ended up with this solution, which I’ve attached. Is there a way I could have made this a double-clickable installable node, btw? 
keithlang.areEqualElse.vuo (2.01 KB)
You also have the became nodes. With became true/false and select latest you can essentially build if/then/else statements pretty easily. If you want to nerd out and avoid if/then/else statements as much as possible (efficiency), there is also the scale node that can be pretty fun!
Thanks Magneson, I appreciate the thoughts!
The problem, I imagine, with Became False is that it will not generate an event if there is a false event followed by a false event. Using Scale seems like a pretty…artful… 
way to solve the problem which would involve calculating the threshold point for two numbers…I think.
I think the fact that this is producing all kinds of suggestions is quite…telling. I’m going to double-down on IF-ELSE becoming a standard Vuo node!
That is true, it will only trigger on a change. To constantly feed events forward to either port, you can just use the “Select Output (Boolean)” node which is even simpler and will pass through data on an event at either in-ports! :) If you search for “select” there are loads of different select nodes that should cover most needs.
(The scale method is more fun though :D)
you can just use the “Select Output (Boolean)” node which is even simpler and will pass through data on an event at either in-ports! :)
Damn it Martinus ! True ! I thought I tried that when trying to help @keithlang and there was a problem. Seems that is what he came up with in his latest subcomp.
So I pretty much made this Are Equal (with Doors) node for nothing. Only benefit is it includes the “select output” inside the “Are Equal” node. But all this just to save 1 node ain’t funny :)
Oh, and I really appreciate the effort @Bodysoulspirit 
! I tried to install it to my local library, hit some problem, and decided to fall back to making a sub composition instead.
Thanks @bodysoulspirit I wasn’t aware of those updates making compilation on the fly a thing. I’ll have to learn some C one of these days. There’s a lot I wanted to do in WC but never learnt Obj C to do it. And it had JS and Lua as a rough hack.
Was meant as a joke about not being funny ;) I always learn something from making nodes.
I have just uploaded 2 more nodes : If True, Else and If True, Else (Events).
To download here : Other logic utilities
Basically it does do what you want if I’m right, although you still need to compare if values are equal, so it doesn’t save you a node (whereas the node I uploaded yesterday which I renamed to Are Equal (If, Then) does both actions in 1 node.
As Martinus said and as you figured out, you can do this with Select Output but it was fun to try to make it, and it may help some other people.
I tried to install it to my local library, hit some problem, and decided to fall back to making a sub composition instead.
Regarding that, compiled nodes like Martinus make, you can double-click to install. Whereas raw . c nodes like mine, you have to manually drag and drop them in the User Modules Folder, accessible from the Menu Bar in the Vuo Editor (see screenshot, or manually by browsing the Finder in User > Library > Application Support > Vuo
@useful_design
Before creating some nodes in Vuo I did not ever write a single line of C code ;)
I just look at the source code, and build from there, learning C, from a visual coding tool ;)
To reiterate the important bits from earlier on this thread: Vuo has two families of nodes that are equivalent to “if-else” in text languages: Select Input and Select Output.
As the composition below shows, Select Input is more like a ternary operator or functional-paradigm if-else that “returns” one of two expressions. Select Output is more of a procedural-paradigm if-else: if true, do this; else, do that.
More examples are in the manual: Do something if one or more conditions are met.
There isn’t a combined node that does both the equal-check and the select. The trouble with adding that is there are so many combinations: 5 variations on the Are Equal node X 9 variations on Select Input X 9 variations on Select Output. (Feature requests Select and OSC nodes with variable number of ports and Lists within lists should get it down to 4 variations on Select Input and 4 on Select Output.)
If you have one combination that you use most of the time, then your best bet would be to create a subcomposition and add that to your node library (as you already did). For a general solution, I don’t know that there’s one combination that is the best choice for most people most of the time. Right now there are already so many if-else nodes in the node library that adding more wouldn’t necessarily make things any easier for novices.
Is there some way that we could improve the node library search, documentation, or example compositions to make it easier for others searching for if-else to find a good solution?
IfEqualThen.vuo (5.81 KB)
Thanks @jstrecker for the thoughtful response. Whilst looking at those docs, it really makes me wonder if some of the issue comes from what is often one factor needing to spread its influence to many places. For example, some app/composition ‘state’ (say, if the user was in ‘record mode’ or ‘playback mode’ or something).
Looking at your example: https://doc.vuo.org/2.1.2/manual/image-generated/IsMouseWithinIntersectingRectangles.png
…which makes my eyes boggle a bit 
I’m sure this has been tried elsewhere, or is perhaps a daft idea, etc, etc. But I’d love if there were a way to group, say, columns of nodes to have a shared scope, in order to clean up some of this wiring?
@keithlang, yeah, I could see that being useful. I think implementation would consist of this feature request (just created), with the ability to hide published cables within an expanded subcomposition. Plus this one for more flexibility.
(Marking this feature request “tabled” since we’re not planning to add another node in the if-else family.)
