1 Source, 2 Destinations - economical routing/mapping

Hello, I am from Austria, new to this forum and new to Bome. Currently learning to use the MIDI Translator and waiting for my Bome Box to connect several MIDI devices.

I understand MIDI Translator more or less, but I think I am not doing everything in an economical way. I have one input device on channel 9 and two output devices on channels 11+12 with 5 different CC mappings each. At my first attempt I got about 30 translator lines.

I am not sure if I really need one translator for each single event (Note on, Note off, Pitchbend, Aftertouch, Control Change, Program Change) and one line for each single CC mapping and that whole bunch for outgoing channel 11 and channel 12.

Is there some technique that allows me to say, for example:
Block all incoming Program Changes on channel 9.
Map (duplicate) all incoming events of channel 9 to channels 11 and 12.
For channel 11, map CC 12, 75, 76, 77, 78 to CC 3, 6, 8, 9, 11.
For channel 12, map CC 12, 75, 76, 77, 78 to CC 102, 103, 104, 105, 106.
Events on incoming channel 9 should not go out.

Can this be done by “Rules” with much less translator lines?
Or probably just by smart configuration of inputs and outputs?
I don’t see a mapping table or anything like that.

Hi and welcome to the Bome community!

I have attached a project file for examples.

This is handled by translator 0.0. I use raw MIDI to send output so I can keep it in the same translator.

This is handled by Translators 0.1 (3 byte events) and 0.2 (2 byte events)

This is handled by translator 0.3 using rules.

This is your homework, you should be able to duplicate translators 0.3 and then modify it to follow the same technique that I did in translator 0.3

I’ve put comments in the rules to help you figure out how I’m doing things.

Complex-Mapping.bmtp (2.7 KB)

Steve Caldwell
Bome Customer Care


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

Ah, that’s what I was hoping for.
It will take me a while to learn ppqq, but I’ll do.

Thank you very much!

OK, oo through xx are all local variables. (same letters). You can read about local and global variable in the MT Pro user guide. Use help or F1 within MT Pro to see the manual.

Steve Caldwell
Bome Customer Care


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

Yes I’ve read about those variables and have used them for note pitch and such during my first steps. I see what you are doing in your code but didn’t think about byte count in raw MIDI. I will study your example and hopefully understand the idea.

Yes, raw MIDI is quite flexible for this type of thing once you understand how it works.

Steve Caldwell
Bome Customer Care


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

Steve, the CC mapping does not work. Let’s talk about channel 11.

You duplicate incoming Ch 9 to Ch 11. This works.
For the mapping you set incoming Ch 11 and yes, Ch 11 should be here now.
But CC out is the same as CC in, as if there were no rules in the mapping.
When I set incoming CC to Ch 9, I get the mapped CC numbers but also the originals (processed and unprocessed output).

Here are readouts from Midi Monitor (I am on a Mac). Done with your settings, I just disabled dup-rules and output for Ch 12.
The original incoming CC number is 75.

This is with your setting for the CC map. Incoming CC 75 on Ch 11 should be mapped to CC 6. But the number is still CC 75, same as the original:

04:39:28.622 To Gordius Port 1 Control 11 75 98
04:39:28.630 To Gordius Port 1 Control 11 75 96
04:39:28.638 To Gordius Port 1 Control 11 75 93
04:39:28.654 To Gordius Port 1 Control 11 75 90
04:39:28.662 To Gordius Port 1 Control 11 75 88
04:39:28.688 To Gordius Port 1 Control 11 75 85
04:39:28.688 To Gordius Port 1 Control 11 75 81
04:39:28.688 To Gordius Port 1 Control 11 75 78

The following happens when I set Ch 9 (original from the controller) as input for the map. It maps correctly to CC 6, but there is still CC 75 around:

04:43:55.252 To Gordius Port 1 Control 11 6 30
04:43:55.259 To Gordius Port 1 Control 11 75 26
04:43:55.260 To Gordius Port 1 Control 11 6 26
04:43:55.267 To Gordius Port 1 Control 11 75 22
04:43:55.268 To Gordius Port 1 Control 11 6 22
04:43:55.283 To Gordius Port 1 Control 11 75 18
04:43:55.284 To Gordius Port 1 Control 11 6 18
04:43:55.291 To Gordius Port 1 Control 11 75 14

I have a suspicion regarding the unaccepted Ch 11 input filter and the stubborn CC 75 with the Ch 9 input filter:
We duplicated all incoming Ch 9 to Ch 11 as raw MIDI. Can it be that the “new raw MIDI” is taking a side path and not caught by the subsequent mapping?

Hi,

  1. Please be sure that the incoming and outgoing ports are properly defined
  2. Make sure you have no MIDI thru paths in the router. The router will continue to send the original messages out unless
    a) the outgoing translator action either completes or is none
    and
    b) swallow is set

Steve Caldwell
Bome Customer Care


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

Response to your hints:

  1. Ports are properly defined. For testing only MT’s virtual input and output are activated. All incoming MIDI is under control, it comes from a Max patch.
  2. Router is clean, no paths.
    2.a Outgoing translator actions are set. I don’t know what you mean with “action completes”.
    2.b Swallow is on, although this makes no difference.

The CC map via rules works well, thank you for that.

But I could isolate two problems:

  1. When I set a new channel in a translator, the following translator cannot use that channel.
  2. (and related to 1. I think) When a translator uses raw MIDI, I have no access to the resulting data. The events simply go to the output.

I seem to have a problem with the processing chain and would have to define each single action.

At this point I’ll pause my research for a couple of days. According to the Bome website my macOS 12.4 version ist not necessarily compatible. I will soon get my Bome Box and try the same on the hardware. This will show if I have a software problem or not.

Hi,
If you see an translator that has a rule like this:

if pp==0 then exit rules, skip outgoing action

then this is a translator that does not complete. If the outgoing action is skipped, then swallow does not work and the original message will pass through any existing MIDI thru paths.

1 - I’m not sure what you mean by this. The translators and local variables are completely independent with one exception. If the first translator has a local variable and the second translator that same local variable with the EXACTLY SAME INCOMING TRIGGER, then the local variable is shared between translators. Maybe a short example of two translators that seem to be interacting would result in me providing you more help here.

2- When using RAW midi input, I use patterns, and the pattern is more loosely defined. For instance Raw input of “oo pp qq” would be any 3 byte MIDI message. Then in rules, you modify or use other global variable for output as desired. Again an example of your issue might help.

I’m running 12.4 (Monterey) on my MacBook Pro with no troubles so I don’t think this is it.
I think looking at your project file and you describing which translators don’t seem to be working would be what is needed to solve your issues.

For now, just to be safe, make sure you don’t define any MIDI thru paths. If you need them that is OK and I can show you how to solve the swallow issue describe above if that becomes a problem. If you require any SysEX messages to pass through, disabling MIDI thru paths may not be an option.

Steve Caldwell
Bome Customer Care


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

Well, I am talking about the “Complex-Mapping.bmtp” file you sent me :wink:
Would be nice if you could look at it again.

I have renamed it and attached to this post. There are few differences to your file:

  • Input/output are set to MIDI Translator’s virtual ports.
  • I have added the CC mapping for channel 12 (you did channel 11).
  • I removed your variable-initialization and “skip outgoing” parts from the CC maps because you wrote that “skip outgoing” leaves the action uncompleted.

TEST: Please send a single CC 75 value on channel 9 to MIDI Translator.
Here the output is CC 75 on Ch 11 & 12 (channels ok, but CC not mapped as required).
Translator 0.3 and 0.4 listen on channels 11 and 12, which you have set in translator 0.1 but this does not work. When you set the input of translators 0.3 and 0.4 to channel 9, the mapping works. But additionally you get also the original CC number as output which is not desirable. I hope that was clear, it is the main problem.

Here is the file:
Complex-Mapping-PO-1.bmtp (3.1 KB)

OK, I had used aliases and also mapped the aliases to Bome MIDI translator virtual ports. I almost always use aliases so if the configuration changes, I can point the aliases to another place and things are correct throughout the project file. For understanding of aliases and how to use them, see this tutorial.

OK

This will break the translator as you will be sending the value of rr which will be undefined since it is a global variable. If there is no match you will send out a random CC number if there is no match.
If you want the original C to go through then set rr to pp at the beginning and any unmapped CC’s will go through without modification. I’ve added rules to translators 0.3 and 0.4 at the beginning to handle this case.

I also changed translator 0.3 to handle incoming on MIDI CH 11 and 0.3 to handle incoming on MIDI CH 12.

0.0 you had changed to PC MIDI CH 10 with value of 64. I changed it back to MIDI CH 9 will any value

Since I’m on Windows, I used Bome SendSX to send all the input test values

// type here MIDI messages in hex
// notation, or use the File menu
// to open a .syx or .txt file.
// 0.0
c9 45
// 0.1
98 43 25
// 0.2
c8 56
// 0.3
ba 0c 43
ba 4b 45
ba 4c 4c
ba 4d 4d
ba 4e 4e
// 0.4
bb 0c 43
bb 4b 45
bb 4c 4c
bb 4d 4d
bb 4e 4e

This is fixed by the rule as stated above.

Here is a transcript of the log when testing with the test values sent by Bome SendSX

1: IN   0.2  MIDI C9 45,  oo=0xC9 pp=0x45
2: IN   0.1  MIDI 98 43 25,  oo=0x98 pp=0x43 qq=0x25
3: OUT  0.1  MIDI 6 bytes: 9A 43 25 9B 43 25
4: IN   0.0  Program Change on ch. 9 with any program=86
5: IN   0.2  MIDI C8 56,  oo=0xC8 pp=0x56
6: OUT  0.2  MIDI CA 56
7: IN   0.1  MIDI BA 0C 43,  oo=0xBA pp=0x0C qq=0x43
8: IN   0.3  Control Change on ch. 11 with any CC# set 'pp' to CC#=12 with any value and 'qq' to value=67
9: OUT  0.3  Control Change on ch. 11 with CC#:rr=3 and value:qq=67
10: IN   0.1  MIDI BA 4B 45,  oo=0xBA pp=0x4B qq=0x45
11: IN   0.3  Control Change on ch. 11 with any CC# set 'pp' to CC#=75 with any value and 'qq' to value=69
12: OUT  0.3  Control Change on ch. 11 with CC#:rr=6 and value:qq=69
13: IN   0.1  MIDI BA 4C 4C,  oo=0xBA pp=0x4C qq=0x4C
14: IN   0.3  Control Change on ch. 11 with any CC# set 'pp' to CC#=76 with any value and 'qq' to value=76
15: OUT  0.3  Control Change on ch. 11 with CC#:rr=8 and value:qq=76
16: IN   0.1  MIDI BA 4D 4D,  oo=0xBA pp=0x4D qq=0x4D
17: IN   0.3  Control Change on ch. 11 with any CC# set 'pp' to CC#=77 with any value and 'qq' to value=77
18: OUT  0.3  Control Change on ch. 11 with CC#:rr=9 and value:qq=77
19: IN   0.1  MIDI BA 4E 4E,  oo=0xBA pp=0x4E qq=0x4E
20: IN   0.3  Control Change on ch. 11 with any CC# set 'pp' to CC#=78 with any value and 'qq' to value=78
21: OUT  0.3  Control Change on ch. 11 with CC#:rr=11 and value:qq=78
22: IN   0.1  MIDI BB 0C 43,  oo=0xBB pp=0x0C qq=0x43
23: IN   0.4  Control Change on ch. 12 with any CC# set 'pp' to CC#=12 with any value and 'qq' to value=67
24: OUT  0.4  Control Change on ch. 12 with CC#:rr=102 and value:qq=67
25: IN   0.1  MIDI BB 4B 45,  oo=0xBB pp=0x4B qq=0x45
26: IN   0.4  Control Change on ch. 12 with any CC# set 'pp' to CC#=75 with any value and 'qq' to value=69
27: OUT  0.4  Control Change on ch. 12 with CC#:rr=103 and value:qq=69
28: IN   0.1  MIDI BB 4C 4C,  oo=0xBB pp=0x4C qq=0x4C
29: IN   0.4  Control Change on ch. 12 with any CC# set 'pp' to CC#=76 with any value and 'qq' to value=76
30: OUT  0.4  Control Change on ch. 12 with CC#:rr=104 and value:qq=76
31: IN   0.1  MIDI BB 4D 4D,  oo=0xBB pp=0x4D qq=0x4D
32: IN   0.4  Control Change on ch. 12 with any CC# set 'pp' to CC#=77 with any value and 'qq' to value=77
33: OUT  0.4  Control Change on ch. 12 with CC#:rr=105 and value:qq=77
34: IN   0.1  MIDI BB 4E 4E,  oo=0xBB pp=0x4E qq=0x4E
35: IN   0.4  Control Change on ch. 12 with any CC# set 'pp' to CC#=78 with any value and 'qq' to value=78
36: OUT  0.4  Control Change on ch. 12 with CC#:rr=106 and value:qq=78

And the updated project file
Complex-Mapping-sjc-2022-06-22.bmtp (3.1 KB)

Steve Caldwell
Bome Customer Care


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

Please excuse my error with the rr variable. I should have noticed that.

Thanks for the log, so far I see your MT output is different from mine.

——————————

Here I sent Control Change 75 0 and Program Change 1, both on channel 9:

1: MIDI IN [Bome MIDI Translator 1 Virtual In]: B8 4B 00
2: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: BA 4B 00 BB 4B 00
3: MIDI IN [Bome MIDI Translator 1 Virtual In]: C8 01
4: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: CA 01

Right: CC channel 9 is duplicated to channels 11 & 12.
Wrong: CC numbers aren’t mapped by the mapping rules.
Wrong: PC should not generate output.

——————————

Here with the same input (CC 75 0 followed by PC 1) and all log options enabled:

1: MIDI IN [Bome MIDI Translator 1 Virtual In]: B8 4B 00
2: IN   0.1  MIDI B8 4B 00,  oo=0xB8 pp=0x4B qq=0x00
3: RULE 0.1:4 expression: (rr=oo&15) = 8
4: RULE 0.1:11 expression: (rr=oo&240) = 176
5: RULE 0.1:12 expression: (ss=rr|10) = 186
6: RULE 0.1:14 expression: (tt=rr|11) = 187
7: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: BA 4B 00 BB 4B 00
8: OUT  0.1  MIDI 6 bytes: BA 4B 00 BB 4B 00
9: MIDI IN [Bome MIDI Translator 1 Virtual In]: C8 01
10: IN   0.0  Program Change on ch. 9 with any program=1
11: IN   0.2  MIDI C8 01,  oo=0xC8 pp=0x01
12: RULE 0.2:4 expression: (rr=oo&15) = 8
13: RULE 0.2:11 expression: (rr=oo&240) = 192
14: RULE 0.2:12 expression: (ss=rr|10) = 202
15: RULE 0.2:14 expression: (tt=rr|11) = 203
16: MIDI OUT [Bome MIDI Translator 1 Virtual Out]: CA 01
17: OUT  0.2  MIDI CA 01

——————————

What do we have here?
Is that my Mac, or Voodoo?

The mapping rules apply to channel 11 and 12 only. We do not translate output of one translator to input of another translator. There is no internal looping mechanism for this in MT Pro.

If you want to map CC 9 input messages to CC11 and 12 output messages, you need to create new rules for that.

Of the output you described:

Lines 1 and 2 are handled by translator 0.1
Lines 3 and 4 are handled by translator 0.2

Translator 0.0 doesn’t appear to be working because we did not create a stop-processing flag on it, so downstream translators with the same incoming trigger will still trigger.

Since you asked to block all incoming PC messages on MIDI CH 9 (translator 0.0) and then asked to translate them (0.2) , both translators are in play. The solution is ether to disable translator 0.0 or 0.2 depending on what you want to happen with incoming PC messages on MIDI Channel 9.

I hope this makes sense…

Steve Caldwell
Bome Customer Care


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

Ok, so the translators are not strictly serially connected and one translator cannot automatically use the situation a previous translator has created.

What about a couple of active presets in a row, would one preset use what a previous preset has constructed (aka “new input”) or is serial processing generally not the way MT is designed?

Hi,

To communicate between multiple translators, use global variables. The only exception to this is that if two translators have the exact same incoming trigger, you they share local variables. You can find out more about variables in the Bome MIDI Translator Pro user guide. Press F1 or access the help menu within Bome MIDI Translator Pro.

Bome Virtual Ports for incoming and outgoing are different. For instance Bome MIDI Translator 1 Input is only an input port and Bome MIDI Translator 1 Output is a separate port from the input port. For Bome Virtual Ports, one end of the connection needs to be Bome MIDI Translator Pro and the other end has to be anything but Bome MIDI Translator Pro (a specific application).

Steve Caldwell
Bome Customer Care


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

Thanks for now, I will try with variables. Have already read that part of the manual.

I don’t understand those differences between virtual ports and their specific expectations, but that doesn’t matter. I bought MT Pro only to have a convenient programming and testing environment for the BomeBox. For everything that involves a computer I will stick to MIDI processing in Max.

Thank you for your patience, I learned a lot in this thread.

Awesome. Glad to help, Peter!

Steve Caldwell
Bome Customer Care


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