bluetooth_midi.h

Why this is a thin file

Bluetooth LE MIDI is paired by the OPERATING SYSTEM, and every platform that supports it already has the screen for it. A plugin that drew its own would have to scan, pair and bond -- the half of Bluetooth that needs permissions, entitlements and a user who trusts a plugin with them -- to arrive at a worse copy of a dialogue the user has seen before. So this opens the system's, and says plainly where there is none.

• macOS: CoreAudioKit's CABTLEMIDIWindowController (10.11 and later), shown MODELESSLY -- the host keeps running, and a modal loop inside a plugin is a loop the host is not running. A device connected there appears in CoreMIDI, which is what MidiInput reads on a Mac. COMPILED against the shim in tests/au_shim, never run: no Mac in this loop.

• Windows: Settings > Bluetooth & devices (the ms-settings:bluetooth page), opened with ShellExecuteW. RUN here, up to the launch (the tests set SONORE_BLUETOOTH_MIDI_NO_LAUNCH so a test run does not open Settings). Said plainly because it matters: a BLE MIDI device paired there is reached through Windows.Devices.Midi, and this SDK's MidiInput uses WinMM, which does not list Bluetooth LE MIDI ports. Listing them here through Windows.Devices.Enumeration was considered and NOT built: it would name devices MidiInput cannot then open, and finding UNPAIRED ones needs an association-endpoint watcher running for seconds -- a WinRT subsystem for a list the Settings page already shows.

• Linux: none. Pairing is BlueZ over D-Bus (org.bluez.Device1.Pair), which this SDK does not link, and there is no system dialogue to open that every desktop shares. isAvailable() is false and the reason says what to do instead.