Show HN: Perfect Bluetooth MIDI for Windows
I bought a Roland FP-90X piano partly because it had Bluetooth MIDI. On my Windows 11 PC, pairing succeeded, but my DAW couldn't see the keyboard, and notes I sent from the PC never made the piano sing. After a regrettable number of evenings, I'd separated this into three independent bugs stacked on top of each other.
The first one is the famous one: Windows only natively exposes BLE-MIDI through the WinRT API, which almost no DAW polls. So even when pairing succeeds, MIDI apps still don't see the device. The usual workaround is MIDIberry + loopMIDI, but I couldn't get that combination to work reliably in my case, and I wanted a single-app solution. The new Windows MIDI Services stack ships with a feature called loopback endpoints: anything written to one comes out the other, and any winmm/WinRT/WMS app sees them as normal MIDI ports. So the app does WinRT BLE-MIDI in, WMS loopback out. That solved direction one, piano to PC.
Direction two, PC to piano, still didn't work. NoteOn writes were getting ATT-acked, but the piano stayed silent. I tried both write modes (some BLE-MIDI firmware silently drops one or the other), poked the proprietary ISSC characteristic. Every variant ATT-acked, every variant produced silence. So the bytes were reaching the piano. Something above the GATT layer was discarding them.
After ruling out pairing, encryption, write-mode, and proprietary characteristics, the only obvious lever left was the MIDI channel itself. The FP-90X has a panel setting called Transmit Channel, default 1. Yet it turns out the FP-90X actually receives on channel 4 (and it can't be changed). Notes I sent on channel 1 were being GATT-acked and silently dropped at the synth engine because they weren't on the channel the engine was listening to. Zero feedback at any layer. The fix had to live up at the application layer, so I added a Detect button that plays N test notes ascending on each channel from 1 to 16: you count the notes you actually hear, and that number is the receive channel. Saved per BLE MAC, about 75 seconds, done forever per piano.
Tech stack: .NET 10, Avalonia for the UI (the BLE/MIDI side is Windows-only but the UI layer is portable), Microsoft.Windows.Devices.Midi2 packages for WMS, Windows.Devices.Midi (WinRT) directly for BLE rather than relying on Korg's older WinMM driver. MIT, single self-contained ~21 MB exe, no installer, no telemetry, no account.
I built it for myself and use it with my FP-90X to play through a few apps and Web MIDI sites. Pete from the Microsoft Windows MIDI Services team commented positively on the BLE integration when I shared it on r/synthesizers (https://www.reddit.com/r/synthesizers/comments/1szvuiq/comme...).
Site (with screenshots): https://mayerwin.github.io/Perfect-Bluetooth-MIDI-For-Window...
Source: https://github.com/mayerwin/Perfect-Bluetooth-MIDI-For-Windo...
Long-form technical writeup with the full debugging story: https://dev.to/mayerwin/why-your-bluetooth-midi-keyboard-sil...
Personally tested with my FP-90X only. The BLE side is generic, so other keyboards (WIDI Master, CME, Yamaha MD-BT01, Korg microKey Air, ROLI Seaboard, etc.) should work, but I haven't confirmed individually. Device test reports, issues, and PRs very welcome.
Discussion (17 Comments)Read Original on HackerNews
https://microsoft.github.io/MIDI/
Doing Direct-To-Bus MIDI handling can't be replicated in modern architecture like the ST was configured.
That said, given the popularity in analog semi-modulars to be used as DAW outboard with MIDI over USB implementations that add latency and jitter, is it even a consideration for most users?
Ableton and other performance oriented DAWs automatically compensate for MIDI and audio latency caused by plugins and devices; in Ableton's case it will delay the audio by the overall system latency, and/or bypasses plugin delay compensation only for armed/monitored tracks, making them more responsive.
The real answer to the question is, as always, to use hardware sequencers and control voltage triggered off your master clock or DAW. SQ-64 is as rock solid as an Atari ST for CV work, although the 64ppqn limit doesn't match the Atari ST' 384pqqn capabilities. That said, standard MIDI Beat Clock is much lower at 24 PPQN. If you want to go all Autechre/Aphex Twin there's plenty of ways to skin that cat.
I have created 20 utils or so with the help of Claude, in order to practice multiple things like reading sheet music, or rhythms, or different scales. I never expected it to be that useful as my new Yamaha was bought before Claude existed, and having a cable that just works is so great.
I have spent way less effort doing all my utils than this man into just connecting its machine.
Before using it with Claude I used them a lot with Synthesia and GarageBand, but with Claude is like having a personal trainer.
I haven’t used Windows for ages. Does this mean that almost every Windows user with any Bluetooth MIDI keyboard is unable to use it out of the box with their DAW without installing additional third-party software?
Does it apply even to latest version of the very widely used DAWs like Ableton, Pro Tools, FL Studio, Reason, and Reaper?
Surprisingly Windows audio stack is a mess. I have a mini keyboard with Bluetooth and it was an adventure to get it working in Windows. In Linux it was pretty much plug and play.
Low latency audio drviers are also messy in Windows when not using an audio interface with well written ASIO drivers. Pipewire in Linux is much easier to configure. Looks like MacOS also does not have this driver problem.
It is surprising. Because most audio plugins and DAWs support only Windows and MacOS.
Do you know how to spot a Windows user ? They print-and-scan to merge their PDFs.
I probably have 5 or 6 things installed on my Mac like Scroll Reverse and Rectangle, just trying to beat the window manager into something that resembles useable.