Behavior of MidiInput::getDevices() has changed?

If there is, I’d be interested in putting Juce code for MIDI connections inside it. Then other apps could connect the virtual USB device, and all note senders and receivers could connect to it instead. That would centralize musical data in a publicly shared hub, and when adding or removing devices, a single app would centralize notifications and provide a unifed method for all apps to share musical data across USB, instead of MIDI, simplifying debugging, and enabling plug and play where possible.

My last thought today here is, Jules then wouldn’t need to change Juce for everyone. It wouldn’t matter if the apps needs to be restarted, because they would connect to the hub, and the hub could manage the connections instead. It appears there’s problems with MIDI Mapper in Windows too, so it could solve problems on both platforms. I’m not the best person to make it, I’m glad to help, and it seems this is the best place for it to be made, because so many music vendors have JUCE already.

Well remember that if the community were to develop a JUCE styled USB / HID API and it was MIT licensed then Jules wouldn’t be involved at all.

It would be a fairly simple matter to provide a cross-platform API that supplies juce::MidiBuffer objects, where the implementation uses a USB or HID driver that translates into MIDI.

Oh. I don’t know about the legalities. But architecturally, there would be a single USB interface between the JUCE app and virtual USB device, then everything connects to the virtual USB device, which centralizes connectivity in a single, shared hub. So if the OS vendors make updates to fix problems with OS notifications, it would only happen in one place, simplifying work for Jules and all JUCE users. It could permit, as well as a USB to MIDI interface for each application, a higher level protocol for a third=party plugin to exchange note data between music apps directly. The latter could be a revenue stream for plugoni vendors, and the hub could be a free, unified mechanism for exchanging musical note data that works on Windows, MacOs, Android, and ios devices. Everyone has less work to do, and Jules has less bugs, because the interface code is unified and shared.

here’s a pic )


I’m confused about all this talk of virtual USB devices.

Both USB and HID have support for media sensing (connect / disconnect notification). It’s not exactly clear why the virtual USB device is needed. From my limited understanding of USB the problem is that the interface for retrieving MIDI information for a USB device by directly using the native USB API, is vendor specific. Of course, if you go through the MIDI driver then it is generic (since the vendor provides the necessary driver). What I am envisioning is a stop-gap solution is to first implement a useful USB suite for JUCE. libusb would be a good place to look for getting started. Then add some platform specific magic to figure out how the USB device relates to the MIDI device, and get notification for connects and disconnects. Finally, create a new API that combines the JUCE MIDI support with the USB apis, to provide notification for MIDI devices which are plugged in via USB.

This would be a hybrid solution - we use the existing JUCE code for the MIDI I/O, and some new USB code to detect the connect / disconnect.

Ah, well that would be a superset of USB functionality above and beyond a PI ‘music hub’ alone.

If a shared hub provides an interface to MIDI devices, then the code for the MIDI interface moves into the hub, and isn’t included in every JUCE standalone. Instead each JUCE standalone simply communicates with the hub. That provides a uniform interface to standalone JUCE applications for note, clock, sysex, etc, and other MIDI devices connect to the shared hub instead. So Jules can concentrate on making MIDI work on that single USB MIDI interface to the hub, instead of supporting separate APIs on each platform for other MIDI interfaces as well.

Simultaneously, as JUCE also provides plugins, the plugins can share objects in the hub’s upper level dataspace, which may include additional music data such as the name of a melody, composer, key, time signature, rhythm information, and so on. For that level, the hub could export one dialog for all applications sharing data, so that the same UI could appear for application interconnectity regardless which app’s configuration panel is opened. Then one application could change melody in anothr; a range of new apps are possible which can create, play, and change melodies in far more ways than is possible with the current MIDI interface; and composers would be pleased, because their names could appear together with MIDI data in the shared data space. As more musicians are starting to include melodic data and other apps with their music, This is a good market opportunity for a third party or consortium of some kind. I’m not the person to make the software. but the need and benefits seem obvious to me, for Jules, for all his customers, and all the customers of his customers. The question is, is there anybody who can step up to the plate, offload Jules of the MIDI interface in this way, and also provide the hub freely on Windows, Macos, Android, and ios platforms?

But I have to get back to work on some less grand projects, and raise some money for a JUCE license later this year. Be glad to hear from you folks )