Maybe I misunderstand the intent, but surely it's simpler to just send wireless triggers to a common toggle?
tiffy wrote:a better method than the "Tick 25 primitive" I used to allow signal flow to pass through the Multiplexer/Selector combination ??
The trouble with multiplexers is this - when you change the index, only the newly selected output sends a trigger - the unselected ones don't, and so the 'old' output doesn't update its value - unless a trigger from somewhere else forces it to. It might seem odd, but your ticker isn't actually doing anything much to the Selector - it's really causing the Multiplexer to be 'asked' for its correct output value (often described as an 'invisible backwards trigger'!).
In the schematic above, you can see one way to try and overcome this (there are others depending on the application).
The key here is the order that you make links from the index selection, so that a reset value gets sent to the current selection, then the selection changes, then the new value is triggered.
Although it is quite a bit more complex, it is much better for performance - unless they get blocked somehow, the triggers from the 'tick 25' will find their way along links and all over the following parts of the schematic, which can cause unintended effects, and will suck CPU (especially if they cause screen redraws).
Another way would be to extract the trigger from the selection and just send it to all of the outputs to update them all (NB - a module with only a Trigger in -> Trigger out is one of the most useful ever - use it to grab only the triggers from any kind of 'green' link).
However you do it, you can often improve things with a few "changed" primitives to clean up any extra triggers that aren't really needed.