I’m not sure I fully understand the problem, but it seems to me like we’d need to do some tests to see ‘exactly’ what the mkII sends over the true DIN MIDI port. I’m ‘guessing’ that it would mirror whatever is sent over the first USB input, but then again, it might be limited to the ‘user presets’?
I’m thinking…go USB if at all possible. The DIN port would be more like an ‘extra port’ to play with when using a DAW. Also good for a more ‘direct connection’ to instruments in a live setup.
To get whatever comes from the MIDIN2 port, USB might be ‘required’?
If it’s sending everything these scripts need, would it not simply be a matter of linking that as your Script’s input instead of the first USB MIDI in?
here is what “I Do” when it comes to ‘routing things MIDI’ and “Why”.
For years now, it’s apparent that many USB<>MIDI drivers for Windows are NOT multi-client friendly. This seems to be more of an issue with the ‘inputs’ than the outputs.
This means that the first app that grabs the MIDI ports can use them, but others cannot.
In the mkII’s case, I find that the ‘inputs’ are not happy with multiple clients on Windows systems. The outputs don’t seem to be a problem though, so I don’t bother to reroute those via virtual cables. I had the same issue with controller by Akai (MPK2, and a EWI-USB Wind controller)…so long ago I started grabbing such controllers with something at boot time and diverting them to a more ‘multi-client’ friendly virtual port.
Since I often like to run different Hosts/DAWs concurrently, my solution is to use a stand alone instance of something like Bidule (For MIDI, Bome works very well too. I go for Bidule since it also does Audio, hosts plugins, and features OSC server/client abilities).
I’ll run that FIRST as a stand alone app in Windows, and grab any ‘problem’ MIDI ports in this instance, and then direct things to the various Hosts via loopMIDI.
So, Bidule grabs my KeyLab USB inputs 1 & 2, and routes them to virtual ports A & B.
My mkII setup in Cubase using mchantzi’s ‘Custom’ scripts ends up looking like this:
I’ve created some logic through the bidule “mkII Transport Conversion” that goes out to a new port C for the sake of remote controlling Dorico. Basically all that does is listen to whatever the mkII sends in the Live/DAW mode, and turns it into simpler single CC events that Dorico can understand (for controling the transport and a few other things).
I also have a pass through out of the bidule in case I want to connect to other stuff in the main Bidule session.
I go a step further, in that I also have a kind of patch-bay set up for audio. Since I use ASIO Link Pro, I can route streams among any ASIO or WDM app running on my system, and also network streams over the LAN. So, this base Bidule instance is always running (I have it set up to start automatically when Windows boots). I route most of my ‘windows apps, browsers, etc’ to send audio through Channels 13-14, where I keep a compressor limiter (Can’t stand the way ads are so damn loud comparted to other content when browsing sources like Youtube. This takes care of that for me!).
A Workflow Example: Dorico’s ASIO outputs routed to the ASIO backend channels 15-16. Passes through Bidule back into ASIO Link, and then goes through the ASIO looback rail to end up in a mixer input in Cubase. I can ‘sync’ the Cubase transport as a slave to Dorico using a special TXL time code plugin. I could insert effects and such in the main Bidule instance ‘between’ these hosts if I like. Also, thanks to Bidule and those virtual MIDI ports (A & B), I can get at either host with my mk2 MIDI controller (Listen to virtual loopMIDI ports A and B).
