Unwanted delay in sending MIDI message


I'm in the process of building a redundant rig with MTPro acting as the control center for all things MIDI. I'm having a problem wherein I'm getting a random delay (as much as 10 seconds or more sometimes) in sending one particular (and crucial) pair of MIDI messages in the project, but only on the A-Computer. As I said, it's a redundant rig, so there's an identically-configured B-Computer -- that one is working just fine and hasn't been impacted by the random delay problem at all, despite the fact that I built the MTPro project on the A-Computer and copied it over. I've done enough debugging and MIDI monitoring to say with certainty that the problem is with MTPro -- I press the button on the controller (it's mapped to two different controller and the effect is the same), the button press is logged (both in MTPro and other software) then nothing happens for some period of time, then the MIDI signal sends. I've also discovered that if I switch application windows (it doesn't matter where to or from), the signal sends when I click into the new window. This is a deal-breaking problem, unfortunately, as it takes the two rigs out of sync and I wouldn't be at the computer screens if this were to happen during a show.

I'm up against a reasonably tight deadline on getting this worked out, so any help would be greatly appreciated.

If this information is helpful, I'm using MTPro to communicate with MainStage, DMXIS, QLab, Sensory Percussion, and Logic Pro X via IAC busses/Virtual Ports. The MIDI messages that are failing to send on time are going to Logic via IAC.

Thanks in advance for your help,


Hi Mobley,
Could you post your project file and I will have a look. Should I assume both of your computers are Mac (since you mentioned IAC)? Have you been able to pinpoint it down to a specific controller or button. The more I can understand your layout, the more likely I can help.
Is there a reason you are using IAC instead of Bome Virtual MIDI ports? The reason I ask is because I believe if you are not careful, you can create MIDI loops with IAC, where as Bome Virtual Ports are one way and less likely to have a MIDI loop. Also, do you have a lot of timers running? I can probably get a good feel for it looking at your project file.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
P.S. And yes since Logic Pro is a Mac app, of course you are running on Mac? Are both computers the same processor speed, memory and at same Mac OS level?

Thanks for your quick reply, Steve. I sent you an email containing the project file as well as a breakdown of which translators are failing. I’m not using the Bome Ports for this purpose, because Bome Ports aren’t persistent before or after the MTP opens/closes, which can result in pesky dialogs in my other apps (a big inconvenience in my setup). I don’t believe there are any loop problems based on my reading of the MIDI monitor logs.

Both Macs have 100% identical hardware specs. On the software side, the hard drive of the B-Computer was cloned from the hard drive of the A-Computer.

Is the email in your signature the best place to contact you?

Yes, Mobley. I will take a look at your project files to see if I can find any anomalies. I assume you are running MT Version 1.8.3?

As far as persistence of MT Virtual ports, I noticed that too on Mac platform. On Windows they are always there. I check into that too. It is less likely that IAC loopback is a problem. Usually when I’ve seen problems like this it is due to a flakey controller or application that cannot handle the incoming MIDI data stream.

Thanks. That’s right, I’m running 1.8.3.

Hi Mobley,

I just sent you email explaining what might be the problem. This is something I had problems with in the past. I don’t know if it is the cause of your issue but it is certainly suspect.

Basically the rule is that “Swallow” only works if the outgoing action is TRUE. If the action is aborted, the rest of the translator chain is still evaluated and if no other target actions are found, output processes through the default defined MIDI paths. Consequently if you have default MIDI paths defined, you should always put some sort of “catch all” translator below the others to suppress any messages that you want to swallow with no conditions and an output action of NONE, otherwise, the default MIDI routes kick in.

So for this test I did the following.

Duplicated the problem translators but took out the conditional rules so they will always fire, however created outgoing action of None which means Swallow should now work. I put these translators after the initial ones you created so your translators should still work as planned but these new translators will just prevent any further output from those incoming actions.

My theory is that it was your intention not to send outgoing messages for these translators to anything unless the conditions were met and then only to send the outgoing action to your application.


Thanks, Steve. I’ll give it a try ASAP. In the mean time, does that theory jibe with the fact that the B-Computer has never exhibited the problem. Both computers have been part of 100% of the tests. B-Computer has been successful 100% of the time. A-Computer has had intermittent failures despite having the same code.

Maybe not unless for some reason there is a misbehaving MIDI device (or driver) on one of the two computers. I assume on the intermittent computer you have de-installed and then re-installed MT Pro.

One would also think that if it was a problem with MT Pro, and it is identical code running on two different computers identically configured, it should either be stable on both or intermittent on both. I have to think that there might be some small variance between the two systems’ configurations that might be causing the problem and that this difference is surfacing the intermittent behavior.

The one difference I can think of is that I ran the MT Pro trial on the A-Computer and not the B. What is the process for uninstalling?

Remove it from the applications folder. Keep in mind the demo program will not run for more than 20 minutes before you have to re-start it. This is by design.

I’ll try this and see. I have full licenses for each computer, I was just saying that I never installed the trial on the B-Computer.

OK, should work on each computer the same then as long as they are the both same revision (same bits).

No luck here. Out of frustration, I even went so far as to spend the day yesterday porting my entire show from Logic Pro X to Ableton Live just to rule out any other possibilities. I’m still getting the same weird, irregular delay. One discovery today is that it does seem to be somehow linked to the status of the MTPro window. If that window is focused/in front, there is no delay. Obviously, though, that’s not an acceptable solution.

Hi, what happens if you turn logging off?

I’m continuing to look at your file from yesterday but haven’t found anything obvious yet. Again if it works on one computer, it should work on both given everything else is the same.
You may want to also go to the preferences window in MT pro to see that your preferences are set the same on both systems.

The other thing, to perhaps try is to delete all existing aliases (you can do in preferences) and then re-assign them. Be careful if you have an alias assigned that you are not sending to both the aliased port and the physical port that the alias points to.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist

I’ve had logging off for most of the tests. Preferences are exactly the same. I’m certain now that it has something to do with window focusing. It’s like the messages get clogged and when I click they’re instantly freed up.

OK, I was looking to see if you had any ingoing or outgoing keystroke or mouse applications as that could be a problem if you change focus. Other that that, I can’t see why switching windows would clog or free things up. Your project file has a bunch of timers which are sometimes suspect but it looks like you have them pretty much under control. I suspect that your project file is OK and that there is some other factor affecting this issue only on the one computer. The key here is to try and find “any differences” and then focus there since it only misbehaves on the one computer.

Are you using an external mouse? If so, are there any differences there? What happens if you take them both of and just user your internal mouse pad? Are there any USB hubs you are using? Are you using the same ones on both systems? Same with external monitors or any other attached devices.

Hey Steve, thanks for all of your help on this. I’ve arrived at what is a workable medium-term solution for me. On the offending translators (which all had to do with my play and stop process), I’ve added AppleScript actions to briefly switch to the window of the application I’m targeting (Ableton, MainStage) and then switch back after a 1-second delay. This has resulted in (knock on wood, fingers crossed) perfect performance. I’m very curious about what’s causing this bug, but relieved to have (hopefully) found a way around it.

Wow, an ugly but very creative workaround. Not sure why a certain screen needs to be focused to unblock MIDI. As I said, I was looking for outgoing actions with mouse clicks or shortcuts, but didn’t see any in your project file. You might want to check if you have some (maybe background) MIDI enabled apps running that could interfere. Make sure all apps are pointed to the ports controlled by MT Pro. Don’t try to share any ports with any other apps. Supposedly Mac allows some level of MIDI port sharing but I’m suspicious that it is 100% reliable.

Sorry I couldn’t be of more help!


Hi, chiming in!
This is a very strange problem, which we have never heard of — and MT Pro is almost exclusively used in live setups like this.

It is obvious to me that there is some weird interaction with the OS. The window activation should not have any influence on the MIDI performance! In MT Pro, GUI and MIDI engine are strictly separated.

Which version of macOS do you use?
Have you tried (temporarily) to use the MT Pro virtual MIDI ports?

And the most important request: when logging is on in MT Pro (with timestamps), is the delay reflected in the timestamps (i.e. somehow sending the MIDI message took so long), or is the delay happening after MT Pro sent it, or before it received the MIDI message?

Are you using network MIDI ports in some way? Network in any other way? Connected to the Internet?

Last, but not least, macOS schedules MIDI events, so if there are system time jumps, the MIDI messages could (but should not!) have flaky timing. Maybe turn off (temporarily) automatic time and date setting.

Also the macOS power options could play a role — the computer should be in performance mode, i.e. not go to sleep or safe power.

Thanks a lot for going through all this.
Best regards,