BMT Router Not passing MCU Message for Channel Select LED

Limowreck · February 1, 2024, 2:26pm

Now I am concerned with what other messages the IAC ports might garble…

So a follow-up question I would have to all of this is if there is some way, unknown to me, to use the swallow actions in a manner that doesn’t require the use of the IAC ports?

I can’t place the swallow action on ‘Bome MIDI Translator 1 Virtual In’, because that is prior to the split paths coming out of there, which you can see in my router screenshots. In other words, since I need to independently, and at different times, swallow Sysex going to the SSL and Stream Deck, respectively, I can’t just put the swallow action on the ‘Bome MIDI Translator 1 Virtual In’ port. The swallow actions need to happen independently on each of the two paths coming out of "Bome MIDI Translator 1 Virtual In. So the swallow action must take place sometime AFTER "Bome MIDI Translator 1 Virtual In.

Conversely, I can’t place the swallow action on the ‘SSL V-Midi Port 1 Destination’ because that is not an incoming port, and wouldn’t even show up as an option in BMT.

So if I eliminated ‘IAC Driver BMTtoHWController1’, which is the port in between ‘Bome MIDI Translator 1 Virtual In’ and ‘SSL V-Midi Port 1 Destination’, I wouldn’t have any other location left to use the swallow action on. This is why I created and used those IAC ports in the first place.

Hopefully that all makes sense? In any case, is there some other novel way to use the swallow action here? I would be fine with getting rid of the IAC ports if I could. I only ever used them as a work around, to get the swallow action to work, so I would be fine with eliminating the IAC ports if there were some other way to make the swallow actions do what I want without requiring the IAC ports?

SteveC · February 1, 2024, 3:46pm

Yes, of course. swallow is an option to turn off outgoing MIDI thru paths You can also create blocking translators that can trigger on anything you want and just put outgoing of none with swallow set and it will block what is being processed by MT Pro.

You can also turn on and off MIDI through paths with translators if you want to block SysEX and particular times.

Two options:

You put a translator with the desired incoming pattern with outgoing action of ‘None’
You turn off your MIDI thru path when you don’t need it. This is a possible translator outgoing option to enable or disable thru paths.

For option 2, I don’t see this much different than enabling or disabling your IAC ports.

There is one thing I suggest though. On your input patterns, you should have the first byte as F0 and the last byte of 7F. I think you have the last byte as a global variable. Also if you aren’t using the variables, you do not need to use different ones. For instances you could just use ‘pp’ as place holders for every byte and it would fit the pattern. You only need distinct variables for byte that you want to process in the rules.

Also if you don’t want translators to be processed further, put them near the top and add the ‘stop processing’ option and if the incoming trigger matches, MT pro will not process any downstream triggers and will move on to the next cycle.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

Limowreck · February 1, 2024, 4:09pm

Ok. I’ll mull all of that over, if that’s my only two other options. I think I sort of previously considered at least one of those options, but my concern then and now has always been about the specificity of what gets blocked and what makes it thru, because I only want the those SYSEX updates to pass thru when I want them too, but I want everything else to pass along as it should.

So I’d be worried that turning on/off a thru path would end up blocking other stuff. I’m wondering how achievable it is to surgically turn on/off a thru path so that it doesn’t end up blocking other stuff I actually did want to make it thru. The advantage of the swallow approach is that it goes and looks for a specific message type/length rather than killing a whole pathway.

And I am using the variables because I do need the info in those SYSEX messages. I just need to control when and where those messages make it thru. That’s why the translator with the swallow action only turns on for a split second. The problem is that BMT has no way of knowing the difference between the SYSEX messages for plugin updates and track name updates. They are both the same length and type, and both contain bytes which are constantly changing in value. So the only variables I can control are when and where a Sysex message is coming from.

Is it possible to turn on/off a thru path for only one specific message? If so, I wasn’t aware of that.

SteveC · February 1, 2024, 4:16pm

No, but you can’t do that with IAC ports either so I’m not sure why you were using IAC ports because as I see it, there really is no difference with turning on and of IAC ports than turning on and off MIDI thru paths.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

Limowreck · February 1, 2024, 4:31pm

That’s what I was trying to explain a couple of posts up above. Because I have no way of intelligently differentiating Sysex messages, based on what is inside those messages, my only other option is to differentiate those Sysex messages based on when and where they come.

So, for starters, I must first create a split (duplicate) at ‘Bome MIDI Translator 1 Virtual In’. That port is where Sysex messages first leave Luna. I need to split it at that point so that I have two separate messages streams that I can independently control (one for the SSL and one for the Stream Deck). This is why I created those IAC ports in the first place. I needed two ports which allowed me to independently manipulate two identical messages streams. And I will always need two duplicate pathways, whether it uses IAC ports or something else. You can see the split I created in the router, if you look at my screenshots or the BMT file I sent you.

The question comes down to whether or not I can find a way to manipulate (swallow/block/enable/disable/whatever) those two message streams without using IAC ports?

Because if I can’t do the manipulation I want to do until after I’ve managed to somehow split the message stream up into duplicate paths, that doesn’t leave me a lot of options. Where else can I apply such swallowing/blocking/path disable type of manipulation? All of these sort of actions require that you identify some sort of differentiating, incoming input as a trigger

‘Bome MIDI Translator 1 Virtual In’ isn’t an option because the signal path isn’t even split at that point. That’s why I can’t use an incoming action trigger of any kind there (as far as I’m aware?).

I also can’t place any sort of swallowing/blocking/path disable type of action on the ‘SSL V-Midi Port 1 Destination’ port because that is not an incoming port, and wouldn’t even show up as an option in BMT. That SSL port is at the very end of the signal path. It is, by definition, not an incoming port, and that’s why it didn’t show up in the incoming section of BMT, in which case I have no option to swallow/block/disable/enable a message or path at that point.

What other options am I left with then? That’s why I used IAC ports. The IAC ports gave me something that was available in the ‘incoming’ section of BMT, that I could manipulate with swallow actions. Those IAC ports gave me a midway point, after the split, but before the final destination, to do the manipulation that I needed.

So unless I’m misunderstanding you, I don’t think your suggestion of enabling/disabling a port or pathway would work for my needs if BMT won’t allow me to do said enabling/disabling of a given path, for an incoming action of one and ONLY one specific Sysex message.

That’s the level of control I need. And that’s why I used the swallow action. Because it does allow that level of control. I just had to use IAC ports to do it.

Or am I misunderstanding the solution options that you’re suggesting? Of the two suggestions you’re making, aren’t I already doing option #1 in the BMT file I sent you (‘1. You put a translator with the desired incoming pattern with outgoing action of ‘None’’)? Take a look at preset 3 and 6. That’s where I have the swallow actions going on.

SteveC · February 1, 2024, 5:26pm

What about something like this? The You can enable and disable the paths at will with translators

In the example above, there is only one translator but you can add more to enable and disable paths or otherwise block certain MIDI messages if you know the pattern.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

Limowreck · February 1, 2024, 5:29pm

Did my most recent post above make sense? Because there are specific thoughts and questions in there that I was hoping to get you to address.

That’s why I’m trying to break this up in chunks, and describe it with words.

It’s hard for me to make sense of you’re diagram because it’s not at all like the flow path I have. In fairness, I know you don’t have my complete flow path in front of you to look at. For example, the translators we’ve been talking about are not depicted in the right place in your diagram. See my edits (two red Xs) in the attached pic. The two red Xs are where the swallowing translators are located. There is no swallowing translator after KM, as you have it depicted.

.

SteveC · February 1, 2024, 6:02pm

I’m not going to design your system for you. Maybe I don’t understand what you want. My understanding is that you want everything to flow through from Luna to SSL, Luna to Streamdeck except certain Sysex patters and certain times. For KM, you want to send messages to Luna to trigger multiple events.

In order to let everything thru you need MIDI thru paths. You can add or delete these thru paths with translators if you want to block everything.

For conditional blocking, you need to create input trigger patterns in translators to block the thru paths. You might want to turn these on and off. You can use global variables or presets to turn them on and off. With the blocking translator on, then all messages will go through except the blocking patterns. Otherwise everything goes through.
For everything that you want to block, you have to have a blocking pattern. Yes this may mean many patterns that you have to set up.

I still fail to see what the IAC ports buy you because all they can do is block everything or nothing which MT Pro can also do.

Maybe you need to paint a picture.

You know that you can use several translators each with different SysEX patterns to block, right?

I don’t see anywhere where you conditionally block anything with IAC ports so that is why I can’t see the value in them.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

Limowreck · February 1, 2024, 6:42pm

I wasn’t trying to get you to design my system. It’s already basically designed. I’m just trying to understand a few subtleties of BMT. That is all. So I’m not sure why you think I’m asking you to do that. I can promise you that I am not.

There is some confusion here. I’ve tried to explain as best as I can, but we’re still stuck here on some level of understanding.

So let me try this approach below:

I’m simplifying this down to its most basic form. Please see the pic below. This is the ‘split’ I have been referring to. These are the two duplicate paths I need. One for the SSL and one for the Stream Deck. The ‘Bome MIDI Translator 1 Virtual In’ comes out of Luna. The ‘SSL V-Midi Port 1 Destination’ port goes to the SSL. The ‘IAC Driver Luna2SDResetMackie’ port goes to the Stream Deck. For now, just forget about the Stream Deck port being an IAC port. Stream Deck requires a virtual IAC port. There is not other option there, but that is not pertinent to what I am about to ask. Just know that I do need a duplicate of the messages to go to the Stream Deck too, hence the split. If it helps, let’s pretend that the port going to the Stream Deck isn’t an IAC port.

Ok. Now that that is established, here is my question below:

Keeping in mind that I need the split mentioned above, at what location on the path between ‘Bome MIDI Translator 1 Virtual In’ and ‘SSL V-Midi Port 1 Destination’ (depicted in the pic below) can I place a translator that will 1) ONLY swallow/block/enable/etc. messages passing along the path between ‘Bome MIDI Translator 1 Virtual In’ and ‘SSL V-Midi Port 1 Destination’ AND 2) will NOT swallow/block/enable/etc. any messages passing along the path between ‘Bome MIDI Translator 1 Virtual In’ and ‘IAC Driver Luna2SDResetMackie’? I can’t use ‘SSL V-Midi Port 1 Destination’ as an incoming trigger, correct? If I try to use ‘Bome MIDI Translator 1 Virtual In’ as an incoming trigger it will affect both paths instead of just the port going to the SSL, correct? So where can I put a translator that will achieve my stated goals above?

THIS is what I’ve been trying to get an answer for.

SteveC · February 1, 2024, 7:35pm

Aha, so you want BMT 1 with a blocking translator that only get blocked if the destination is SSL, but if the destination is Stream Deck, you don’t want to block it. Is this what you mean?

If so, I suggest you look at Bome Unlimited MIDI Ports.

You can have basically 2 inputs coming from Luna and distinctly call out which path you want blocked.

So I create a virtual port called ‘FromLunaMain’ where I send all my MIDI from the Luna DAW. I create this port with Bome Unlimited Named MIDI Ports.

Then I create 2 more ports FromLuna-A and FromLunaB

Then I create the following routes in the Bome Network Tool.

IN: FromLuna-Main → OUT: FromLuna-A
IN: FromLuna-Main → OUT: FromLunaB

Now you can use ‘FromLuna-Main’ From your DAW and it will go to two separate ports that you can use as input for Bome MIDI Translator Pro and separately create blocking translators for each incoming Luna Port.

Here is what it looks like in the tool.

We use Bome Network as the tool but if you are not sending MIDI across the network to other computers it is free. You just pay for the Unlimited Named MIDI ports and you can name them whatever you want.

Does this make sense?

Sorry I’ve been so dense!

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

Limowreck · February 1, 2024, 7:52pm

More or less, yes, but not exactly. BOTH destinations need to be receiving everything all the time. The only exception to that is that I want a translator to swallow a Sysex message, at a time of my choosing, on one path (SSL), while allowing that same Sysex message to pass thru to the other destination (Stream Deck) unimpeded. And then, I also want the opposite to happen too, where the Stream Deck now won’t receive the swallowed Sysex, but the SSL will.

But I think you’re generally getting what I’m trying to do now.

But isn’t this effectively the same thing then as just using IAC ports, as I’ve previously described?

SteveC · February 1, 2024, 7:58pm

Similar but they will not mess with your MIDI messages like we discovered yesterday like the IAC ports do. Also putting them before MT Pro is a little less confusing when looking at the routing. You can set up as many Virtual ports with static routing outside of MT Pro and do the heavy lifting regarding translators within MT Pro. With that said, to dynamically turn off and on routes using translators, that would need to be done in MT Pro. You can change routes in Bome Network but it is a manual process using the Bome Network routing tool. Different tools for different uses.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz

Limowreck · February 1, 2024, 8:01pm

Ok. But you’re seeing now why I was wanting/needing to use those IAC ports, correct? Does that make more sense now?

And to circle back to my previous questions:

Am I correct about both of those questions (quoted from my previous post)? I"m just trying to make sure I understand this stuff at its base level.

I’ll have to think about this. I got the impression from Florian that 90 xx 00 to 80 xx 40 was maybe the only message type that I had to worry about getting changed? If so, I’m not sure if I would want to spend the money on Bome Unlimited Ports if I could just add in a translator to take care of this one OFF note issue, and then use the IAC ports, as I’m already doing.

FlorianBome · February 1, 2024, 11:17pm

Hi, IMHO, using IAC ports is very clumsy. The same goes for using Bome Unlimited Named MIDI ports, which may ‘behave’ better, but will still require this clumsy routing out of MT Pro and then back into MT Pro. And the latter cost (a little) money.

I think your routing task can be done without any additional virtual ports, but you will only be able to use one MIDI route in the router. The other route has to be emulated.

For simplicity, let’s use the MIDI route for the stream deck, because it will always get all messages, right? No processing necessary for that route.

A horribly retouched screenshot of the MIDI router:

Then create the first preset for the emulated route to the SSL:

Preset Name: "Route SSL Channel Voice Messages"
  Preset Default MIDI Input: "Bome MIDI Translator 1 Virtual In"
  Preset Default MIDI Output: "SSL V-MIDI Port 1 Destination"
Translator 0: 1-byte messages
  Swallow: no
  Incoming: MIDI pp
  Outgoing: MIDI pp
Translator 1: 2-byte messages
  Swallow: no
  Incoming: MIDI pp qq
  Outgoing: MIDI pp qq
Translator 2: 3-byte messages
  Swallow: no
  Incoming: MIDI pp qq rr
  Outgoing: MIDI pp qq rr

The second preset will route the Sys-Ex messages:

Preset Name: "Route SSL Sys-Ex"
  Preset Default MIDI Input: "Bome MIDI Translator 1 Virtual In"
  Preset Default MIDI Output: "SSL V-MIDI Port 1 Destination"
Translator 0: Sys-Ex messages
  Swallow: no
  Incoming: MIDI f0 ga gb gc gd ge gf gg gh gi gj gk gl gm gn go gp gq gr gs gt gu gv gw gx gy gz g0 g1 g2 g3 g4 g5 g6 g7 g8 g9 ha hb hc hd he hf hg hh hi hj hk hl hm hn ho hp hq hr hs ht hu hv hw hx hy hz h0 h1 h2 h3 h4 h5 h6 h7 h8 h9 ia ib ic id ie if ig ih ii ij ik il im in io ip iq ir is it iu iv iw ix iy iz i0 i1 i2 i3 i4 i5 i6 i7 i8 i9 ja jb jc jd je jf jg jh ji jj F7
  Outgoing: MIDI f0 ga gb gc gd ge gf gg gh gi gj gk gl gm gn go gp gq gr gs gt gu gv gw gx gy gz g0 g1 g2 g3 g4 g5 g6 g7 g8 g9 ha hb hc hd he hf hg hh hi hj hk hl hm hn ho hp hq hr hs ht hu hv hw hx hy hz h0 h1 h2 h3 h4 h5 h6 h7 h8 h9 ia ib ic id ie if ig ih ii ij ik il im in io ip iq ir is it iu iv iw ix iy iz i0 i1 i2 i3 i4 i5 i6 i7 i8 i9 ja jb jc jd je jf jg jh ji jj F7

No enabling preset ‘Route SSL Sys-Ex’ will route all messages to the SSL. Disabling the preset will not route (swallow) sys-ex messages, but keep on routing channel voice messages to the SSL.

Note that you may have other sys-ex messages with different length. Then you will need to create duplicate translators in the preset ‘Route SSL Sys-Ex’ for those sys-ex messages.

You will have to uncheck ‘Swallow’ in all translators. Otherwise, the Stream Deck would not see those messages.

Does that make sense?

PS: Steve and I were brainstorming last week a possible future feature to add ‘internal MIDI ports’ for use in the MIDI Router only. They would work like your use of the IAC ports, just that they only exist inside MIDI Translator. We’re still looking for a good name for these internal MIDI ports. Router Port? Manager Port? Interface Port? we have a long list…

Limowreck · February 2, 2024, 1:59am

I don’t disagree with you that the the IAC ports are less than ideal. That’s why I was trying to figure out if there was a way to not have to use them.

So, actually, it’s not just the Stream Deck that gets all the messages. BOTH destinations (SSL and Stream Deck) need to be receiving everything all the time. The only exception to that is that I want a translator to swallow a Sysex message, at a time of my choosing, on one path (SSL), while allowing that same Sysex message to pass thru to the other destination (Stream Deck) unimpeded. And then, I also want the opposite to happen too, where the Stream Deck now won’t receive the swallowed Sysex, but the SSL will.

I sort of think I understand what you’re saying, but I need to spend some time trying to wrap my head around what you’re suggesting. In any case, as I mentioned above, I need both routes to receive all the messages, so could I adapt your suggestion to work for that?

In any case, another concern I would have about this proposed method is that I’d have to account for all of the various lengths and types of messages that might come from Luna (there are many). That was one advantage to the method that I’m currently using. It only requires one type of translator. I’d have to make a lot of translators to do what you’re suggest, Unless I’m not understanding you?

That would be great if you guys implemented the internal ports thing. As I was putting all of this stuff together, I found myself wishing that the various destination ports would show up in the list of incoming triggers for translators. The internal midi port thing would be a great substitute for that instead.

Any of those names would be fine with me. Maybe a catchy name will come to me. I’ll let you know if a catchy name comes to mind. But I’m mostly interested in you guys just releasing that feature. It would be super useful. You can call it whatever you want.

FlorianBome · February 2, 2024, 2:14am

The proposed method routes through all channel voice messages, so the only missing thing are sys-ex messages. If Luna sends Sys-Ex messages with different lengths, then yes, you’d have to create one translator for every length. I agree that is clumsy if there are more than, say, a dozen different lengths to cover. In any case, even with more translators, it will not affect performance, MT Pro can handle thousands of translators easily. It’s just a lot of editing (but MT Pro has a function to duplicate translators, making it a bit easier).

And then, I also want the opposite to happen too, where the Stream Deck now won’t receive the swallowed Sysex, but the SSL will.

Given that the above is managable, it probably makes sense to not use the MIDI Router at all:

Create the two presets as suggested above (may need to add more translators in the first preset for the different sys-ex lengths).
Then, when that works fine, duplicate both presets, rename them and adjust the Default Preset MIDI Out ports of the duplicated presets to the Stream Deck port.

Btw, there we consider adding a wildcard variable type. It’s difficult to integrate. But with that, you’d only need one translator to trigger on all sys-ex messages, regardless of length.

Limowreck · February 2, 2024, 4:02pm

Do you have any idea if/when you guys might implement the internal midi ports?

I’d be interested in the wild card variable thing too.

FlorianBome · February 4, 2024, 5:34pm

We never disclose our internal planning. But this forum discussion is marked with both features, so we will post here when either feature is available.
Sometimes, we also ask for volunteers to test new features before they get released publicly.
Thanks!