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?
Marked as spam
Can I assume you do not have multiple applications trying to concurrently access a given MIDI port.
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.
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.
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.
Marked as spam
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!
Marked as spam
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)