2 Oddities with BMTP 1.9.0

For some reason I have to strike a Key Stroke twice in order to fire off a Translator.
I have Preset A and Preset B
Preset A
Translator 01 = Incoming > Keystroke (T) Outgoing > Mouse Position XX
Translator 02 = Incoming > Keystroke (T) Outgoing > Activate Preset B
Translator 03 = Incoming > Keystroke (T) Outgoing > Deactivate Preset A
Preset B
Translator 01 in = Incoming > Keystroke (T) Outgoing > Mouse Position YY
Translator 02 = Incoming > Keystroke (T) Outgoing > Activate Preset A
Translator 03 = Incoming > Keystroke (T) Outgoing > Deactivate Preset B

For some reason Mouse Position XX is not happening. But Mouse Position YY is. As I said, I have to press (T) twice for anything to happen, and when it does, Mouse Position YY is executed and Mouse Position XX is not. So I put a 100ms delay on Activate Preset B and this fixed it. Almost like there is some sort of ‘bleed’ from the first (T) activating the Translator in Preset B.
I set up this project for someone to have a look at.

Strange Bug.bmtp (1.4 KB)

When there are several translators with the same incoming trigger, sometimes they are executed in parallel which is probably what is causing the issue. If you want a series of events and want the guaranteed to be in order, you should insert delays to ensure the outgoing actions are in the order you want.
Here is an example. In the first translator I introduce a 20ms increment and added rules to increase each step.

Strange Bug-sjc.bmtp (1.6 KB)

I’m getting the same behavior with 1.8.4

Steve Caldwell
Bome Customer Care

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

I usually set a global variable and increment it by a fixed amount after each step and then reset it back to 0 to restart the process.

Hey Steve,
Thanks for the reply. I understand what you are saying, but this particular Preset and Translator set up was fine in my 1.8.4 project. Oh well, I can always roll back to 1.8.4. How did you go with the Keystroke not working on the first press. It may be my system or a windows thing.

Hi Jesse,
thanks for the report. From your separate bug report, I read that you’re using Windows 10.

I suggest to always use (and post) the Log Window to understand why and how something is working in MT Pro.

In addition to what Steve said, 2 observations:

  • I can reproduce the issue that only every second T keypress is triggering the actions. We’ll work on that bug. It does work when you use key combinations (like Ctrl-T) or Key Down or Key Up only.
  • I can reproduce that with “Physical Keys” T, Translator 0.0 is never triggered. Probably related to the previous point.
  • As Steve suggested, you have a race condition in your presets: translator 0.1 activates preset 1. Now the incoming event (keystroke T) continues processing preset 0. As Steve said, meanwhile, preset 1 is activated. Now when the incoming event has finished processing preset 0, it depends if the activation of preset 1 is already done or not. If yes, the translators in preset 1 will be executed, too (because they’re also reacting on keystroke T as incoming action). Otherwise, they’re ignored. This is – sort of – at random and you should not rely on this behavior being either this way or another way. The fix is to add a very small delay (a couple of milliseconds) to translator 0.1 so that activating preset 1 will always come after processing the current incoming event.

We’ll follow up with the bug. That’s quite a serious bug!

1 Like

Thanks Florian! So it is a bug which I probably never ran into since I always introduce delays to ensure things are in the order I want.


Hi Jesse,
I’ve found the cause for this bug. Fortunately, it only occurs when deactivating the current preset in response to a Keystroke incoming action, without delay.

The problem was that the Keystroke incoming action received the key down T event and deactivated the preset. Then when you release the T key, the preset is deactivated and the translator action will not receive the T release event. The incoming keystroke action has a lot of logic to handle overlapping keys and modifier keys, and a bug in that logic prevented an incoming action to re-trigger when it thinks that the key in question is still held down.

1 Like

Thanks for great support. Glad that this got sorted out.

MIDI Translator Pro 1.9 build 1020 with the fix is now available in your account:

1 Like