MT Pro partially crashes then can't be restarted without a full system restart

Occasionally when I'm performing MT Pro will stop sending translator commands. Commands passed straight through the router are fine. I can close the MT Pro window, but I can't reopen MT Pro until I completely restart the computer. Ending the MT Pro process via the task manager and closing all other software doesn't prevent me from having to do a full restart. I do make extensive use of timers and these crashes might be related to moments of heavy timer use.

 

OS: Windows 10

Laptop: Lenovo T470s

Key Software: MT Pro, Traktor Pro 2, Chauvet ShowXpress, Foobar2000

Controllers: Livid Base II, Numark Orbit

 

Does anyone know how I can avoid these crashes, or at least avoid a complete system restart?

Hi,
Can you share how you have these applications and controllers tied together? Can you share your project file? What version of MT Pro are you running?

Can I assume you do not have multiple applications trying to concurrently access a given MIDI port.
Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

If you don’t feel comfortable posting your project here, just send it to me via email. I’ll do the best I can to help you.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

MT Pro Version 1.8.3 build 892

ShowXpress and Traktor are set up to listen only to MT virtual ports 3 and 4, respectively. Foobar2000 is not set up to receive any MIDI signals. No other active applications are open during performances when the error occurs.

The attached routing map is the least confusing I could draft up. Virtual ports 1 and 2 are not utilized in the attached project file, but are reserved for older controllers that I rarely use. The translator entries for the older controllers have been removed, but the error occurs in the expanded version of the project file as well.


Attachments:
![](upload://tDTFyg0j6VW0w8TAEQtLzht9EVm.png)
1536680344242_Project-File.bmtp

Hi Steve, just wanted to post a reply to make sure you noticed my project file and mapping below. It’s in its own response since I don’t believe comments can have attachments.

Hi, we are looking at this but one thing I noticed is that the script might need some re-organization into various presets. For instance, you may want to put the first 26 translators under a separate preset and at the preset level set the default input ports. That way if your configuration changes, you would just need to make one input device change at the preset level instead of 26 input device changes at the translator level.

Also, I noticed they all have the same rule (if li==1 then exit rules, skip outgoing action). Of course this will work but these translators will always be checking for input. It may be better to have a translator to enable the preset at project open and then when you set li to 1 to disable the entire preset. This would be more efficient as then MT Pro would not look at these incoming trigger actions. I’ve made this tweak as an example but in general if you can organize presets by device or function, it make it easier to review and maintain the code.

I would also break out the timers into different presets by either device or function.

Also, it would be good practice to document all of your global variables under a single translator so you can refer back to them later to ensure you are not re-using global variables for multiple functions.

I usually create an “INIT” preset and then a translator under that to document the global variables and their use. I usually also create an Init timer and use that to trigger anything that needs to happen when the project is opened.

I did this in the attached example.

I haven’t yet found any glaring issues but my guess if anything it would be either a timer issue or misdirected MIDI messages.

Also keep in mind that if you skip an outgoing action within a translator, the message will still “pass through” to any default routes. So if you don’t want a given incoming message to pass through, you need to either need to put a translator at the end of the chain with swallow set and no outgoing action, or at the last translator for a given output, put stop processing. I prefer the former.

As an example if Orbit sends any 3 byte MIDI message, it will pass through to the default routes if skipping outgoing action with rules. So you may in fact be getting much more MIDI output than you expect.

I hope this helps!

 

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

 

You might want to focus on repeating timers. Since I don’t know how you are using your variables. I would start with Pulse D Timer and the calculation of pp on rule 0.176. If you are not careful, the calculations could have it trigger pretty often. Start with your continuous repeating timers, followed by your timers with more than 1 iteration. I doubt if any one-shot timers would be a problem. Here is a list:

Outgoing: Periodic timer “End Warn A”: 500 ms (initial delay: 0 ms)
Outgoing: Periodic timer “End Warn B”: 500 ms (initial delay: 0 ms)
Outgoing: Timer 51 times “Fade Down”: 100 ms (initial delay: 100 ms)
Outgoing: Timer 64 times “Fade In A”: 80 ms (initial delay: 80 ms)
Outgoing: Periodic timer “Pulse A”: pp ms (initial delay: 0 ms)
Outgoing: Timer 64 times “Fade In B”: 80 ms (initial delay: 80 ms)
Outgoing: Periodic timer “Pulse B”: pp ms (initial delay: 0 ms)
Outgoing: Timer 64 times “Fade In C”: 80 ms (initial delay: 80 ms)
Outgoing: Periodic timer “Pulse C”: pp ms (initial delay: 0 ms)
Outgoing: Timer 64 times “Fade In D”: 80 ms (initial delay: 80 ms)
Outgoing: Periodic timer “Pulse D”: pp ms (initial delay: 0 ms)
Outgoing: Timer 64 times “Speed FX”: 80 ms (initial delay: 80 ms)
Outgoing: Timer 64 times “Pulse A Trigger”: 80 ms (initial delay: 80 ms)
Outgoing: Timer 64 times “Pulse B Trigger”: 80 ms (initial delay: 80 ms)
Outgoing: Timer 64 times “Pulse C Trigger”: 80 ms (initial delay: 80 ms)
Outgoing: Timer 64 times “Pulse D Trigger”: 80 ms (initial delay: 80 ms)
Outgoing: Timer 64 times “Speed Pal”: 80 ms (initial delay: 80 ms)