OK, but if your problem started after you added those new translators, it is probably that. Please find the attached and give it a try. I disabled your translator 0.5 and replace it with 0.6.
Luna-sjc.bmtp (9.0 KB)
Your translator would send a note-off with the form of 80 oo pp where mine would send it in the form of 90 oo 00.
Steve Caldwell
Bome Customer Care
But I’m not saying that the problems started after any new translators were added. There weren’t any new translators added right before I noticed issues. I never said that. I think that’s maybe what is causing some confusion here.
The ‘new’ translator you’re referring to came AFTER I started noticing an issue. That ‘new’ translator was just a very recent attempt I made to experiment and see what I could do to fix the problem. It has nothing to do with the issues I’m having. That ‘new’ translator has 80 qq 40 in it because I recognized that, though, the 80 and 40 were not what I wanted, that packet did also contain the correct note value, so I figured I would repurpose an old disabled translator to translate 80 qq 40 to 90 qq 00 just to see what would happen. But that’s a kludgy work around, at best.
I was worried you might see that ‘new’ translator and think it was a smoking gun. That’s why I tried to make you aware of that in a previous post. Now I wish I would have just deleted that translator before I posted, because it’s gotten us off on a tangent. Bottom line, that ‘new’ translator came AFTER I noticed issues, not before. That new translator was created specifically to try to fix the problem.
And I’ll mention it again that, 80 xx 40 shows up even when I have my SSL directly connected to Luna, with no BMT in between. Just Luna and the SSL. That is it. The 80 xx 40 packet appears to be an artifact of whatever happens between Luna and the SSL. Luna must have some reason to send that packet out, irrespective of what it’s connected to.
I will take a look at the file you attached, to make sure I’m understanding what you’re trying to say, but I just wanted to make it clear that the ‘new’ translator was a very recent addition and isn’t causing the problem, because it wasn’t even introduced until after the the problem arose. The new translator was an attempt to fix the problem. I’m just going to delete that new translator so we can move forward. I never intended for that new translator to be a permanent part of the build. That’s why I sent you the BMT file with that new translator disabled.
To be clear, translator 1, within preset 0, is the fix I am talking about. This is the ‘new’ translator that came after I started having trouble. This is the new translator I made from a repurposed older translator to try to patch up the problem, but it was never intended as a long term solution. Translator 4 and 5 have been around for quite a while now and we’re actually some of the first things I did in BMT.
Those two translators are necessary to get things out of Keyboard Maestro in a controllable way. KM unfortunately does not have any built in routing, so the only way you can keep things separate from one another is to send various things out on different midi channels, and then use something like BMT to route them where you want them. Translator 4 and 5 are there simply to change the midi channel (3) coming out of KM to channel 1, for general use where I want to ultimately route those messages.
Sure, just give my project file a try.
I think the issue is it is 0.5 was sending the wrong kind of note-off message to Luna so Luna was not passing the correct note-off message back to your SSL.
You don’t want a translator in the form of 80 oo pp going to either Luna or your SSL.
Steve Caldwell
Bome Customer Care
Also, you should be able to reduce the number of ports you need. You shouldn’t even need any IAC ports at all.
Here is my best estimate of your routing today.
And what you could do to reduce the number of ports and not need IAC ports at all.
Except you would have to use another strategy to deactive your hardware controller.
The routing I have going on is more complicated than that, though. I’ve been working on drawing up a diagram. Out of curiosity, what program are you using to draw up the diagrams you’re providing? I might just use the same thing.
And the thing is, everything works just like I want it to, except for the one little issue with the note off not making it to the SSL. So I’m reluctant to start over. But I’ll take a look at your file this evening.
And I need the IAC ports for the activation/deactivation thing to work. The limited I/O and routing capabilities of KM, when it comes to MIDI, require me to use the IAC ports. It’s not really an option to do otherwise
I’ll try one more time to reiterate that the translator (translator 1) you’re talking about, with the 80 qq 40 to 90 qq 00 thing going on, was something I tried to do as a fix AFTER I had already encountered the problems. It’s unrelated to the problem and did not cause it. I already plan to delete that translator because it is getting us off on a tangent.
If you’re talking about a different translator than translator 1, then I’m not sure what you’re talking about. Perhaps looking at your file later will help it make sense. I just wanted to try to be clear about how translator 1 isn’t involved in the problems here.
Edit: I just downloaded your BMT file. I see that you have translator 1 enabled. PLEASE IGNORE TRANSLATOR 1. PLEASE DISABLE OR DELETE TRANSLATOR 1. It is not intended to be a part of this. I am deleting translator 1 now. Translator 1 will no longer be in any subsequent BMT files which I may upload to this thread.
So it’s also unnecessary to then create translator 6, because translator 6 is simply offsetting what is happening in translator 1, and translator 1 shouldn’t any longer be part of the discussion. The issue lies somewhere else. Translators 4 (ON notes) and 5 (OFF notes) are intended to act as nothing more than a means of moving channel 3 messages coming from KM to channel 1 so that it can be used elsewhere in places that are expecting message to come in on channel 1. Translators 4 and 5 need to stay the way I had them, otherwise KM won’t be able to get certain messages out to everything else.
I’ll keep working one getting a diagram together.
I’m using ClickCharts by NCH Software. I have KM on my laptop and I don’t think I’m using IAC ports there. Just the Bome Virtual Port and the KM port that was created. Haven’t played with it for a while though.
I can try and load this up on my Mac and take a look at it. I mostly work with Windows.
Steve
Ok. Thanks for the info. I’ll check out ClickCharts.
As for KM, it’ll hopefully make more sense once you see my flow chart. Among other things, the IAC ports are needed to get midi into or out of KM, at least in some cases.
OK, looking forward to seeing your flow chart. I think it will be much more understandable to me in that type of format.
ClickCharts free is demo for a limited period. Then they charge you for it. I don’t know if you ever used Visio but I consider ClickCharts like a poor man’s Visio. I had Visio at my work before I retired and starting working for Bome.
Steve Caldwell
Bome Customer Care
I will check it out.
Did you see my post up above about ignoring Translator 1, etc.? I just wanted to make sure that we were on the same page there, going forward.
Yes, I’m totally ignoring translator 1. It is translator 5 that concerns me because you are sending Note-Off message to Luna in the wrong format so of course Luna will not pass it down to update the SSL.
Steve Caldwell
Bome Customer Care
What is wrong with the format in translator 5?
To be clear, KM is sending simple midi note on and off messages (42, 43, 34) on channel 3. BMT then translates those same messages using translators 4 and 5 to change them to channel 1. This is then sent out of BMT to Luna via the ‘Bome Midi Translator 1 Virtual Out’ port. Luna has been accepting these midi messages just fine, and has been reacting as it should to those midi messages, so I’m not sure what the problem is? Luna receives those midi note on/off messages, which then causes Luna to send out Sysex updates to my SSL and Stream Deck, as intended.
Note 42 is for the pan button in MCU format.
Note 43 is for the plugin button in MCU format.
Note 34 is then for using the third Vpot to select the ‘Inserts’ option. This is a Luna specific feature.
The combo of those three buttons, pressed sequentially, results in a Sysex update that displays the plugin names for each of the eight inserts in Luna. That updates my Stream Deck buttons. So KM is simply doing the same thing that I would manually do if I were physically pressing those three buttons on the SSL. KM just does it much quicker. This allows me to be constantly forcing Luna to send out the latest and greatest Sysex for the current state of my plugin inserts.
Your note-off message going to Luna (via MT Pro) are in the form of 80 xx 00 where xx is 42, 43, and 34 (I take it).
If Luna is reacting OK to that, that is fine but the Mackie Protocol required by most controllers are the form of 90 xx 00. So I suspect Luna is just passing what it sees along and the SSL doesn’t know how to react to those type of note off messages. The 0.6 translator I created corrects 0.5 to the proper note-off format.
Please give it a try and hopefully you will be pleasantly surprised.
Steve Caldwell
Bome Customer Care
I think you’re getting my translators 4 and 5 confused with the changes you made to my translators on your own. My translators 4 and 5 don’t have any reference made to 80 or 90 or anything. See the screenshots below. Those screenshots are identical to what I sent you previously. Those translators simply use oo and pp to pass any note value and any note velocity, respectively, from channel 3 to channel 1. That’s it.
So 42, 43, 34 should (and does) pass thru BMT, unimpeded. Those messages are getting to where the need to go, and in an uncorrupted manner.
But does Luna pass them correctly to your SSL? I thought that is where it is not getting updated.
No. It doesn’t need to pass 42, 43, 34 to the SSL. The 42, 43, 34 note on/off messages are coming from KM to Luna, as if those notes were coming from physically pressing those same buttons on the SSL. Luna doesn’t know the difference. And when Luna receives those notes, it then updates the Sysex back out to the SSL and the Stream Deck, as it normally would. I’m just using KM to automate this process.
The channel select note is used as a trigger within KM. But it’s just a trigger. The channel select note is otherwise not used within KM. The macro in KM, when triggered by the channel select notes, sends out 42, 43, 34 to Luna. The idea here is that, anytime you press a channel select button on the SSL, it will ultimately result in an updated Sysex message getting sent from Luna to the SSL and also my Stream Deck. That way, as you change channels on the SSL, the plugins displayed on the Stream Deck will always be current and up to date, displaying the plugins for the currently selected channel at all times.
It’s the channel select note off (90 xx 00) message that isn’t making it all the way thru from Luna back to the SSL. So, as you select channels on the SSL, the LEDs stay lit, even after changing channels. Obviously, you only want the LED for the currently selected channel to be lit. The channel select off message is making it all the way to ‘IAC Driver BMTtoHWController1’, but it doesn’t then get passed on the ‘SSL V-MIDI Port 1 Destination’. This is the crux of the problem, and I don’t know why it’s getting hung up there. See the screenshot in my very first post to see what I’m talking about. You can see that 90 1A 00 makes it to ‘IAC Driver BMTtoHWController1’, but it doesn’t ultimately show up on"SSL V-MIDI Port 1 Destination".
Could you at least try my translator?
Steve
I did. It doesn’t work.
And I wouldn’t expect it to work because your translator has now severed the ability for Luna to receive the 42, 43, 34 messages from KM.
Could you send one message from KM to Luna and turn on MIDI IN, MIDI OUT, Incoming and Outgoing in the log file.
Please make it a note off of your choosing.
Steve
I did. It’s in my very first post. See the screenshot.
