Question

I’m working on a little hack sending MIDI messages from an app using RtMidi as a wrapper for CoreMIDI on OS X. I use RtMidiOut::openVirtualPort("MyAwesomePort") so I can select my app as an input source in a DAW.

However, if my program closes and I open it again, my DAW does not recognize the input device as the same port, despite being given the same name.

I was originally using pyrtmidi, so went and verified the behavior writing in C++ directly with RtMidi. “My DAW” in this case is Reaper 4, but I’ve duplicated the behavior in Pro Tools, Logic, and MuLab.

I know it’s possible to retain some uniqueness of a virtual midi port, since MidiKeys behaves just as I’d like my application to behave: my DAWs remember it even if MidiKeys closes and re-opens while my DAW is still running.

So I dug into the RtMidi source, and the CoreMIDI wrapper seemed straightforward enough. All that the MIDISourceCreate asks for is a string. The client parameter is (what I presume after browsing the docs) an identifier for my application, it being a client of the CoreMIDI services.

void RtMidiOut :: openVirtualPort( std::string portName )
{
  CoreMidiData *data = static_cast<CoreMidiData *> (apiData_);

  if ( data->endpoint ) {
    errorString_ = "RtMidiOut::openVirtualPort: a virtual output port already exists!";
    error( RtError::WARNING );
    return;
  }

  // Create a virtual MIDI output source.
  MIDIEndpointRef endpoint;
  OSStatus result = MIDISourceCreate( data->client,
                                      CFStringCreateWithCString( NULL, portName.c_str(), kCFStringEncodingASCII ),
                                      &endpoint );
  if ( result != noErr ) {
    errorString_ = "RtMidiOut::initialize: error creating OS-X virtual MIDI source.";
    error( RtError::DRIVER_ERROR );
  }

  // Save our api-specific connection information.
  data->endpoint = endpoint;
}

So I looked at the MIDISourceCreate documentation, and read this:

After creating a virtual source, it’s a good idea to assign it the same unique ID it had the last time your application created it. (Although you should be prepared for this to fail in the unlikely event of a collision.) This will permit other clients to retain persistent references to your virtual source more easily.

This seems like exactly what I’m looking for. Except I have no idea how to assign the source a unique ID. The out parameter for MIDISourceCreate is a MIDIEndpointRef, which according to the docs is just typedef’d to a UInt32 down the line. So I hypothesized that maybe I should keep track of this UInt32, but that seems like a bad idea.

After digging through all of this I feel like I’m hitting a bit of a brick wall. How do I retain the uniqueness of my MIDI port in between runs of my application?

Answer 1

According to the docs,

kMIDIPropertyUniqueID

The system assigns unique ID’s to all objects. Creators of virtual endpoints may set this property on their endpoints, though doing so may fail if the chosen ID is not unique.

So maybe something like this:

// Try to set the ID if it's saved.
if (savedUniqueId) {
  OSStatus result = MIDIObjectSetIntegerProperty(endpoint, kMIDIPropertyUniqueID, myUniqueId);
  if (result == kMIDIIDNotUnique) {
    savedUniqueId = 0;
  }
}
// If not saved, record the system-assigned ID
if (!savedUniqueId) {
  OSStatus result = MIDIObjectGetIntegerProperty(endpoint, kMIDIPropertyUniqueID, &savedUniqueId);
  // Handle the error?
}

The unique ID is typedefed to a SInt32. I’ve made the assumption that 0 is an invalid unique ID, which is at least true for connections (the docs for kMIDIPropertyConnectionUniqueID say it’s "non-existant or 0 if there is no connection").

I’m not sure how you maintain long-term uniqueness with only 32 bits, but it’ll hopefully be sufficient for relaunches of your app.