I've reworked that part of the schematic now and it's depressing: The situation is essentially the same although (in my understanding) there is absolutely no reason left why it doesn't do what is expected.
Here a screenshot of the new solution (you don't have to comprehend what it does, I'll point out the details that matter for that problem below):
Here is the problem: The two BSwitchTrigs should let pass the note on and note off event triggers coming from the note extractor only
when the notes are inside a specific range. In order to decide this question one has to do the computation below for each note. As the result of this computation is determined by current value of the pitch bend extractor (a midi based component) and two external values that come from outside the module we have the problem that normal link order isn't sufficient anymore to ensure that the gate of the BSwitchTrig is switched to the right setting before the matching trigger event passes it. (Sometimes the gate has already switched as expected, sometimes it still has the wrong value and the trigger is stopped while it should pass or passed while it should be stopped). So far the old problem. Now I introduced some the tagged datastream concept described here
and added a component (the "intResultWaiter") that only let's pass the triggers from the note extractor when the result of the computation that is based on the pitch bend value that was current when this trigger was sent is available (that part seems to be perfectly working). But now the gate always
is switched too late (the first note that should be blocked passes an the first note that should pass is blocked). So in my understanding the only
explaination for that behaviour is that packing and unpacking of informations in and from busses changes the link order (e.g. if a value should be extracted from a bus and there are other links of higher order then the extracting is delayed for one round and the other paths are executed at least once.) That could be the case e.g. at the place where the the outputs of the not component from the very right are fed into the intResultWaiters (first and second order links) and then into the "Strip Tag from Datastream" component that effectly switches the state of the gates from the BSwitchTrig components. So for some reason (perhaps the reason mentioned a sentence before) the two links from the not component to the intResultWaiters are followed before the link from the "Strip Tag from Datastream" to the BSwitchTrigger boolean input although these have a higher order number and thus should be executed at the second and third place. (The fact that midi components (pitch bend) as well as the external values that are fed in from the module inputs are involved in the computation shouldn't imo be a reason anymore as everything seems to exactly work as expected up to this very right not component where I have to leave the tagged world and go back to "normal" green data components - and at this point no further midi components or module inputs influence the result). Hope anybody can help me out here (perhaps the devs as this presumably requires some deeper knowledge about the SM link order implementation - except I overlooked something, then everybody who sees such a thing is of course more than welcome to point me to it
, many thanks in advange, I have no clue atm. how to continue from here, the tagged concept was my last idea up to now
the current schematic.