I am attempting to deal with what happens when midi devices hot swap at runtime. I am building my own mapping of device id -> current port number so that if a device goes away and comes back I know it is the same device. The problem is I do not know when I need to rebuild my map. It is not clear at what times RTMidi's port view can change and I do not know how to detect a change except by iterating all ports and comparing the strings, which seems slightly wasteful.
I would like to request either some kind of a call like >havePortsChanged(), or a message that gets queued with midiin->getMessage which flags ports have changed. RTMidi is in a better position to determine when a port change has occurred than my client code is.
If this is not feasible, something that would help is better documentation around port changes. It would be very helpful to be able to know at what times ports can change or when I need to a port change. If I need to potentially be ready for ports to change between any two calls*, it would be useful to have that fact documented. Everything around ports is very unclear in the current docs, for example, although its usage is clear from the docs I cannot find an explanation anywhere of what openPort(0) actually does.
I am aware of #30 but I am slightly confused what to do with it. It looks like an entirely different fork with things like different build scripts and namespacing. This is a smaller, more attainable question. Since #30 has not been integrated over a period of five years maybe it is worth exploring smaller solutions.
* I did a test on OS X 10.13.6 which seems to indicate that port assignments can change at any time as if the change were occurring in a simultaneous thread. Perhaps this is the race condition other issues refer to. I ran:
int outc = midiOut.getPortCount();
int inc = midiIn.getPortCount();
ostringstream str;
str << "Out " << outc << endl;
for(int c = 0; c < outc; c++) {
str << c << ": " << midiOut.getPortName(c) << endl;
}
str << "In " << inc << endl;
for(int c = 0; c < inc; c++) {
str << c << ": " << midiIn.getPortName(c) << endl;
}
If I run this I frequently see
MidiInCore::getPortName: the 'portNumber' argument (1) is invalid.
This implies port 1 disappeared between midiIn.getPortCount() and midiIn.getPortName().
I am attempting to deal with what happens when midi devices hot swap at runtime. I am building my own mapping of device id -> current port number so that if a device goes away and comes back I know it is the same device. The problem is I do not know when I need to rebuild my map. It is not clear at what times RTMidi's port view can change and I do not know how to detect a change except by iterating all ports and comparing the strings, which seems slightly wasteful.
I would like to request either some kind of a call like >havePortsChanged(), or a message that gets queued with midiin->getMessage which flags ports have changed. RTMidi is in a better position to determine when a port change has occurred than my client code is.
If this is not feasible, something that would help is better documentation around port changes. It would be very helpful to be able to know at what times ports can change or when I need to a port change. If I need to potentially be ready for ports to change between any two calls*, it would be useful to have that fact documented. Everything around ports is very unclear in the current docs, for example, although its usage is clear from the docs I cannot find an explanation anywhere of what openPort(0) actually does.
I am aware of #30 but I am slightly confused what to do with it. It looks like an entirely different fork with things like different build scripts and namespacing. This is a smaller, more attainable question. Since #30 has not been integrated over a period of five years maybe it is worth exploring smaller solutions.
* I did a test on OS X 10.13.6 which seems to indicate that port assignments can change at any time as if the change were occurring in a simultaneous thread. Perhaps this is the race condition other issues refer to. I ran:
If I run this I frequently see
This implies port 1 disappeared between midiIn.getPortCount() and midiIn.getPortName().