Steps causing the bug to occur
In the attached workspace
Fire option 3 event in select latest node to change which port in select event node input to 3
Fire option 2 event in select latest node to change which port in select event input node to 2
Changing the which port, itself outputs an event, which is consistent with other nodes, but doesn’t make sense in a node whose sole purpose is to only allow events from the selected input port .
Have you found a workaround?
- Vuo version: 2.0.3
- macOS version: macOS
- How severely does this bug affect you? It prevents me from completing a specific task with Vuo.
Select Event Input.vuo (1.27 KB)
Mmm, yeah on the fly I don’t see any reason either.
In the meantime you can add a wall to the “Which” port on the node yourself.
You can bundle custom nodes into exported apps it seems, so users don’t need to have that node installed.
Joined is that node with a wall and a comp to test it, hitting any keyboard key changes the “Which” value, with a wall, hitting a key indeed doesn’t flash the rectangle layer, same for the exported app.
Select Event Input 1.1.zip (5.05 KB)
@micpool, you make a good point. We’re discussing among the team to see if there would be any drawbacks to adding a wall to the
Which port on
Select Event Input nodes.
In addition to @Bodysoulspirit’s nice solution using a custom node, here’s another possible workaround using the built-in
Hold Value node.
ControlEventRateBlockedWhich.vuo (7.42 KB)
After review by the team, we’ve decided to change the behavior of this node.
Vuo 2.2.1 replaces the
Select Event Input nodes with new ones that have a wall on the “Which” port. This won’t affect existing compositions (unless you go back and edit them). When you create a new composition and add a
Select Event Input node from the node library, it will use the new version of the node.