I’m going to paste screenshots of my BMT. For context, the MCU output from my DAW (Luna) is set to use ‘Bome MIDI Translator 1 Virtual In’. Within the BMT router, I’m routing ‘Bome MIDI Translator 1 Virtual In’, as a split, to ‘IAC Driver BMTtoHWController1’ and ‘IAC Driver BMTtoStreamDeck’. ‘IAC Driver BMTtoHWController1’ and ‘IAC Driver BMTtoStreamDeck’ then each route to ‘SSL V-Midi Port 1 Destination’ and ‘IAC Driver Luna2SDResetMackie’, respectively. The SSL UF8 is my hardware controller and the Stream Deck is used for plugin control.
I’ve got a couple of translator swallow actions set up that swallow Sysex messages going to the SSL and Stream Deck. This all works as intended. However, I seem to be having trouble getting BMT to pass messages to the SSL, specific to turning off the LED of a channel that of a channel that was just deselected. The ‘off’ message manages to make it all the way to"IAC Driver BMTtoHWController1", but doesn’t pass to"SSL V-Midi Port 1 Destination" for some reason. However, when I remove BMT from the set up, and just hook everything up to my SSL and DAW directly, everything works fine, and the ‘off’ message passes to the SSL, as expected.
So I’m trying to figure out why I’m having an issue with this. Does anybody have any ideas?
Are there any other translators other than the one that blocks SysEX messages?
For turning of an LED in Mackie MCU you need to send back off messages in the form of 90 xx yy instead of 80 xx yy. So maybe a translator that sends a note-off message is sending it in the wrong format.
I see in your diagram 80 1A 40 going to the SSL but no 90 1A 00 which is what would be required. I suspect there is a translator there that with a incoming note-off out outgoing note-off and the incoming is coming in as 90 1A 00 and the outgoing is being converted to 80 1A 40. I would need to look at your translators to tell for sure.
In general anything without a translator will pass through the designated routes.
Anything with a translator will not pass through the designated routes if Swallow is set on the translator. The translator will override MIDI routing.
The exception is if in the rules of that translator you have ‘exit rules skip outgoing action’ in which the MIDI route will still follow.
Of course if Swallow is not set, it will still go through the MIDI thru route.
If the outgoing action is ‘None’ and Swallow is set, the it will not go through the MIDI thru route.
There should not be any note of messages in the form of 80 xx yy as the SSL or any Mackie MCU controller will not properly interpret these messages to turn the LEDs off.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
In any case, I get the same 80 1A 40 message even when the SSL is connected directly to my DAW, without BMT in between. And when the SSL is directly connected to my DAW, I DO get the 90 1A 00 message to pass from my DAW to the SSL. So I don’t think the 90 1A 00 message is somehow getting mis-translated in BMT. The 90 1A 00 message is just not making it past ‘IAC Driver BMTtoHWController1’ to the SSL port, for some unknown reason.
If you notice from the screenshot I provided, OTHER messages DO make it past ‘IAC Driver BMTtoHWController1’ to the SSL port, so it’s a mystery why the 90 1A 00 message isn’t making it thru.
I do have one other translator, but it’s set to receive messages from Keyboard Maestro exclusively, so that shouldn’t be intercepting any messages from my DAW.
I’m not in front of my computer at the moment, but I’ll try to post my translators later today when I get a chance.
The 8 in 80 represents note-off, the 0 in 80 represents MIDI CH 1 (zero based) the second value is the note value (in hexadecimal) and the third value is the velocity (in hexadecimal).
The note-off type of command your SSL will recognize would be 90 1A 00. This is a special case were the 9 in 90 is normally a note-on but since it is velocity 0 it is considered note-off. Mackie MCU only recognizes this form of note-off.
I will wait until I see your project file to make a final determination why the message is not coming through.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Is there any chance that the ‘IAC Driver BMTtoHWController1 virtual port could be causing issues? I created that in my Mac AudioMidi settings. It’s a bidirectional port, unlike the BMT ports which only work in one direction, and must be connected to BMT.
Is there anything wrong with that approach? I mean, it clearly seems to be working to pass on messages to my SSL and Stream Deck, but I had wondered if what I was doing was technically correct?
I took this approach because I needed a place to give my Sysex swallow translators a place to latch onto. The swallow function wasn’t working when I tried to attach it directly to the SSL port or Stream Deck port.
That’s why, when looking at the screenshots of my router, you see a line coming into the BMTtoHWController1 and BMTtoStreamDeck ports on the right, and then directly across from that on the left, you see two lines going out of those same two port names. These two lines are what attach to the SSL V-Midi Port Destination and Luna2SDMackieReset ports.
Hopefully that all makes sense? Is there anything wrong with this approach, or could it be causing issues with my missing 90 1A 00 message?
Typically I do everything with translators and do not use routes if I want to block SysEX messages. Sometimes routes give unwanted surprises if I’m trying to block messages and I have to add additional ‘Blocking’ translators. I’m pretty sure there is a translator messing things up here.
The only other no-no is you can’t send to MT Pro to MT Pro using a BMT port. It won’t work. But I didn’t see anything like this in your routing. A BMT port needs one end connected to MT Pro and the other end connected to anything but MT Pro. Since you are using IAC ports for the most part, I don’t think this is the issue.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Yeah, I’m using BMT Pro ports strictly for getting into and out of my DAW, and then using IAC ports for everything else other than the required source and destination ports to/from the SSL on the other end.
The reason I kept the routes in the router, and used specific translators for swallowing is because I want nearly everything to pass thru, unimpeded. My thoughts process here is, why bother trying to identify ALL of the various scenarios where you DO want something to pass thru (there are many), and provide translators for it, when you could more easily just figure out what you don’t want to pass thru, and then provide a single translator with a swallow action for that.
The Sysex swallow actions I’m using require the Sysex to start with ‘F0’ and be 120 characters long, so that shouldn’t be also swallowing the 90 1A 00 message. There are two of these Sysex swallow translators. One for the SSL and one for the Stream Deck. They both only very briefly are enabled when Keyboard Maestro sends out a specific keystroke. These two Sysex swallow translators don’t appear to block any other 90 xx xx messages, so it’s hard for me to imagine how they would be specifically blocking that one 90 1A 00 message.
I also have one other translator. This one exclusively takes midi messages from Keyboard Maestro, so it’s not even attached to the same port as the port that is receiving the 90 1A 00 message. This particular translator is only used to take channel 3 inputs and change them to channel 1 inputs.
So I’m still having a hard time seeing how these translators could be causing my issues. In any case, you are the expert on this stuff, so I’ll let you take a look at my translators when I post them later today.
You set these up with defined preset input and output ports. So I might do this on any preset. It also makes it easier to tell where the message is getting passed through.
With this scenario, no SysEx will ever get through as SysEX requires messages longer than 3 bytes. Takes a little more to set it up but when troubleshooting makes it easer seeing where the problems are as the affected translators are shown when viewing Incoming or Outgoing in the log.
The thing is, that there are longer messages than that though. I’ve seen messages that are roughly 10 or 15 bytes. So I’d have to have translators for every scenario. It’d probably require quite a few translators for different byte lengths. I’m honestly not sure how many different byte lengths are possible with MCU?
I know Sysex updates for the LED track name screens are 120 bytes, and those are the longest, but there seems to be quite a few different lengths between 1 byte and 120 bytes. Especially without knowing what all of those possibilities are, I’d be scared to use this method of translators.
And to be clear, I DO want Sysex to get thru, but I need to control WHEN it gets thru. The enable/disable presets that I’m using in BMT will temporarily ‘open up the gate’ to allow a Sysex message to update buttons on my Stream Deck, and then close down again before opening up a different gate to allow a Sysex message to go to my SSL.
This is because the macros I’m using in Keyboard Maestro are set to send out a quick key sequence (42, 43, 34) to update plugins on a given channel, which then triggers a new Sysex. But I only want the Sysex with plugin names to update my Stream Deck, not the SSL. Conversely, Keyboard Maestro will subsequently send out a quick key sequence (42) to take it back to pan mode, which then sends out a Sysex with track names. But I only want that Sysex to update the SSL, and not the Stream Deck.
The purpose of all of this is to provide real time, always visible feedback of what plugins I have instantiated on a given channel. I have eight buttons on my Stream Deck set up to display these plugin names, one for each of the eight inserts in my DAW. But I obviously want my SSL to continue to always display track names. Hitting any of the channel select keys on the SSL triggers Keyboard Maestro to send out these updates to my DAW (as if they were coming from the SSL), which then subsequently triggers my DAW to send out updated Sysex messages in quick succession that respectively update the plugin names on my Stream Deck and the track names on my SSL.
Anyway, maybe I’m not understanding something about what you’re saying?
Ok. Here is my set of presets. There are quite a few presets and/or translators in there that are actually not being used. Those were from various iterations I’ve gone thru. Refer to the screenshot below for a reference on which presets and/or translators are applicable to this discussion. Those presets/translators in the screenshot, which are not checked, can be ignored.
Also, FYI, the translator titled ‘[1] Keyboard Maestro to Luna’ will likely pique your interest because it involves 90 qq 00 and 80 qq 40, but that is just a translator I put together yesterday while trying to figure out how to correct my issues. I just wanted to make sure that you didn’t see that and think you had found the smoking gun.
Maybe you could put the project back to the original condition when you reported the problem. I can’t duplicate it looks like you have changed things around.
For instance translator 0.1 is suspicious because it is a note off with velocity of 0x40 which seems to match somewhere around where your problem was.
As I said, everything works for me so you must have either changed something since you reported the problem or there is something going on outside of MT Pro. I see that message 80 1a 40 in your original log so it must have been active at the time you reported it.
The default state should look like the screenshot below, with these presets and translators enabled (box checked).
Preset ‘[3] Hardware Controller’ is, by default, disabled but it is briefly enabled by keystrokes coming from Keyboard Maestro. You’ll see those keystrokes in presets [1] and [2]. This briefly allows the Sysex to come thru that goes to the Stream Deck to update the plugin names.
Preset ‘[6] Hardware Controller (5)’ is, by default disabled but it is briefly enabled by keystrokes coming from Keyboard Maestro. You’ll see those keystrokes in presets [3] and [4]. This briefly allows the Sysex to come thru that goes to the SSL to update the track names.
I can promise you that translator [1] was not active when I ran BMT to show you. Even when my SSL is directly connected to my DAW, with no BMT in between, that 80 1A 40 message still shows up. I didn’t even create translator [1] until after I was already having the problem I started the thread about. That translator was created to try to test things to see if I could fix the problem with some kind of work around.
That signal flow you drew up isn’t quite right though. I’ll provide a subsequent post with the full signal flow.
Also, you shouldn’t have all of the translators in preset 0 disabled. Translators 4 and 5 in preset 0 are supposed to be enabled. That’s how I’ve been testing this, and those are the conditions under which I encountered problems with the 90 1A 00 not making it thru to the SSL.
I’m not sure why you’re suggesting to not send anything to the Stream Deck? The Stream Deck is the whole reason I’m doing all of this. I want plugin names to display on my Stream Deck.
As I said, I think there may be some confusion here revolving around an incomplete understanding of my signal flow. For example, ‘IAC Driver Luna2SDResetMackie’ comes BEFORE, not after the Stream Deck. ‘IAC Driver Luna2SDResetMackie’ is the port that gets signal into the Stream Deck. I’ll try to provide a thorough signal flow diagram in a subsequent post.
