Retaining virtual MIDI port's kMIDIPropertyUniqueID to improve compatibility with StudioOne

Hi there!

I don’t post very often since I usually find the answers in JUCE’s code directly, but in this case I need some guidance…

When my osx app creates midi ports, it seems StudioOne users need to reconfigure the DAW everytime they reuse the app because it can’t recognize the ports as being the same from one launch to the other, despite being named the same.

StudioOne support said that it’s because I need to set the device’s kMIDIPropertyUniqueID for them to recognize the port:

On every startup of your app, a new random value is assigned to the kMIDIPropertyUniqueID property of each MIDI port. This value is used by Studio One to do the matching.
From the Apple docu :
“After creating a virtual destination, 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 destination more easily.”
While one could in theory invent some workaround on our side, using port labels, we’d advise against it. One should adhere to Apple’s recommendations.

Would it be possible to add a setter on MidiOutput/MidiInput classes for me to keep those unique IDs consistants between 2 launches?

Hmmm, I’d rather have JUCE always set the unique ID with some sensible value. How about your bundle-id + the midi port name + port direction, so something like:

com.roli.mididemo.midichannel0.input

Works for me :slight_smile:

OK this is now on develop with commit ac60ce5.

Thanks for the quick fix. I pulled the changed by updating to JUCE 5.2

The story is not over though. I haven’t verified yet if it fixes the issues with Studio One, but it appears it introduces a problem in Maschine. It seems that with the unique ID, Maschine does not recognize the MIDI ports anymore. Just commenting the call to setUniqueIdForMidiPort() seems to fix it.

I honestly don’t know what to do. I would say it is better to stick with what Apple recommends. But then someone at NI should update the behaviour of their app.

What do you think Fabian?

We could make the setUniqueIdForMidiPort() optional somehow via a flag maybe. Would that work for you?

I guess it would be a good tradeoff as I could give the option to the user in the settings.

Hi @fabian,
Do you think you can add this flag soon so that I can add an option in my App’s settings for NI users?
I forgot about this and now have problems in Maschine, while Studio One works properly though. But being compatible with both would be the best :slight_smile:

Hi @fabian,
Do you want me to submit a patch for the develop branch?
Let me know how I can help.
Cheers

OK sorry for losing the ball on this. It seems really excessive to be changing the MidiInput/MidiOutput API on this just for NI Maschine. Could it be that Maschine maybe doesn’t like the format of the unique ids that JUCE generates. Can you replace the unique id with something more simple, for example replacing line juce_mac_CoreMidi.cpp:216 with:

CHECK_ERROR (MIDIObjectSetStringProperty (device, kMIDIPropertyUniqueID, CFSTR ("HelloWorld")));

Hi Fabian,
Just tested but it doesn’t seem to change how NI Maschine behaves regarding the port.