Sysex controls with "L" value don't respond to incoming MIDI

Question

Controls with an "L" in their sysex string don't respond to incoming MIDI feedback, but they do if the sysex string is hard-coded with the same value.

Update: Some controls with an "L" in their sysex string DO respond to incoming MIDI feedback.  I've updated the layout with examples.

Downloads: 161
20211118.1 sysex control L MIDI feedback bug 2.mididesigner - Updated layout, with sysex strings that work and break with MIDI feedback
Downloads: 158

Images

updated_example_matrix.png

Comments

Dan,

Please look at the updated layout's matrix of examples.  It demonstrates that the problem occurs based on the position of "L" (and maybe "V")  in the sysex string—not how the channel was set.

FWIW: Each control uses the same channel (02d/01h), set by different means in each column (left: channel changer, middle: design mode, right: hard-coded into the sysex string without using "L").  Consequently, all pickers in the same row send identical sysex messages from the same ticks.

Using a MIDI loopback, changing the value of any picker should cause the other two in its row to change to the same value.   But that's not always what happens, and the only difference between each row is the position of L and V in the sysex string's format.

With this format, all controls respond correctly to incoming MIDI:

[F0] 22 22 L 22 V [F7]

With these formats, controls with "L" in their sysex string fail to respond:

[F0] 22 22 22 22 L V [F7]
[F0] 22 22 22 22 V L [F7]
[F0] 22 22 22 V 22 L [F7]

With all these formats, controls with hard-coded channels (and no "L") respond correctly.

You'd mentioned that a directional control shouldn't be affected just because it has an L in it, so this really looks like a bug.

---

Thanks for this. The issue here is probably with the variable bytes that make up a V (receive engine doesn't know what's a variable byte or not, nor the length). That said, let's just assume that there's a bug here to move the conversation forward. What I need is the SIMPLEST possible way to show the bug (test case) so that we can possibly fix it. If L isn't needed, then it's not part of the example. I don't need 3 examples (nor 10) if one will show it.

I have a web link somewhere about the "simplest possible example" but you get the point... This is the problem, fix this and it's solved, etc.

Once that's done, we can put some estimates on fixing it, and even then it might take a long while to fix. Note that you can work around with SB always, so that's a work-intensive option.

---

Also again thanks or diving into this. It'll be good to get this documented, even if it turns out to be extremely difficult to fix (but probably not).

---

(Edited)
Current working theory - need to check if this holds:
It works when L is before V, and there is at least one non L/V value preceding and between L and V, or for standalone L V or V L.

These cases work
L V
V L
NN L MM v, where both NN and MM are > 0 lengths of fixed bytes

These cases do not work
NN L V
V NN L

Finally, matching a subset also works, eg nn L NN V2b will also control  NN L NN V1b (the control doesn't care there are extra bytes past the match)

See if this matches your results.

---

Hmmm... so there are cases that don't work where the L is before the V?