Status:
Vuo version:
Fixed in Vuo version:
OS version:
- macOS
How severely does this bug affect you?:
●●●○ — It prevents me from completing a specific task with Vuo.
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?:
No
Compositions:
| Attachment | Size |
|---|---|
 Select Event Input.vuo | 1.27 KB |
Comments
Mmm, maybe there is a purpose
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
micpool, you make a good
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
Whichport onSelect Event Inputnodes.In addition to Bodysoulspirit's nice solution using a custom node, here's another possible workaround using the built-in
Hold Valuenode.ControlEventRateBlockedWhich.vuo
After review by the team, we
After review by the team, we've decided to change the behavior of this node.
Vuo 2.2.1 replaces the Select
Vuo 2.2.1 replaces the
Select Event Inputnodes 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 aSelect Event Inputnode from the node library, it will use the new version of the node.