I'm trying (again) to use more than one instance of MT, having used up almost all global variables and needing some more.
In concept, should I be able to run 3 instances? I think I need to do so. Here's why:
I don't fully understand the concept of multi-client drivers, but I think maybe some of my controllers are multi-client and some are not.
I'm able to run two instances of MT and receive midi from my ReMote Zero SL controller on both instances of MT simultaneously.
I don't seem to be able to do the same with my Akai APC Mini. When I try to do it, the first instance of MT works correctly, but in the second instance I get an error message telling me that the MIDI port is already open in another application.
I thought the way to get around this would be to use a third instance of MT.
In this instance, I would get input from the Akai APC Mini, and send it out Bomes Virtual Output ports 1 and 2. Then,
MT instance 2 would input the midi messages from instance 1 on Bomes Virtual Input port 1
MT instance 3 would input the midi messages from instance 1 on Bomes Virtual Input port 2
But it's not working. I get error messages when I try to assign Bomes Virtual Input ports 1 and 2 saying that the ports are already open.
Is there some way to get input into two instances of MT if the device sending the messages is not multi-client?
I tried it and indeed it does not work. I think this is because BMT ports have some protections to prevent MIDI loops. If I remember, I think only 1 end of a BMT virtual port can be Bome MT and the other end needs to be something else (a device or application but not MT Pro) .
I tried the same test but used LoopMidi insteand of BMT ports and it worked.
Instance 1 APC Mini Input -> LoopMIDI1 and LoopMIDI2 output
Instance 2 LoopMIDI1 Input
Instance 3 LoopMIDI2 Input
Fortunately loopMIDI is easy to install and free (unless you donate as I did).
I’ve attached all three instances for the test I ran.
Yep so instance 1 is a traffic director to instances 2 and 3 and you are doing this way so you can use each instance with its own global variable space. (global variables private to a given instance).
Essentially, your way of doing it is the same as mine, except that I don’t use the MIDI Router, I do the assignments in translators. Still, the results seem to be the same for both.
Strangely, I believe I actually had this working on an earlier version of BMT…maybe 1.6. Perhaps Florian changed something in order to create more stability. Or maybe I involved MidiOx somehow. I wish I had notes on this.
At any rate, I’ll try your solution using Loop Midi (which is probably supported more fully than MidiOx at this point in time. My preference would be to not use another piece of software, but I may have to. The only other solution I see would be to move all code that is expecting input from this Akai APC Mini to the second instance while having the first instance monitor all the rest of the controllers (7 APC Mini’s Three Novation controllers and two Behringer X-Touch Mini’s). This would take a bit of untangling that I’m loathe to do.
I’m pretty sure Bome Virtual Ports have always acted the same way. You may have been using MIDI Yoke, which although works on Windows 8/10 is not well supported and a little tricky to install. Once loopMIDI became available I uninstalled MIDI Yoke.
What I’d like to know is whether or not the issue is lack of multi-client capability of the Akai APC Mini. Since two instances of BMT are able to receive MIDI from a single Novation ReMote controller, my hypothesis is that the Novation is multi-client capable, but that the APC Mini is not. But I don’t really understand the multi-client concept in any kind of depth.
Is this really what is causing the problem I have. And, from your knowledge, is it so hard to write drivers (if that’s where “multi-clientism” lives) that support more than one client? I would think it’s common knowledge how to write such drivers, or that the algorithms for doing so are just floating around for anyone to grab and use.
Hi, note that writing multi-client drivers is not common knowledge, and it’s rather tricky to do it well. The main problem, however, is that most USB-MIDI devices are USB class compliant (and that’s a good thing), but Microsoft’s USB-MIDI drivers are not multi-client for MIDI INPUT. Therefore, if using the Microsoft MIDI drivers, there’s only one application that can open the MIDI INPUT port.
Having said that, Windows 10 ships with a new MIDI API (“UWP”) which is multi-client — but only if you exclusively use programs which are already UWP enabled. MT Pro is not (yet) UWP-enabled, but we plan to add support for it.
Last but, not least, you can run multiple instances of MT Pro. I suggest to create a copy of the executable file (MIDITranslator.exe in your programs folder) for every additional instance you want to run, e.g. MIDITranslator2.exe etc. Like that, each instance will remember its own settings.
MT Pro’s virtual ports are not multi-client and cannot be used to send MIDI streams from one instance of MT Pro to another. For that, you can resort to third party loopback MIDI drivers, e.g. LoopBE.