TouchOSC bridge communicating with RME TotalMix but not Cubase Pro 10.5 on Win 10

Dear all,

I’ve been struggling for a while to figure something out with which I hope you can help me, should you have the time to spare.

I have been using TouchOSC to simultaneously control both RME TotalMix and Cubase Pro 10.5 at the same time using an iPad Pro and a MacBook Pro (Catalina) for a while sending MIDI to both software over dedicated channels. It has worked effortlessly over Bluetooth on my past setups.

Now I still have my iPad pro, but I have migrated my Cubase 10.5.3 setup to a Win 10 Pro (v. 10.0.19042) PC. Here, I can make it work from iPad to TotalMix over USB after installing iTunes on my PC but Cubase does not respond to the MIDI commands sent to it. I have followed the TouchOSC installation instructions and I have Googled/YouTubed it for a couple of weeks without solving it. I can’t figure out why it works with TotalMix but not with Cubase. Does anyone here, with more experience with Windows 10, have any insight to share with me? (My TouchOSC contains over 300 commands (JunkieXL style) so I’m not very eager to migrate to a different software at the present.)

When I, in Cubase, reset the generic remote, it sends data to set the faders in my TouchOSC, but that is the only thing I can make happen.

I’ve also tried to set up rtpMIDI following the website instructions but it does not connect to the iPad either. And all firewalls are down on my PC. I’ve opened ports on my router. I sense there is something Win-specific here that I, having been a Mac user for years, am not understanding. All the data in the Generic remote XML file and my TouchOSC are the same as when everything worked properly on my Macbook Pro setup. I’ve double-checked.

Thank you in advance.

All best,
Robin

BTW, Cubase is not registering any MIDI input from TouchOSC Bridge on the meter as far as I can see.

SOLVED: Got help from the TochOSC support:

"The Windows MIDI ecosystem functions differently from the macOS MIDI ecosystem in various ways, but there is one significant difference between the two:
On macOS systems, multiple programs can use the same MIDI ports at the same time
On Windows systems, only one program can use a MIDI port at a time
From your description, it sounds like you have TouchOSC Bridge set up as a MIDI input in TotalMix - it is likely being launched first and therefore “grabbing” the TouchOSC Bridge MIDI input, meaning no other application can use it.
It likely is not assigned to use TouchOSC Bridge as a MIDI output however, which explains why Cubase is able to send the messages back to TouchOSC.
Since TotalMix already has the TouchOSC Bridge MIDI input in use, Cubase can’t get MIDI input from that - but since the TouchOSC Bridge MIDI output port is not being used, Cubase can send out of that.

Having come up in a Windows production environment mostly, I myself until recently assumed that this kind of behavior was universal - but as it turns out, it is actually just the weird way Windows insists on handling MIDI inputs/outputs.
So, ultimately the solution here is to get MIDI input from the TouchOSC Bridge to both TotalMix and Cubase.
There are different ways of doing this; one method would be to send all messages into one program and route the MIDI out of that into the next program.
For instance, Cubase selects the TouchOSC Bridge as an input; as an example, say that all Cubase MIDI commands are designated to MIDI channel 1, and all TotalMix commands are designated on channel 2.
Cubase would take in all the MIDI input, map the controls on channel 1 accordingly, and then output either all of the messages or just the messages on channel 2 to TotalMix.
So the chain would go something like TouchOSC Bridge → Cubase → TotalMix, with all the TotalMix messages routing through Cubase.

This can get a little complicated to do via this method, hopping messages between programs like this, so it may be easier to just figure out all the routing before you hit either program.
This page has a useful method of doing this: How to use the same MIDI device on Windows across multiple programs at the same time – Tristan’s Site (tristancalderbank.com)
Note that both loopMIDI and MIDIOX mentioned in this article are free, which is very helpful (I myself use loopMIDI very commonly, as it is extraordinarily useful for organizing and labeling MIDI ports).
This personally would be a more preferred method of routing as opposed to the other method I mentioned above, where you would route the messages through one program to get to the other one - while this other method will work fine, it also can introduce some “strangeness” if the first program in the message hop decides to do anything unusual with the messages or routing. Via this method mentioned on this page, it will separate the MIDI input into separate MIDI ports, which may help for organization and understanding of exactly what messages are being routed where.

Regarding rtpMIDI - this can also work, but is a bit cumbersome. We don’t necessarily have any specific suggestions/advice on that front, besides following Tobias’ directions to set it up: rtpMIDI Tutorial | Tobias Erichsen (tobias-erichsen.de)
This is more necessary for people that need to integrate CoreMIDI on iOS devices into Windows setups - which is a bit of a specific usage case.
Even on macOS devices, we generally recommend users use the TouchOSC Bridge in lieu of CoreMIDI, unless they have specific hardware/software that demands CoreMIDI usage.
We would more or less say the similar for Windows/rtpMIDI, if not moreso: if your scenario basically demands you need CoreMIDI (again, usually due to specific hardware/software) that would make rtpMIDI more necessary, but otherwise if you can avoid it we would recommend that as it will likely only complicate your setup.
Again, this stuff gets very case-specific; these are only our own suggestions and not any sort of rules. Your mileage may vary, and coming from macOS you may feel more comfortable using rtpMIDI (as it is meant to basically emulate the macos Audio MIDI Network Setup functionality)."

1 Like