Same MIDI Input device name forbids enabling


#1

I've looked at the forum but couldn't find an answer to this... Why are MIDI Input methods in Juce base on device NAMES instead of using indexes ?

I have 2 MIDI keyboards of same type and they both return the same device name using MidiInput::getDevices() method. I want to enable them both to simulate a larger keyboard (that works under MacOS if I change their name using the Audio/MIDI Config app utility).

Problem is that functions such as setMidiInputEnabled(String,bool) use the device name to enable a port. Any hint on how to enable 2 (or more) devices with same name ? I believe that a new (extra) setMidiInputEnabled(int, bool) in Juce code would fix the problem, but there may be an alternate solution which I couldn't find ?


#2

The MidiInput class does use indexes.. I guess you're talking about AudioDeviceManager - the main reason it uses strings is so that it can store those names in its settings and restore them in the future if the devices have changed. Not sure what it should do if there are dupes though, because even if setMidiInputEnabled took an index, it'd still fail to re-open a previous device because it has to do so by name. Hmm.


#3

most keyboard manufacturers use a sysex ID number when their keyboards are chained together via MIDI Thru.   maybe you could get that value to distinguish the two?   unfortunately, that involves querying the device itself via MIDI, not polling the MIDI driver..


#4

I understand that. And you are right: I am talking about the AudioDeviceManager :)

But my problem is not about re-opening the right device. It is about opening 2 devices with the same name: the current setMidiInputEnabled method has no way to distinguish between the 2 and therefore will always open the same device. So maybe the solution would be to add the index parameter or, as I said before, create a new setMidiInputEnabled method with different parameters (using index instead of or in addition to the names). What do you think ?


#5

Yes but as said above I want to use the whole package that Jules has put together and works very nicely otherwise. And I have to go via the setMidiInputEnabled method if I want to avoid a lot of re-writing, which would not make sense to me...


#6

Has anyone found a solution to this? I have two Arturia KeyLab 49s I’m using to build a small virtual (VST based) pipe organ. I’ve run into this problem too. Both controllers device names appear as KeyLab 49 on both Windows and Mac. This first (physical / first powered on) device opens perfectly and I can run Juce sample code or custom code to receive events and send them to a midiKeyboardComponent. However I cannot access the second device using the same code.

In other words, as far as the Juce tutorial_handling_midi_events sample is concerned. If I select the second device in the list (which happens to be the second powered-on device) the first device still controls the demo / feeds the midiKeyboardComponent.

Can MidiInput::setName fix this? Also, is there a way to add pictures (screen captures) to these forum threads?

I’m a bit stumped at the moment and would prefer to not hack the Juce code itself for a solution.


#7

Are you sure the second device won’t connect? I have two keyboards (although differntly named). If I select both in the audioselectorcomponent, both is enabled/feeds my app. It doesn’t matter which one I connect (to the midi input node), they both will sound as long as I have any of them connected, i.e I can play them both simultanesously. Talking about windows 10 here.


#8

Yes, I’m quite sure. In fact, if I use the JUCE VST Host sample, in the dialog that allows you to select MIDI input devices, when I select either KeyLab 49 entry (either first or second device) BOTH are automatically enabled with checkmarks as if the device name is dominant over the device ID. I need to go back and look at the sample code of the VST Host from JUCE to see what is actually happening there. Maybe that will shed some light.


#9

Check out the AudioDeviceSelectorComponent class… follow it to MidiInput::getDevices()

What probably needs to happen is instead of using a StringArray (for MidiInputSelectorComponentListBox::items) create a structure or class with the device name and ID and store that in an OwnedArray

Rail


#10

Thank you! I think I’m starting to understand part of the problem. The combobox getSelectItemIndex method is basically returning indexed item 1 (device 1) regardless of whether I choose device 1 or 2 because the name is identical. So now I need to figure out how to “intelligently rename” devices with same device (driver supplied) name. Going to dig through AudioDeviceSelectorComponent after work now that my lunch is over! Thanks again!


#11

I edited my previous post which gives you one solution… but it’ll require changing the MidiInputSelectorComponentListBox class and CoreMidiHelpers::findDevices() code (and the Windows equivalent).

As Jules mentioned, you’d also then need to change setMidiInputEnabled to use the MIDI device endpoint reference (on Mac) instead of the name.

Rail


#12

Thinking about it… probably the least invasive approach will be to add a numerical suffix to the name if there are more than one device with the same name… so the list in AudioDeviceSelectorComponent will show the different items as “KeyLab 49 [1]”, “KeyLab 49 [2]”, etc.

You can just modify AudioDeviceSelectorComponent::MidiInputSelectorComponentListBox::updateDevices() to look for duplicates and add the suffixes if required. The other methods can be changed to use the name and suffix number to ID the device.

Rail


#13

A long shot, but it appears the new windows runtime api adds some mysterious numbering to the midi devices, perhaps it’s possible to discern two devices with the same name that way…