How to deal with MCU messages

0 votes
asked Feb 8, 2024 in Advanced by the-elf (1,190 points)
edited Feb 8, 2024 by the-elf
Got something, but prolly won't get posted until tonight.  First solution seems to have found a new SB bug, but there is a second (and third) way to address.  The original SB is trivial, but fortunately decided to test it before posting.

3 Answers

0 votes

So the problem is the status message format and the command message format are incompatible.

Status is 90 13 00/7F where command is repeated 90 13 7F

One way is to split the command button and status indicator.  Status button would be no touch in play mode.

Another is to use StreamByter to trap any of the 90 13 00s and convert to 90 13 7F.  

BUT - appears StreamByter seems to dislike the Note On / Note On message, and changes all zero velocity Note Ons to Note Offs.  Was what was causing me problems this morning.

In other words, SB converts all 9x xx 00 messages to 8x xx 00 messages before processing.

Once I got this figured out, solution is straight forward.

In the above case, we need the one line of SB 1 code

80 13 00 = 90 13 7F

(Seems the code should be 90 13 00 = 90 13 7F, except as soon as SB sees the On/On message, it converts it to the 80 xx 00 On/Off format)

The downside is that ALL zero velocity note ons in the output stream now get converted to note offs, just by going through the SB code.

This line converts all note offs back to zero velocity note ons

80 XX 00 = 90 XX 00

If you have a mix, you may have to add more code to specify which remain On/On vs On/Off.

To convert all On/Ons to the toggle format, use

8x xx 00 = 9x xx 7F

Caution - don't ever use this last conversion in a layout processing "real" note data, as you are going to end up with a ridiculous number of stuck notes.  Prolly safer to just target the specific cases you need for MCU control.

(Somewhere lost in my memory seems there might be a configuration setting for SB that controls this On / On behaviour, but sure cannot find it in the SB documentation or Audeonic Soapbox.  Or maybe Nic just didn't like Hash House Harriers)

answered Feb 9, 2024 by jkhiser (19,810 points)
edited Feb 9, 2024 by jkhiser
I've tried splitting the button and status indicator, as suggested. The separate indicator does seem to reliably reflect the state of mute in the DAW when using the accompanying button (set to now not receive MIDI). That's the good part...

But I have to say that it seems a bit naff to have a separate indicator button for every control button. I'm getting this problem with such as the Play and Stop buttons on the control page also. It would mean having to have indicator buttons everywhere. The design is pretty tight as it is, so having to have all those indicators doesn't really fill me with joy.

I don't recall having this problem before, so I'm wondering if this is a problem introduced with a new version of MD at some point, and I've missed the moment where it started behaving this way.

What I need is a button that sends out a message, but only reacts to an incoming message to set its lit/dim state.
0 votes

Finally found the command to tell StreamByter to NOT remap On / On to On / Off.

set NVR 0

So now we just use

Set NVR 0
90 13 00 = 90 13 7F

and ignore most of the first answer.

answered Feb 9, 2024 by jkhiser (19,810 points)
Thanks for helping out.

I'm afraid this didn't work. My button remained unlit when pressed, though my DAW reacted as it should. Triggering the mute in my DAW now lit the button, but un-muting no longer dimmed the button, since it was only ever now receiving Velocity 127.

I backed the SB code out.

I've changed the image at the top of this post to show the log of pressing the button, the data it sends out and receives, yet the button remains dimmed. I've also uploaded the Layout in question (though it's been named weirdly!). I'm guessing any MCU-compatible DAW (I use Cubase) would react the same.

I'm wondering if this is a timing problem - that pressing and releasing the button is masking the response to the incoming Velocity 127.
0 votes

Make your mute buttons toggle, turn off send on only, ensure they are all Note ON / ON.  

With those changes, the mute buttons works fine here against a simulator.  Timing doesn't matter, the inbound message takes control of button state.

To change all eight mute buttons output to 7Fs with one line, use:

Set NVR 0
90 10-17 00 = 90 XX 7F

Re: What I need is a button that sends out a message, but only reacts to an incoming message to set its lit/dim state.

That is essentially what is happening once you make the changes above.  As configured, the natural button state normally will match what the DAW is sending for status.  If they get out of sync, the DAW status will flip the button to the correct condition.

p.s., check your knobs that are used only for grouping buttons.  You prolly want them NO MIDI SEND / RECEIVE to preclude random surprises elsewhere in your setup.

answered Feb 10, 2024 by jkhiser (19,810 points)
edited Feb 10, 2024 by jkhiser
Thank you! I think you have hit the solution, but that SB code is not needed - in fact, it causes a problem, because with that code in place it takes two button presses to un-light the button).

But 'Note On/Note On', disabling 'Send On Only' and 'Toggle' seem to solve the problem. It's also solving trouble I was having with other buttons, such as Cycle on/off.

The final SB code I've ended up with is:
Incoming:
SET NVR 0

Outgoing:
SET NVR 0

9X 00-07 00 = 9X XX 7F
8X XX XX = 9X XX XX

The Outgoing code mopped up problems I was having with Channel Select, followed by unsetting the selected channel's Record status, and also my Rewind/Forward buttons. Not sure why I need both the first and last lines, but the Layout only works properly with both in place.

Everything I've tested now seems to be working as it should. I'll re-upload the Layout.
The important thing is that you found a group of settings that works with your DAW.  MD is flexible enough that most situations can be addressed, even differing control and status commands on one control.

If the only line in incoming rules is the SET, you "should" not need it.  Without any code, SB "should" not process any commands.
Sure enough. Thank you for your help. I think an MCU control surface is an important Layout to have in MD's armoury, so I was determined to bring it up to scratch. I'm already considering improvements.

I still don't understand why I need both 'Set NVR 0' *and* the 8X line in my outgoing code, but I'm shrugging my shoulders and moving on...
re: I still don't understand why I need both 'Set NVR 0' *and* the 8X line in my outgoing code, but I'm shrugging my shoulders and moving on.

They are doing two different things.  
1. NVR prevents SB from converting the zero-velocity NOTE ONs, needed by MCU, into NOTE OFFs.  
2. The 8x xx xx is fixing some of the controls that were coded with ON / OFF to ON / ON.  If you convert them to ON / ON you don't need that line of code.
Yep, makes sense. I'm making the required changes.
...