link order problem?

[NothanUmber]

Hi,

would be glad for any help. Here a schematic with a special midi component I need. It does fulfill the following functionality:

* The component is made to define custom ranges on a ribbon as on/off toggles for certain functions. For that one can define the pitch of a note from which the trigger range should start and the size of the range in semitones (e.g. a trigger area position of 50 and a trigger area range of 3 would mean that the trigger area goes from d2 to f2)
* The ribbon is touch sensitive and sends a modulation value when pressed. So the modulation value is used in order to determine when the trigger was released (if the modulation value is zero). (just using the number output of the Midi Mono component doesn't work as this jumps to zero between two semitones and the trigger range can be bigger than one semitone)

If one uses the the simulation (with the pc keyboard as midi in and the toggle for switching on/off modulation) everything works as expected: If modulation is on and one presses a key between d2 and f2 the gate jumps to true and the midi note events don't come out at the other side of the "Reset Tune Trigger Area" (they are dropped). If one leaves the area or set's the modulation value to zero then the gate jumps to false and the midi values are forwarded through the module again. That's how it's supposed to work.
Now here's the problem: Plug in a real midi source (ribbon/keyboard etc.) that is able to send note on/note off messages and control the modulation parameter. Now (at least on my setup) it is impossible to filter the midi data if one comes inside the trigger area: Change the modulation value to something different than zero and touch a note inside the trigger area. Now the first midi events (note on, pitch bend, whatever you actually produce) are forwarded through the trigger area component before the gate jumps to "true" and only midi messages that come some fractions of a second later are blocked - but ALL events that where produced while/after the trigger was activated should be blocked, e.g. the note on event with the note number 50 should NEVER EVER reach the other side of the trigger area when the modulation value is bigger zero. Presumably there is some link order problem involved (or a midi thread sync problem, don't know...)

Has someone an idea how I can change the trigger area component so that it's working reliably as it should in all cases?

Greetings,
NothanUmber

[NothanUmber]

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 )

Greetings,
NothanUmber

P.S.: Here the current schematic.

[skOre]

wild!

[NothanUmber]

wild!

Ahhh, I've been searching the bug at the completely wrong end. The "bug" was as simple as nasty: The ribbon sometimes sends the pitch bend event after the note on event what leads to the situation that the gate stays open as the schematic thinks that the last note that was played outside the trigger area was repeated another time. The fact that the order of arrival of the pitch bend event and the note on event changed arbitrarily led to the situation that the schematic was sometimes doing what it should and sometimes not. So all I had to change was to make sure that not the current pitch bend value but the first one that arrives after the note on is stored in the sample and hold. Now everything is working as expected!

Greetings,
NothanUmber