MIDI device names on reload

Plugins & Modules
1

Got something odd going on with Midi-Cat… the displayed MIDI device name does not match the actual MIDI device name being used.

Build a patch, add some Patchmaster strips and controls, add a MIDI-CAT, choose my usual device and map everything up. Repeat for next device etc. Save. Quit. Reopen. The same instances work perfectly, but under both in/out device names lists a completely different device that it isn’t actually listening to.

Fix appears to be swap both in/out off Core onto Computer, then back to core, then reselect devices… but having to do this on every patch load.

On an average patch I’ll have 6-8 MIDI-CAT instances all mapping in various hardware (8Pre / 828MkII/BCR & BCF2000’s/01V/a few Pi Picos & Feather M4s)… s’rather disconcerting seeing wrong names everywhere & everything functioning - although I daren’t attempt to remap further controls without manually resetting every instance first.

MacOS11.7.5, Rack2.3 (latest), Stoermelder P1 from library.

Anyone else seeing this oddness, or is it just me?

2

Update: s’not Stoermelder… it’s current version of Rack on MacOS11.7

Looks like once you hit a certain number of MIDI devices (possibly) name mappings get weird & completely out of sync with hardware on opening a saved patch. For Stoermelder modules, switching off Core to (No Device), back to Core and reselecting correct device straightens back out. For VCV Core Midi modules, you have to delete and re-add the module.

Powering off a device causes a random device to jump into it’s place rather than to (disconnected) too - again, more digging required…

More testing to do to confirm… this is with 18 MIDI devices/ports across FireWire and USB.

Suspect I’m going to have to build me an external MIDI Merger :roll_eyes:

1 Like
3

This issue has been mentioned many times. I don’t know if VCV “remembers” MIDI devices by name or by integer index. The integer index is of course not very stable, but it is easy. As I say, however, I don’t know which one VCV uses, just speculating…

1 Like
4

Cheers Squinky - I always thought it was prev a case of devices being randomly selected rather than device NAMES being mislinked to underlying hardware (ie: select 828 talk to BCR2000, because the BCR2000 entry suddenly talks to a MidiSportUNO. In past, files would open mismapped but 828 still talked to the 828 if that’s what was visually selected).

I’ve been using this particular control setup in VCV for 4 years and never really had this problem til now. Have I just been oddly lucky?

Seems if I keep total number of listed MIDI ports below 12, everything stabilises. Ass pain is the Behringer BCx2000 controllers all presenting 3 ports when I only use 2, so with just the Motu828 and those, that’s 11 ports (+ Network Session = 12).

5

It looks like RTMidi used integer device ID. I think (but am not sure) that the ID can change if you, for example, move to a different USB port… But I have to admit I haven’t looked at this much since the 80’s…

from rack: rtMidiIn->openPort(deviceId, “VCV Rack input”);

6

So you can get the device name from RTMidi, but it’s kind of up to you have to do this. I did find this tidbit about how to accommodate MIDI device numbers that change while you are running: Any means to detect a USB Midi controller that has been disconnected · Issue #169 · thestk/rtmidi · GitHub

7

Yeah, using unstable IDs to map something in a patch doesn’t seem like a great idea, but maybe it’s the best that could be done. Does the MIDI standard for devices not have a concept of stable names? Even something like a GUID or something? Because it seems obvious that mappings should be done against stable identifiers. Maybe it’s just a shortcoming of rtmidi.

8

RTMidi (which I an not super familiar with) does let you get the name from the ID, so with enough work your app could save off the name, then when it goes to open it can enumerate all of them and find the id that matches the name. I think that’s how the windows native API works, too.

The devil, of course, is if the MIDI devices change while you are running. In general VCV seems to ignore possible changes while running (we are all familiar with quit and re-open when modules are updated).

Now knowing what VCV does inside I don’t know the answer…

9

but after wasting 20 minutes learning how to look at a 2.0 patch file, I see that VCV does save the name:

 "midi": {
          "driver": 4,
          "deviceName": "2- Steinberg UR22C-1 0",
          "channel": -1
        }

so ?? I’m guessing VCV does the right thing, but there is clearly something that is vexing people. I guess if you had multiple MIDI ports with the same name there wouldn’t be anything you could do? Once again, I don’t know…

1 Like
10

The MIDI 1.x wire standard does not specify any device identification (names or ids). It does have a spec for devices names within SMF MIDI files, but if the wire protocol doesn’t have anything, then it’s not useful for identifying connected devices. This leaves us with however the operating system identifies devices. Of course each OS does this differently, and USB implementations also vary widely, both on the OS side and the device side.

I think MIDI 2.0 does contain some solutions for this problem, and we have to wait for MIDI 2.0 to develop and become available.

1 Like
11

Saving the device name it at least has the potential to attach the right device next time. I guess it will be up to looking at the MIDI module code to see if it actually uses it on re-attach. Of course the OP is using Stoermelder MIDI-CAT so could potentially be a bug in that one.

1 Like