MTP hangs at launch on macOS


I’m re-visiting this topic because I have been dealing with this same issue for several years and lately it’s been getting worse. I am currently running on Mac Studio M1 Ultra with Monterey 12.6 but I also have had this problem for a long time on my Mac Pro 5,1 running Mojave 10.14.6.

Many times, MTP just hangs at application launch. If I repeatedly Force Quit the app and re-start it, it may eventually launch properly but this usually takes about 5 to 10 tries.

I have tried the following experiment:

  • Delete the “CurrentProject” entry from the .bmts file so that MTP will not try to open a .bmtp preset file at launch.
  • Open MTP.
  • Save a dummy .bmtp file.
  • Ensure that I can successfully close & re-open MTP.
  • Using a text editor, add some translators to the dummy .bmtp file.
  • Save the file (via the text editor).
  • Verify that the dummy file will open and load using the already-running instance of MTP.
  • Add/save more translators using the text editor.
  • MTP can open these changes even after closing and re-launching MTP.
  • I then use MTP to insert & immediately delete a space character in a comment field (space then backspace). This causes MTP to flag the file as dirty so that the Save option is enabled (even though there are, essentially, zero changes).
  • I click Save using MTP.
  • The next time I exit and re-launch, MTP will hang.
  • I used Beyond Compare to see what changes have been made to the file before & after the MTP Save. Only the signature data at the end of the file is different.
  • If I replace the signature data in the .bmtp file with the signature data of the same file prior to saving via MTP, there a good chance that MTP can launch again without hanging.

The “hang” behavior is as noted by others:

  • The MIDI Translator process gets spawned but the GUI is un-responsive.
  • The failure seems to happen as the .bmtp file is being read in.
  • The GUI does not yet show any evidence of any Translators being loaded, but any Virtual Ports created (I’m using all 9) are visible within the MIDI Device selectors in other apps.

It’s interesting that the OS doesn’t seem to think the app is hung. If I right click on the MTP icon in the Dock, the Quit option is displayed but selecting it does nothing. I have to press the Option key to change the popup menu selection from “Quit” to “Force Quit” in order to terminate the application.

The macOS Activity Monitor also does not indicate that the MIDI Translator process is “unresponsive”. You can also “Force Quit” MIDI Translator from here to close MTP (choosing the regular “Quit” instead does nothing).

Going into the Console and filtering by the word “Bome” as I launch MTP shows a few entries that may be of help to you but mean nothing to me:

<TCCDProcess:, pid=95422, auid=501, euid=501, binary_path=/Applications/Bome MIDI Translator> attempted to call TCCAccessRequest for kTCCServiceAccessibility without the recommended entitlement

Sandbox: logd_helper(189) deny(1) file-read-data /Applications/Bome MIDI Translator

MIDITranslatorPro AddInstanceForFactory: No factory registered for id <CFUUID 0x6000001cf0e0> F8BB1C28-BAE8-11D6-9C31-00039315CD46

Invalid timestamps for HID response delay: 12390408105522541 to 297369806006875

RBSStateCapture remove item called for untracked item 203-157-98368 (target:[app<>:95422])

Hi, I’m sorry for your issues!

First of all I would stay away from editing your MT Pro file with a text editor at all. as I have found doing so can create unpredictable results. Especially for translators that have rules, incoming keystrokes or outgoing keystrokes which have specific encoding that will cause issues, especially if adding or subtracting a space.

The most common issue I have seen with apparent hangs are that the setting of MT Pro are set to minimize on launch which may give the impression that things are hung.

With that said, please review this thread to obtain a dump and send it to us so that we can evaluate the situation further.

Also, before you do this, I would recommend you are running the latest version of MT Pro.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Hi Steve,

Thanx for your reply. I want to be clear, I don’t normally edit .bmtp files with a text editor. I was explaining my methodology for trying to troubleshoot a problem with that I have experienced with MTP for many years. I am well aware of the difference between the application being hung versus simply minimized at launch and I outlined the symptoms in my post.

The link you provided gives instructions for capturing the activity monitor diagnostic messages. In my post, I already outlined the relevant lines that were flagged as either “Fault” or “Error” but if you need a complete dump of the other text, I can provide that. Just let me know.

Also, yes, I am running the latest version of MTP.

Hi Karl,
chiming in here… this is a serious problem for us, too.
Please follow the “Freeze” section in the link provided by Steve:
Crash or Freeze? Please send us a dump file!
and do the Sample Process function. It might give us a clue where it hangs.

A mysterious finding is that the signature would have any impact on load. MT Pro does not read or even verify the signature of .bmtp files when loading. So maybe this was a coincidence?


Hello Florian,

Included is a copy of Sample processes when MTP launches successfully as well as when it is in a frozen state. I also included a copy of my Presets file in case that helps.

Additional observation:
When MTP launches and freezes, the cursor changes to the spinning blue pinwheel rather than the typical macOS colorful spinning beachball. Normally, this wait cursor is shown when a Java process is busy.

I’m guessing that MTP is written in Java and that you have Mac/PC/Linux wrappers to make your application multi-platform. The fact that the Java wait cursor is displayed would indicate that it is the JAVA process that is frozen. This could explain why macOS still thinks the application is still running even though the app is unresponsive.



Bome MTP FDiag (71.1 KB)

Any updates on this?

Bump topic.


I think Florian is traveling but he is aware that you sent him this dump. Thanks for the reminder!

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Hi Karl-Franz,
sorry for the late reply. Thank you very much for posting the freeze files so fast. I had a look at them, and they do indicate some kind of deadlock, but it is not clear where or how exactly. It seems that there is some strange interaction with Core MIDI, too. There seem to be three things happening at the same time:

  1. loading of the project file, which causes opening a MIDI port
  2. a refresh of the known MIDI ports
  3. an incoming MIDI event from a MIDI port

And they somehow lock each other out. Is it possible that there is MIDI activity on the MIDI ports being opened by the project file? That shouldn’t be a problem, but just trying to see what could be the cause.

I’ll look into this, but it might be a tricky one. If There is a potential fix, I’ll contact you via PM.
Sorry I don’t have better news at this time.


Florian, there is always MIDI activity on one of the ports because my main keyboard sends out a constant stream of Active Sensing messages that can’t be shut off. In fact, if you look at my translators, you’ll see one of them is dedicated to filtering those messages out so that they don’t flood my bandwidth with unnecessary data.

The Active Sensing is really annoying. Whenever I select the MIDI Out checkbox in the log window, the messages fly by so fast that anything I try to capture scrolls off the window immediately. I have to uncheck the box to stop the stream and then scroll up the log window to find the data I’m looking for. It would be nice if there was a way to filter out Active Sensing similarly to what you have in the translator’s Capture MIDI window.

Regardless, do you think Active Sensing might be the root of the problem?

Hi Karl-Franz, you should be able to turn off Active Sensing by unchecking “Allow Active Sensing” in the right-click menu for the given MIDI port:

Actually, Active Sensing should be off by default, so I’m wondering why it’s on for you…

No, but it could be part of it. In general, MT should be robust enough to support active MIDI messages at start-up and/or during project load.


One way to test if active sensing is part of the problem is to start up MT Pro without your device that sends Active Sensing, connected to see if you get a hang.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services:

Yes, I was actually going to test that next.

Correction, it’s not Active Sensing (0xFE); It’s actually MIDI Timing messages (0xF8) that are being continuously sent by my master controller and are flooding the log window with entries.

oh, that explains. You can filter them out by unchecking “Allow Timing Messages” in the MIDI INPUT drop-down menu (see screenshot above).

quick update: I’ve been able to reproduce the freeze, hooray! Flooding a MIDI port with data and using your project file. Now we should be able to fix it. I’ll report back here.

1 Like

Yay! Good job.

I have a private beta build ready. I’ll PM you with instructions.

Good news. I tested the beta you sent me and haven’t had MTP hang at launch yet so it seems you may have fixed the issue.

I tested something yesterday that you may find interesting. I re-saved my .bmtp project file after disabling “Allow Timing Messages” for the MIDI Input that was sending all the 0xF8 messages and it also allowed MTP to launch properly without hanging up. It seems the flood of timing messages was indeed the culprit.

BTW, I noticed that changing the “Allow Timing Messages” property does not flag the project file as dirty. Is this by design? I had to make a dummy change to the project in order to have MTP allow me to re-save the file.

Great job!


I think that change is in the settings file and not the project file which would explain why the project file was not flagged dirty.

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: