Refresh AudioDeviceSelectorComponent?

[Aros]

I have been wondering… Is there a way to refresh AudioDeviceSelectorComponent MIDI inputs/outpus? The thing is that if I connect my MIDI keyboard while the application is running it will not show. I always have to restart my app. Well, I have been doing this for years and since you don’t change your inputs very often it’s not a big deal, but the users keep asking for this. I think that even Ableton needs to be restarted when you connect some audio/midi devices while it is running so hey, it’s an industry standard But well, if there is a way to do this in JUCE, I’d like to know…

I have checked AudioDeviceSelectorComponent and also AudioDeviceManager but I don’t see any function that looks to do something like this.

Thanks!

[Aros]

Hi Jules,
I noticed you got this “let-someone-else-handle-it-so-that-I-don’t-have-to-waste-my-time-with-trivial-things-and-if-nobody-knows-and-the-guy-keeps-asking-then-fine-I’ll-have-a-look-at-it” forum posting algorithm and I thing it works very well! So keep it up But this thread seems to have moved to the “nobody-knows-and-he’s-still-bothering” phase.

Thanks!

[fr810]

See this thread and my answer here:

MIDI device rescan (Windows)

My specific use case is adding virtual MIDI ports via virtualMIDI - what you’re suggesting may very well work for USB MIDI (though I’m not sure based on what I’ve read about how Windows handles MIDI ports) but virtualMIDI appears to create actual WDM devices without any sort of USB intermediary which JUCE’s Windows MIDI implementation seems to have trouble picking up without restarting the application while the mentioned apps’ “rescan” functions handle it fine. In the meantime I’m also contacti…

[Aros]

Hello Fabian,

you mean that about the background process or the one about Windows Runtime MIDI API? I guess the former… But I don’t quite get it. Is this a Windows specific problem? That is would I just have the same kind of issue on Linux, or would the Linux version of my App simply refresh the device selector window just like that when something is connected?

So if I get this right, the problem is that Windows only provides the application with the list of available device just once (hence the need to restart the app). I understand that by restarting the background process it would get the current list of the devices. But how does that help the main application? How would you pass that information to the main process. You mean by sending some kind of handle to the process? Would that be valid in the main app?

Thanks for your answer!

[fr810]

Well I mean both of my answers. You have two options:

1. You try the new Windows Runtime Midi API which will limit your app to Windows 10 Anniversary update (and may be affected by other bugs related to Bluetooth midi).

or

2. You run a utility process which handles all the midi of your app. You need to send all of your MIDI to that utility app by some means of IPC. When the user re-scans you re-launch the utility app.

[Aros]

Hm… I see.

So 1) makes no sense and 2) means that the separate process would just handle everything related to MIDI, so if I wanted to say play a MIDI track, instead of sending the MIDI messages to the MIDI output, I would send them to that background process (encoding it somehow in IPC) and that process would send them to the MIDI output. What a pain in the neck…

So please just let me ask the question again: Is this a Windows specific problem? Would JUCE on another platform refresh the MIDI ins/outs on it’s own when calling getDevices()?

Thanks

[t0m]

It’s a Windows specific problem.

Just a comment on 1): If you use the new Windows Runtime Midi API then your app will run on all Windows versions, but you’ll only get dynamic device refreshes when running on Windows 10 Anniversary and later.

[Aros]

Thanks, that sounds much better. I will look into it.

[oxxyyd]

Hmm, what are you really talking about? Usb-midi or din?

When I disconnect my midi-keyboard (connected to my Windows PC) it immediately disappears from the list of midi devices on the audiodeviceselectorcomponent. If I reconnect it, it immediately pops up before my eyes, even its check-status is restored. The only catch is that I need to uncheck/check it again, but I’m sure I could fix that programatically if I cared enough.

If it’s a DIN connector on the midi device It’s probably a completely different thing. Then it would be up to the the soundcard to implement some sort of continues scanning of the midi ports and report any changes back to the computer via its USB interface.