Sometimes need to reboot computer in order for control surfaces to be "seen" by MT

Sometimes, when I wait too long to launch MT after booting up (maybe 5 or 10 minutes) MT doesn't "see" my control surfaces.  I then restart my computer and launch MT, and the controllers are "seen" and correctly assigned to ports.

I should mention that I have 6 APC Mini's, 2 Novation Keyboards, and 2 Behringer X-Touch Mini's.  Only the 6 APC's are ignored this way.  The other controllers are properly assigned always.

Thanks,

GAbriel

Hi Gabriel,
What host are you using and what operating system? What version of BMT? How are you connecting your devices? Are they all through the same USB hub? Are you using a powered hub? Are the controllers always cabled the same?

Sorry for the late response to your questions, which I appreciate. I sent the response directly to Florian somehow.
So…
– Ableton Live 9
– Win 8.1
– MT ver 1.8.1
– All APC Mini’s -> powered hub
– Everything else -> A second powered hub.
– I’m leaving everything connected and not changing any of the cabling.
Thanks,
Gabriel
p.s. Though this has been marked as resolved, it still happens. But, again, it’s a minor issue.

Seems like a rather serious problem to me! Have you tried if in that case when MT Pro does not see the devices, any other software like SendSX, OX or Ableton sees the devices?

How exactly are the missing devices displayed in MT Pro?

I ask because, on Windows, a (standard) MIDI device can only be opened by one application. Now when MT Pro is started up and wants to open a MIDI device which is already in use by another application, it marks it as pending and regularly tries to open it. So it looks pretty much the same as if it does not exist.

You can easily find out: closing the project (or just double-clicking such a pending device) will close the MIDI device (and remove the “pending” attribute). If it says “closed” rather than “unplugged”, the device is probably blocked by another application.

PS: MT Pro marks a device which is pending because it’s blocked with “pending (error)” instead of just “pending“, but the column in the MIDI device list is not big enough to show the “(error)” part.

Hi Florian,

I hope I can make sense when responding.  The attachments should help.

You’re right about the APC Mini’s.  They seem to be open in another application.  And that application is Ableton Live, as far as I can tell.  I don’t always get the error, so I experimented a bit (I’d have to do this a few times to make sure of the results though).  When I started MT first and then Live, I didn’t have the problem (APC Mini’s not being “seen”).  If I start Live first, and then MT, I did have the problem.  I do know that it was a struggle getting Live to ignore the Mini’s because Live’s control surface mapper wanted to assign the Mini’s to it’s Input and Output (ports?).  I researched on the web and found a way to remove some Live initialization files – which took care of the problem.  As I recall, it would prevent MT from seeing the Mini’s, but I’m not sure.  The attachment Bomes 1.jpg shows Live control surface mapper without the offending Mini’s, and yet, it seems if I start Live first, I still have the problem.  I’ll try this a few more times and report results.

MT reports the problem as shown in Bomes 4.rtf and when I double click one of the Mini’s in as you suggested, in Bomes 2.jpg

Midiox also has the same problem if Live is started first.  See attachment Bomes 3.jpg

It is interesting, though, (if it’s really true) that I can avoid the problem by starting MT first, and then Live.

I’ll post if something isn’t right in this report.

Gabriel

This attachment seems not to have made it

Thanks for the detailed information (sorry for the messy display. We’re still refining this Q&A system!).
It seems to me that the issue is resolved (as in: cause is Ableton, solution is to start MT Pro first), so I mark it as such. Thanks!

Oh dear.  I think I made an assumption on not enough data.  Just now I started Live first, and then MT, and there was no problem.  I did this twice.  There are a few variables here – order of launches, time before launching MT, whether I’ve merely restarted the laptop rather than shutting it down and booting again.  Maybe others?  I’ll make a point of zeroing in on the problem, and letting you know what I find.

In the meantime… what do you make of the fact that there is never a problem if I launch MT first.  This makes it seem that Live is handling port assignments with more “grace”.

 

Uhm, with due respect, if I understand you correctly, I believe it’s the other way round. It seems to me that Live is arbitrarily opening MIDI devices at undefined times — even when not selected — thereby blocking them for other applications. That’s not very graceful, is it?

MT Pro will never open a MIDI port on its own. It only opens ports which the user selects.

The error messages you’re seeing in MT Pro (and the ones in Ox) leave no doubt that the ports are open in another application. MT Pro just beautifies the error message from Windows.

Hi Florian, You may be right about Live opening ports somehow, even when Live is not selected. On the other hand, ports are opened when I use the Novation SL editor and the Behringer X-Touch Mini Editor. They may be the problem. Or perhaps more than one instance of Live was invoked, and then left open…and I may have closed and exited and relaunched MT. I’m happy to say that I haven’t been able to make this error happen since I first reported it. who knows what I did wrong. All is well though, and my MT programming is coming to fruition. Thanks, Gabriel P.S. I didn’t mean to compare the ”grace” of Live vs MT. I recall having seen the wording used in reference to programs, when they crash, crashing gracefully – in that they don’t cause an OS system crash, and maybe misused the term. g.s.

I’ve found the source of my problem.  If I have been browsing the web using Chrome before launching MT, then MT is not able to open midi ports for the six APC Mini’s in my system.  Exiting Chrome before launching MT has no effect.  But if I use the task manager to close each of the Chrome background processes (there were16 running when I last looked) MT is then able to “see” and open the ports without reporting the error that the ports are already open in another application.  I’ve attached an example of the pop-ups that appear with the closing of each Chrome process.  I guess closing an item causes it to crash.

Does anyone have an idea how Chrome could “claim” a port?