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.
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.
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?
Please be sure that the incoming and outgoing ports are properly defined
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
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.
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:
When I set a new channel in a translator, the following translator cannot use that channel.
(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
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.
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
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?
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.
