MidiInput identifier is a negative number, causes hang

Hey all,
I’m grabbing device identifiers from MidiInput::GetAvailableDevices(), and one of my devices is returning a negative identifier. Is this normal?

I only ask because when I pass that identifier to setMidiInputDeviceEnabled() later, I’m getting a weird hang. No exceptions or crashes, the program just ceases to respond to any midi input whatsoever.

Any insight into what’s going on here would be great help.

Thanks,
-M.

Are you on macOS? The kMIDIPropertyUniqueID is a signed integer, so negative numbers are normal.

Can you step through the setMidiInputDeviceEnabled() method and see if the input device is being opened correctly? Just to check, you have added a listener using the addMidiInputDeviceCallback() method right?

Yes, I’m on a Mac. That makes sense, it was just the first most obvious strangeness. But of course, I’m seeing now it’s certainly not limited to the device with the negative identifier.

And yes, I have added the callback. As per the handlingMidi tutorial, I’m checking to see if the input device is enabled, if not enabling it, then adding a midi input device callback.

It doesn’t happen every time I enable an input device, but it is happening when a method I have that calls the setMidiInputDeviceEnabled does so under certain conditions. Not sure exactly what those conditions are other than it seems to be the second or third time any given instance of the object which posses this method has it called. That was quite a sentence. Hope that was clear.

After stepping through it looks like it’s hanging on line 883 at:

if (auto midiIn = MidiInput::openDevice (identifier, callbackHandler.get()))
            {...

It’s something in the “if” line specifically, I guess opening the device.

I think this problem may be somewhat dense. I have a main object (“Set”), that instantiates several of another class of object (“Patch”) and keeps a vector of unique_ptrs to those instances. The “Patches” then all instantiate their own objects of a class called “Pipes”, keeping vectors of unique_ptrs to them. The “Pipes” enable and disable the midi inputs, and handle incoming midi messages. When the “Set” tells a “Patch” to enable itself, it in turn tells all of its “Pipes” to enable themselves.

Something in this hierarchy seems to be the origin of this issue. If I manually enable the “Pipes” or even the “Patches” from the main function (i.e. call their enable method), it goes off without a hitch. When I let the “Set” do it (which it does from it’s own handleIncomingMidiMessage method), I get the hang.

Perhaps another clue, if the “Pipe’s” enable method (that gets called by the other classes) uses MidiInputs::getAvailableDevices(), I get an assertion failure in juce_mac_CoreMidi.cpp:259

There must be some fundamental C++ memory management concept I’m not fully grasping yet.

Still having problems with this. Commenting to hopefully get some visibility on this issue.

This problem seems to be centered around the “JUCE_ASSERT_MESSAGE_THREAD” command inside the findDevices function, in juce_mac_CoreMidi.cpp, as well as around calling the MidiInput::getAvailableDevices() function from within a handleIncomingMidiMessage process.

If I disable “JUCE_ASSERT_MESSAGE_THREAD”, I can call the MidiInput::getAvailableDevices() function from a handleIncomingMidiMessage just fine, but then it chokes when trying to enable the desired input, which I assume is why the message thread assertion is there in the first place. Does this help illustrate where the problem lies? I’m not sure what to do now.