# Same MIDI Input device name forbids enabling **URL:** \ **Category:** General JUCE discussion\ **Created:** [September 1, 2015, 9:23am UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443 "2015-09-01T09:23:33Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![phil](https://avatars.discourse-cdn.com/v4/letter/p/e95f7d/32.png) [@phil](https://forum.juce.com/u/phil)\ **Post date:** [September 1, 2015, 9:23am UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/1 "2015-09-01T09:23:33Z")
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 ? ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [September 1, 2015, 10:42am UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/2 "2015-09-01T10:42:23Z")
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. ---
**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\ **Post date:** [September 1, 2015, 11:51am UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/3 "2015-09-01T11:51:42Z")
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.. ---
**Author:** ![phil](https://avatars.discourse-cdn.com/v4/letter/p/e95f7d/32.png) [@phil](https://forum.juce.com/u/phil)\ **Post date:** [September 1, 2015, 5:04pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/4 "2015-09-01T17:04:52Z")
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 ? ---
**Author:** ![phil](https://avatars.discourse-cdn.com/v4/letter/p/e95f7d/32.png) [@phil](https://forum.juce.com/u/phil)\ **Post date:** [September 1, 2015, 5:11pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/5 "2015-09-01T17:11:27Z")
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... ---
**Author:** ![joeduf](https://avatars.discourse-cdn.com/v4/letter/j/5e9695/32.png) [@joeduf](https://forum.juce.com/u/joeduf)\ **Post date:** [March 15, 2017, 6:04pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/6 "2017-03-15T18:04:04Z")
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. ---
**Author:** ![oxxyyd](https://avatars.discourse-cdn.com/v4/letter/o/e47c2d/32.png) [@oxxyyd](https://forum.juce.com/u/oxxyyd)\ **Post date:** [March 15, 2017, 6:34pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/7 "2017-03-15T18:34:03Z")
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. ---
**Author:** ![joeduf](https://avatars.discourse-cdn.com/v4/letter/j/5e9695/32.png) [@joeduf](https://forum.juce.com/u/joeduf)\ **Post date:** [March 15, 2017, 6:54pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/8 "2017-03-15T18:54:12Z")
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. ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [March 15, 2017, 6:58pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/9 "2017-03-15T18:58:20Z")
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 ---
**Author:** ![joeduf](https://avatars.discourse-cdn.com/v4/letter/j/5e9695/32.png) [@joeduf](https://forum.juce.com/u/joeduf)\ **Post date:** [March 15, 2017, 7:05pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/10 "2017-03-15T19:05:15Z")
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! ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [March 15, 2017, 7:07pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/11 "2017-03-15T19:07:38Z")
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 ---
**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\ **Post date:** [March 15, 2017, 7:23pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/12 "2017-03-15T19:23:50Z")
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 ---
**Author:** ![oxxyyd](https://avatars.discourse-cdn.com/v4/letter/o/e47c2d/32.png) [@oxxyyd](https://forum.juce.com/u/oxxyyd)\ **Post date:** [March 16, 2017, 8:57pm UTC](https://forum.juce.com/t/same-midi-input-device-name-forbids-enabling/15443/13 "2017-03-16T20:57:39Z")
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… > [@Experimental support for the Windows Runtime MIDI API](https://forum.juce.com/t/experimental-support-for-the-windows-runtime-midi-api/21049): > > Hi everybody, We’ve just added EXPERIMENTAL support for the Windows Runtime MIDI API to the develop branch, which enables machines with Windows 10 Anniversary Update installed to connect to Bluetooth Low Energy (BLE) MIDI devices. However, there are some very important caveats: Once a BLE MIDI device is paired, the WinRT MIDI API will always list it as available, even if the device is powered off. Sending or receiving sysex messages is very likely to cause a hang. The WinRT MIDI API…