HOWTO: fixed channel mapping (e.g. channel 1 to 3)

In this post, I present 2 ways for a static mapping of one channel to another using Bome MIDI Translator (MT).

Let's assume we have a keyboard that is connected to the computer, and you want to use it to drive a DAW.
The keyboard sends on MIDI channel 1, but the DAW shall receive the MIDI data on MIDI channel 3.

Preparation
For this to work, the typical "Midi Translator in the middle" approach is used. The introductory chapters of the users' manual explain more details, but in general it works like this:

• in MT, create a preset "channel mapper"
• in the preset's properties, default MIDI ports, select the keyboard as MIDI IN
• also in the preset default MIDI ports, select a virtual MIDI port as MIDI OUT
• in the DAW, select the virtual port as MIDI IN
• in the DAW, make sure that the keyboard is NOT selected as MIDI IN

MT's MIDI Routes
Now create a MIDI Route in MT: keyboard IN --> virtual OUT. Like this, MT will, by default, pass on all MIDI messages from the keyboard to the DAW.

Create Translator Entries
Now you can use Translator Entries to modify the MIDI messages. Make sure that each translator has a checkmark with the "swallow" option so that the original message is not passed on to the DAW.
So far, the MIDI translator action does not distinguish between the status Code of a MIDI message and the channel. Both are encoded in the status byte. A future version of MT will have an alternative way for entering MIDI data which allows to specify the MIDI channel separately (and also directly with a variable).
But channel mapping is possible nonetheless!

More options?
If this example is too limited for you, there are many more advanced channel mapping solutions in this forum:

• translate channel from keyboard to DAW, and convert back from DAW to keyboard
• translate multiple (same) devices to different channel each
• change the channel map on the fly
• or use the search function, there is much more...

Next post is variant 1.

Variant 1: static mapping

For every MIDI message, create a Translator entry (in the preset created before). Note that MIDI channel 1 is represented as 0 in the lower half (nibble) of the status (first) byte of the MIDI message. Channel 2 is represented by 1, and so on using hexadecimal notation, so that MIDI Channel 16 is represented by F.
There are other channelized MIDI messages, but the ones above are the most common ones.

Variant 2: use rules
The first rule line will set the lower nibble of the status byte to 0 (i.e. set the channel to 1, whatever came in). The next rule adds 2 to the channel.

Hope this post helps!
Florian

Florian, thanks for the help.
My case is a little different from the example and I've tried to extrapolate this to my case but so far no luck, and I dont see where else I can go with it.
I need to have a synth (with local off) that only has one midi channel setting (i.e. the same input as output midi channel) send its midi (from channel 1) through the computer and out through my usb-midi adapter to a different midi channel (that way I can use the synth as only an expander and its control surface to control other synths hooked up and set to different midi channels.)
What i've tried to do, after setting up a Bome preset like you've shown, is route from usb-midi-in to Bome Virtual Port 1, then draw another route from Bome Birtual Port 1 to usb-midi-out. This doesn't work, yet if i Route usb-midi-in directly to usb-midi-out then I do have response, but unfortunately only on the channel I don't want it on, so it's like having Local set to ON on the synth..

Hi novoline

I think you need to try an alternative routing. The problem you may be seeing is you are routing the synth to MT Port 1, and then routing MT Port 1 back to the synth, so everything is getting confused, because the synth is just getting caught in a loop.

Instead, have everything that comes in FROM the synth be MIDI-to-USB -> Bome MT Virtual Port 1 and everything that comes back be Bome MT Virtual Port 2 -> MIDI-to-USB

That make sense?
Jared

Where does Virtual Port 2 come in, should I create it? In my logic i dont see it going back through to the synth, especially since the synth isnt playing (when I have it set the way I explained with usb-in -> Vrtual 1 -> usb-out.
it does (of course) loop back to synth when I just draw a line from usb-in to usb-out, but that was just to test its behavior.

You create Virtual Port 2 the same way you created Virtual Port 1, but selected 2 virtual ports instead of 1 in the MIDI options.

I guess the better question is what are you changing the external synth's channel for? What is it connecting to? Another external synth or an internal VST/DAW?

I'm connecting the synth to other synths, through computer (for translation purpose but also because I dont have a merger with me), because I want to use the modwheel to control other synths (expanders that dont have any mod wheel) but unfortunately this synth I'm using does not allow me to change the output midi channel to be different from the input midi channel.

Okay, that makes sense.

So why use Virtual Ports? Virtual ports are really ideal for routing to software, but since you're just hijacking the signal and sending it back out to a physical output, just route USB-to-MIDI in to USB-to-MIDI out and do all of the translation as Florian explained above. Did that not work?

DERP, yes, it does work that way. I thought that using the virtual port was neccessary. Tunnel vision: Ihave a bunch of things i'm wrapping my head around, trying to get aquainted with some borrowed equipment for a show tomorrow. SAVED! thanks everyone

EDIT, oops, spoke too soon. seems that pitch/mod is not responding but note on/off is. I have MIDI B0 pp qq -> B2 pp qq..

EDIT2, aaand then i got it, E0 -> E2

Hi novoline,

just reading this. Great you've figured it out! So in a nutshell, I guess the routing is:
Route: USB MIDI IN --> USB MIDI OUT

And then make sure that your preset default ports are also set to those USB MIDI ports (and not the virtual ports). Then you should be filtering/mapping MIDI from MIDI IN to MIDI OUT of your computer.

Thanks,
Florian

Hi, I bumped into this thread as I also needed channel mapping.
I followed what recommended in some posts above, and that "kind of" worked; that is, this is what happened:

- I created a translator that accepted any midi message of the form tt pp qq
- I realised that, while it was working fine with CC messages, it was not accepting PCs
- I created another translator that does roughly the same but accepts messages of the form tt pp

This solves the problem of mapping CCs, PCs and all other messages of 2 or 3 bytes, but not the general problem of mapping *all* messages: what happens with midi clock? With sysex? Unfortunately in my setup I need to deal with those.

Is there a way to map all types of messages? Not necessarily with one translator only, e.g. one per message size, if MIDI does not allow arbitrarily long messages.
Thanks!

Simone

Hi Laimon

You will need to create a different translator for each type of message, unfortunately. There isn't a way to have MIDI Translator listen for multiple types of messages with one translator and change the channel.

Thanks
Jared

DvlsAdvct wrote:Hi Laimon

You will need to create a different translator for each type of message, unfortunately. There isn't a way to have MIDI Translator listen for multiple types of messages with one translator and change the channel.

Thanks
Jared

Thanks Jared,

that is not a problem, but what's the maximum number of bytes a MIDI message can contain? Because PCs use only 2 and CCs 3, I am not sure about other types of messages. What I need to know is that there is a maximum number N of bytes that can constitute a midi message, so that I create translators for messages of size from 1 to N.
Is there such an N?
Thanks

I haven't seen sysex messages much larger than 14 bits of data, but sysex messages are usually specific for an individual controllers. Regular MIDI messages are generally only 3 bits, though if there is any 14 bit messaging it could be sent as 6. Usually the only sizes I've seen are:

MIDI Clock: 1 bit (always and only F8)
Standard MIDI: 3 bits
14-bit: Either two separate 3 bit messages or one six bit message
Sysex: Around 14 bits always beginning with F0 and ending with F7, but this is unique to specific controllers and can range in length depending on the context.

Jared