Change translators in text editor

I have a Bome MT Pro project that has approx. 1200 mouse position Translators in 45 Presets.
Many of them are the same X-Y positions. Question: I am using a 1080p monitor, If I upgrade to a 4k monitor, can I update these mouse position Translators en masse in a text editor type application?


I’ve had some limited success in doing this. First of all always make a backup of your .bmtp file prior to trying this.

In general, it is very difficult to do replace of anything in the rules section of the translators, I believe there is some counting method to determine where the end of each line is so I have had no success with a text editor changing rules.

For other items in might be possible to do a global search and replace of a given value, however not always reliable so you might have to confirm each replacement.

Say you want to change all occurrences of 35 to 28. If there is a rule or something that had anything with a 35 in it, then you may be replacing something you don’t want.

For outgoing mouse position you may see something like this:


In my project file for that particular position it shows like this. I’m not sure of all of the encoding but I suspect the 000C is 12 (hex 0c) and the 0018 is 24 (Hex 18).

My guess is there are other bits that define whether it is relative one of the displays or the global display. Perhaps something else that determine if it is a movement, click, or wheel action. This is all undocumented so you may have to experiment and do a little reverse engineering.

In general, I don’t recommend this method but if you try it make sure you back up your original .bmtp file.

My recommendation is when you design a project you use global variables to set the size of your monitors and then in translators do math in the rules to determine the position for that particular monitor topology. Of course this doesn’t help on a project that has already been hard coded with a bunch of translators.

The other thing you could do is to export your project file to a text file (which is not importable) and then use a text editor to search for each occurrence in one window and then use MT Pro in another window to go to the next occurrence and make the edits there. I think although not as fast, it will likely be more reliable. It takes time but is more reliable. Once you are done you can export your project file again and use various tools to compare the versions and changes (Like the *nix “diff” command).

Good luck!

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:


I quite often use parametrics to write out boring stuff. eg In Gigperformer (great product), they have an input module to name all the incoming midi events etc so they can be used a bit like a global in MTP
Doing any of this large scale mapping is really fatiguing, easy to produce errors etc especially when its is based on repetitive parameters. The good thing is the file format they have to store is all in xml…brilliant!
So I was able to map it all out in overview in a spreadsheet, then simply import and 450 painful entries was turned into joy!

In the same way, I have done a major overhaul of my DAW setup and am using a bunch of stuff but in this application Im using a gaming keyboard (Razer Tartarus) and migrating from an N52…Im not kidding, its the best upgrade I made to workflow and best value

Anyway, there are the feed in points

  1. KP (Keypad) shortcuts ie F13-24 + Ctrl + shift etc (Painfully manually setup)
  2. MTP to manage keystroke > midi (so cubase is not window focused) (XML?)
  3. Cubase Studio setup (XML)

Putting this all into a spreadsheet makes it so much easier
Looks confusing but stay with me

Which generates the xml file backend on another worksheet

What would be the best way to emulate this? Is it possible (as there is nothing like the complexity of the OP example)
Its just basic input KS mapped to midi out but would like it to all be generated (ie the different files need for each app) from a central place.

The presets/translators would be very simple, like the line added here (the import seemed to work ok?)

And this is a work in progress…so having a central source that I can update and propagate/republish as I develop is very important, hence the extra setup work

Is it possible? It would make life a WHOLE lot easier :slight_smile: ie some clues would be great :wink:

Cubase import is no problem

I’m not aware of any such tool in MT Pro which would create this automatically or import from an XML file.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Thanks Steve
Thats true…I wouldnt expect it…Im not actually wanting it to be done for me so much…as mentioned the sample bmtp file imported fine. What is missing is knowing the hex for the ‘incoming’ so I can assemble that in the spreadsheet; it will do the rest
The bmtp file is essentially already an xml format (used by astute coders…thank Florian)…the incoming is the only thing needed if possible; its not exactly hidden away in binary…I started to decipher but thought it would be better to consult here first

I finished the cubase file pretty much and would be good to include the bmtp file if possible…its just too painful to do manually…well moreso repeat versions if you know what I mean

So you are looking for a Hex to Decimal converter. Most spreadsheets can do this, but you have to remove the “0x” prefix.


This converts a hex number to decimal if the hex (without the 0x prefix is in cell a1.

Any CC will start with hex b and the channel number

CC on MIDI CH 1 is 0xb0
CC on MIDI CH 2 is 0xb1
and so forth

CC number 7F is CC 127 = Using hex2dec()
value will also be 0-0x7f

So CC 1 on MIDI CH 1 value 127 is
B0 01 7F

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

No…not at all…I mean in the translator xml…thanks for the example but that is all basic midi stuff.


Is a coding that has in this case some sort of ascii/hex and I imagine perhaps thats the point of the checksum/signature? There are some clues but would be good to know how to write that so I can include it in the spreadsheet and generate the stuff dynamically

Hi @mwesse

I found this article on the old forum that might help. I’m not sure if it is still accurate.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

in general, I don’t recommend to edit KAM1 and KAM2 key actions. You can now use KAM3 which is actual XML.

  <Outgoing Action="KeyStrokes">
      <Key VK="17"/>
      <Key VK="46"/>
      <Key Release="Y" VK="46"/>
      <Key Char="M"/>
      <Key Release="Y" VK="17"/>

VK is a virtual key code. It is either “press”, or “release”.
Char is the letter to type, it is always press+release keypress.

You can construct arbitrary sequences of <Key> statements.

I’ve formatted the example above for display here. In the .bmtp file, they need to appear all on one line. First, CTRL is pressed down (VK=17=0x11), then DEL is pressed down (VK=46=0x2E), the DEL is released, then Char M is typed (down+up), then CTRL key is released.

Hi Florian, are VK codes Windows platform only or are the also portable to Mac?

Also, if you read a project file that has KAM1 and re-write it, will it convert to KAM3 on writing?

They are Windows VK codes, but MT Pro will work with them on Mac, too. MT Pro has an internal translation table from VK to Mac keys.

This is SO brilliant
Florian…you are definitely worth more money!
This makes it so much easier and I really appreciate it.

Having a control system overview and then being able to publish it is so good.
Q: If a particular (complex) mtp was setup; could it be compiled and be made available as a standalone midi utility? Specifically im using standard MCU protocol but extending it way beyond. Basically (assuming you are right handed) one can do most of the mixing with just enc/enc buttons etc with gestures and the workflow improvement is many fold. Not for profit but so others can simply use it on any mcu compatible control surface

ie Im most of the way to turning this (mtp + gesture = really great tools) into a very compact version with just mtp and adding a left hand controller which adds another level of ergonomics

It turns most of that package above into a much simpler and portable package + a lot more (great effort though and gave me the idea to take it a step further)

Florian; I really commend your extremely competent but moreso personable attitude and contribution; rather than being offended or threatened, you are right there to help and the power that these sorts of ‘under the hood’ features add is tremendous. To do what I am doing here would be almost impossible without mental health checks every 2 hours :wink:
:pray: :clap: :clap: :clap:


  1. KAM3 is generic naming for incoming as well I gather?
  2. KAM1 is the default output write in mtp because its compacted?
  3. How can I get a correctly formatted KAM3 ‘Incoming’ to create template from (just to be sure)?

That is a nice trick you do to trap the release key so it doesnt create unwanted interactions :slight_smile:

Thanks for all the nice words!

The “KAM” action types are in historic order:
The first version of MT Pro with keystroke support used KAM1. Then, after a while, new features made it into MT Pro, requiring an updated format: KAM2. And now, with keystroke shortcuts and other new features, we introduced a more human friendly KAM3 in XML format. MT Pro saves files with KAM2 and KAM1 where possible to maintain best backwards compatibility with older versions of MT Pro.


For example, by specifying the type “Shortcut” in an incoming action.

I understand that this would be slightly nicer for users. But in most cases, it will work fine to distribute the .bmtp file and let users load it into MT Pro. You can hide MT Pro in the tray, use auto start, and it’s almost as good as a stand-alone utility.

We do offer the MT Player product, which would allow you to package your project file into a standalone product. However, this is meant for OEM customers who want to make a business from that. It’s not suitable for distribution for free, because we charge royalties on redistribution of the MT Player. And we have decided to not get into the market of selling specific MT Player versions ourselves. We just make the tools… I hope you understand our reasoning.

Thanks Florian; that all makes sense.
I have the resources to implement now.
Greatly appreciated!

(Could you pm details in mtplayer pricing etc as it would be good to know?)

EDIT: Since its xml/tag based, is it ok to ordinate the entries instead ie group



Seems to import ok but anything to be wary of?

Sorry, I though I was on the way…
I was hoping to use qualifier keys of ctrl + shift as separate translators.
These would set a global that becomes the outgoing midi channel modifier.

It seems that to be able to use eg f13 and up with qualifiers, they must be set to physical keys, else the incoming criteria must include the qualifier…which means it has to be KAM1 from what I can see

KS2.bmtp (1.9 KB)

I did a simple bmtp to illustrate…what is best in this case?

yes, that is possible


no, you can use one of these <Type> statements:

1 Like