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: 424
20211118.1 sysex control L MIDI feedback bug 2.mididesigner - Updated layout, with sysex strings that work and break with MIDI feedback
Downloads: 421

Images

updated_example_matrix.png

Comments

The example is amazing and appreciated however it’s simply not supported yet. What’s your use case?

---

Ouch, I thought that all controls in MDP2 were designed to handle the same MIDI messages coming and going. :/

---

My use case is that I use channel changers to manage multitimbral devices.  That requires "L" in part-specific sysex controls.  When changing channels, controls must display how the current part is configured, so they need to reflect incoming MIDI.

Basically: channel changer + sysex controls = requires incoming MIDI support for "L"

---

Right, but what are you controlling?

---

I have deleted my original answer after more examination.  All three pickers in a row should follow a change, but they don't.  The only thing I can see slightly suspicious is the use of note on / note off as the channel changer message type.  I would just use cc.  

I have even gone back and checked my prior layouts with L and V to see if they are working, and they are.

Going to sleep on this for a while.

---

Thanks, jkhiser.  I've also found a control elsewhere in my WIP layout that has been correctly responding to incoming messages with L and V; trying to figure out what the difference is to see if I can make a reproducer.

---

I just remembered how we implemented this. There’s no reason why by directional control should be affected just because the control has an L in it. However, if the channel is not set to the right value at time of receive, then it won’t be addressed properly.

Basically, the channel changer just changes the control’s channel for real.

---

I think I've narrowed the MIDI feedback problem down to the placement of "L" and "V" within the sysex string.

I've updated the example layout with a new matrix to demonstrate sysex strings with broken and working MIDI feedback.

---

The Receive Engine, so to speak, doesn’t know it’s a channel changed sysex. Whatever the last value is, that’s as if you entered it in design mode

Not to say you won’t find a bug, gogogo!

---

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?