Talk to other MIDI Designer users about MIDI Designer, iOS MIDI and related topics. Or share layouts, pages, and ideas.

Check out our Facebook Group.

Of course, if you want to send us an email, feel free.

New! Consolidated performance observations

NEW! Summary of user requests

MIDI Designer
Design your perfect MIDI controller for iPad, iPhone, and now on M1 Macs
Sysex controls with "L" value don't respond to incoming MIDI - MIDI Designer Q&A

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

0 votes
asked Nov 16, 2021 in Defect (Confirmed, Not Fixed Yet) by 5din (590 points)
edited Nov 18, 2021 by 5din
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.
...