Rack: Multiplex MIDI input on Windows

[MarcBoule]

Operating system(s): WIN10
Version if official Rack release, commit hash and/or branch if from source: 7915829

I've been getting this Rack crash for about a week now, so its not just the latest commit that is causing a problem. When I create an instance of MIDI-1 and MIDI-CC (one of each), and I select the same device, Rack crashes with this in the terminal:

MidiInWinMM::openPort: error creating Windows MM MIDI input port.

terminate called after throwing an instance of 'RtMidiError'
  what():  MidiInWinMM::openPort: error creating Windows MM MIDI input port.
make: *** [Makefile:63: run] Error 3

The crash occurs precisely when I choose the same device in the second code module. Here's a screen shot of the UI:

The problem seems Windows-specific, as in Ubuntu and on Mac I can't reproduce it.

Also, when trying the same steps in Rack 0.5,1, everything works, so perhaps something has changed with RtMidi?

[AndrewBelt]

Looks like an RtMidi issue with your device. You'll have to debug this yourself.

[MarcBoule]

It is not device specific though, because it's not just my Kawai keyboard that can create the crash: when I do the same steps and instead select my Steinberg UR22 mkII, which has midi ports also, the same thing happens.

Since it worked in Rack 0.5.1, and not in dev, I'll look through the commits to those core midi modules to see if I can spot where things may have broke.

[MarcBoule]

Adding another data point for debug purposes: I unplugged all my midi devices, installed loopMIDI (virtual loopback midi cable, in order to test with VMPK) and when I select loopMIDI as a device simultaneously in Rack's MIDI-1 and MIDI-CC modules, the same crash occurs.

[AndrewBelt]

Have you made sure all your plugins match the ABI of Rack? Perhaps a recompile of all plugins?

[MarcBoule]

I will give it another shot, but last night I deleted my dev Rack and re-downloaded and recompiled everything fresh, before I logged the bug report, just in case. I assume that when we compile Rack, it compiles the core modules, and since I am only using those in my test case, the other plugins shouldn't matter (but I did recompile everything though, as good measure).

If you can't reproduce on your end, would it be ok to ask on the FB group for a few people that are using Rack dev on Windows 10 to try to see if they can get the bug to occur?

[cschol]

I can 100% reproduce this on Windows 10 with my Akai MPK mini. Investigating.

Update:

Is this perhaps related to https://github.com/VCVRack/Rack/issues/223, which was marked fixed in https://github.com/VCVRack/Rack/pull/231? Maybe @bontric can confirm.

• Confirmed to be working fine on Linux with the same Akai MPK mini device. No crash here.
• Confirmed to be working on Windows in Rack 0.5.1

Also relevant, talking about limitations in RtMidi on Windows:
RtMidi prevents another application to read/write to opened device
mmsyserr-nomem-when-calling-midiinopen-only-when-other-midi-apps-are-open

[phdsg]

same here too. win7 though.

[MarcBoule]

Thanks for the followup @cschol and @phdsg , just out of curiosity, if you have Rack 0.5.1 installed, does the bug occur there also?

[phdsg]

@MarcBoule no, works in 0.5

[cschol]

@MarcBoule No. Rack 0.5.1 works fine.

@AndrewBelt What is the 0.6 equivalent of MidiInWrapper, which per 0.5.1 code comments "allows to use one instance of rtMidiIn with multiple modules"? In 0.6 the code in MidiIO.cpp is ifdef'ed out.

[AndrewBelt]

@cschol The equivalent will be just MidiInput, which you're already using. The wrapping will be behind that class instead of in front of it, when I get around to adding it.

[cschol]

@AndrewBelt Sounds good. This is expected behavior then until those changes are implemented (due to limitations on the Windows side). I don't think there is any other issue as far as I have found testing with RtMidi on Windows.

[MarcBoule]

Not sure I'm yet deep enough into Rack knowledge to be able to follow the last part of the discussion, and from the sound of it the problem is now explained, but for completeness, here's another test I did. In a new directory I checked out and build Rack 0.5.1, then copied librtmidi-4.dll from my 0.6.0dev install over into the 0.5.1 install (dep/bin/), and when I run Rack 0.5.1 the problem doesn't appear (it was also not appearing with the original librtmidi-4.dll from the 0.5.1 build). So a newer change in rtmidi is probably not the problem. Sorry if this is not very useful but I thought I'd share it just in case!

[cschol]

@MarcBoule The code that would make this work has not been implemented yet in v0.6. The code from v0.5 was refactored and it missing the "multiplexing" capabilities to use 1 RtMidi instance with multiple modules. It is not a problem of RtMidi.

[MarcBoule]

Ok, cool, no stress then. Thanks for the explanation @cschol !

[DomiKamu]

Hi, I confirm this issue, from mine Win7 and Win10 platforms. Having once MIDI device (M-Audio CODE61), (plus loopMIDI but only on Win7). Doesn't occur on official 0.5.1, though. Regards.

[tuborgman]

Confirming this painful issue - two MIDI-1 can't point to the same MIDI interface on Windows 10 due to crash. And I have exactly this kind of setup (

[pgrahampdx]

Confirmed Win10, this breaks a patch that uses 4 MIDI-1 for multi voice MPE with a Linnstrument. Painful

[DomiKamu]

@pgrahampdx disapointed like many users.

[BillBehrendt]

FWIW, I get this in Rack on Win 7 also. 2 Instances of MIDI - 1 breaks it. HOWEVER -- in other software(s) when I try to get 2 MIDIs going in 2 different apps (like using MIDI in Cubase and then trying to sniff MIDI data via MIDI_OX), I generally get a message that says "There is not enough memory to run this.." instead of the "application requested unusual termination".

In fact if I start Cubase LE 9 and select the KordBot MIDI input, then start Rack (with an autosave patch using KordBot MIDI in) I get:

And if I start Cubase LE 9 with KordBot MIDI in selected and try to run MIDI-OX, I get

These are "for example". Any 2 programs trying to access the "standard" Windows Audio/ MIDI driver causes this problem, at least on my system. So, again FWIW, perhaps Rack can report the 'lack of memory' instead of the 'unusual termination' at that point somewhere...

[DomiKamu]

@BillBehrendt Hi, it's a Windows MM (Multimedia Manager) limitation (MIDI is based on this sh*t), BTW same MIDI device can't be shared across multiple applications. Same fact occurs about ASIO.

[cunabula27]

@DomiKamu You can however (tested in 0.5.1 not yet with 0.6) use CopperLan to route midi information from a midi device to two vMidi ports (or probably direct and to one vMidi port) and therefore use the same information that way. I successfully had my APC40 driving both Rack and GrandVj at once.

[DomiKamu]

@cunabula27 Very interesting info! (thanks a lot!) and CopperLan seems to be free, arent? I'll test v1.4.5 ASAP on my dedicated Win10 test platform, surely next evening. Thanks again, if working it's a GREAT TIP! Greetings from France.

[cunabula27]

@DomiKamu Yes it's free. I use it with my band to share midi between two performers, works really well and it's very solid.

[DomiKamu]

@cunabula27 Too impatient... Have installed it (lastest 1.4.5 on regular Win7) => this tool is simply fabulous, now can use splitted MIDI keyboard (M-Audio CODE61) to control parts of rack (MIDI channel based). Very easy to use (a baby will understand in 3 minutes lol). THANKS A MILLION - I'll give info to Facebook VCV Rack French group. EDIT info posted to VCV Rack Official User Group, having thanked you! ;)

[BillBehrendt]

@cunabula27 Yes. Thank you. CopperLan works with Rack 0.6.0 (after a bit of a learning curve). But now I do have 4 MIDI notes coming from my KordBot into Rack! Not perfect but I'm in the middle of learning 437,213 things.... ;)

[AndrewBelt]

Transforming this issue into the feature request to add a "MIDI multiplexing" wrapper to midi.hpp.

[MarcBoule]

Fixed in current master (and thus 0.6.1) by @AndrewBelt as reported on FB. Thanks you!