multiplexer/selector bug

[tester]

I noticed, that:

A) when multiplexer/multiselector has connected mono4 streams (don't know, maybe it's general problem with streams),
B) then if I create passive switching, i.e. add trigger blocker to selection input
C) and after that - green trigger, sending "zero" value to any stream input (to activate switching)

then:

1) multiplexer/selector visually swtiches between stream inputs (if no green tigger is sent via zero value, then passive switching does not shows it for streams)
2) but physical stream is not switched however to another one.

It will take me a while to extract this part, to show it. Busy with other things. I came to that issue, when trying to create discrete switching between streams, to avoid resets "code" boxes to initial position during switching. It works when multiplexers/selectors acts wth greens.

[trogluddite]

trying to create discrete switching between streams, to avoid resets "code" boxes to initial position during switching

Even without this "bug", that still wouldn't work, though.
The reset is caused by detecting changes to stream routing, not by the selector/multiplexer seeing a trigger or value change at the selection input - effectively, the change of routing is treated just the same as if you manually edited the links in the schematic.
There cannot be a stream routing change without a reset - or more properly, without re-compiling the code that runs the stream components (some components don't reset because they have no "initialise variables" section in stage(0)).
I think that it is done like this to save CPU load. Rather than the code having to make a decision on every sample ("Does component 'X' require processing?"), the code gets "edited" so that the line "process component 'X'" is added or removed, depending on the current routing. That will make the code much more efficient because lots of decisions and 'jump over code' commands are not required - but, just as with manually writing code, you have to re-start the code for the changes to take effect.

So, yes, the select/multi is being odd - but the behaviour that you want would not be possible with the current system. Really, the bug is one of these two things...
1) Stream inputs are usually insensitive to triggers - so the display is in error and should not show a switch over that hasn't really happened.
...OR...
2) When a trigger comes to the input, there should be a "reset" to force the code to re-compile the new stream routing.

[...OR...
3) A whole new stream routing engine that doesn't require code compilation to re-route signals! ]

[tester]

Well - I thought, that maybe this recompiling is "partial" somewhat, i.e. I tried to quiet down resets on secondary route, not connected to sound output, but just to "some" processing (and not overloading CPU). Another point to add to manual in "Nuances" section - "...due to programming environment limitations..."

[Tzarls]

[...OR...
3) A whole new stream routing engine that doesn't require code compilation to re-route signals! ]

I don´t think we´ll ever see that kind of thing. FS (SM) relies on a "monolithic piece of code" principle to avoid function calls. That is, everytime a routing change is made, the whole processing tree has to be calculated in order to know how the flow of code should be arranged. Once (and only when) all pieces of code have been collected into the "big code", compilation takes place. That way primitives (or branches with primitives in front) with their outputs not connected to anything are not included in the big code, which in turns give us CPU savings.

Actually I can think of a way to avoid having recompilations everytime you change routing via a selector, but that would involve having all primitives working, even those with outputs not connected. So it would be a trade-off between CPU usage and "hickups".