Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

Perfect Bluetooth MIDI for Windows

Details

External ID
47972888
Source
HN
Company
—
Product
—
Website domain
—
Launched
May 1, 2026
Cohort
—
Upvotes
105
Upvotes percentile
0.9127625201938611
Tags
—
Fetched at
Sept. 7, 2026, 9:26 p.m.
Updated at
Sept. 7, 2026, 9:26 p.m.

Description

Hi HN, I'm Erwin. I built a small free open-source utility that bridges Bluetooth LE MIDI keyboards into the new Windows MIDI Services stack so any DAW or Web MIDI app can use them as if they were wired.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.

Enrichment

Theme
audio and music production tools
Vertical
Horizontal
Function
Hardware & robotics
Audience
B2C
AI stance
Not AI
Project type
Commercial product
Normalized one-liner
bluetooth midi support for windows
Manually corrected
False

Could you build this?

No Building a low-latency MIDI bridge between Bluetooth LE and the internal Windows MIDI Services driver stack requires specialized Windows C++ systems programming, Bluetooth GATT profile handling, and real-time audio/MIDI drivers.

What it would actually take: Implementation requires C++/WinRT interfacing with the Windows MIDI Services (MIDI 2.0) API and Windows.Devices.Bluetooth APIs. The hard piece is jitter-free timing compensation, handling packet fragmentation/retransmissions over BLE with minimal latency, and integrating directly into the Windows audio subsystem. It requires specialized knowledge of BLE MIDI specifications and Windows system-level device driver programming.

Discussion

20 comments analyzed.

Competitors mentioned: libremidi, Apple's BLE MIDI implementation, Microsoft's Windows 11 MIDI drivers, PDF Expert

Concerns raised: MIDI clock protocol is inherently unstable due to network jitter and latency, Windows audio latency problematic for real-time applications like Rocksmith, BLE implementation more complicated than USB MIDI, Latency may vary by Bluetooth adapter, Project untested on Windows 10

Feature requests: Multi-client support, BLE polling capability

Competitors

Other products that read as similar to this one — 215 launches clear the similarity bar, closest 8 shown.

Attention rank: #21 of 216 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).

Launched 180 days after the earliest competitor.

Other launches for this product

Same idea, different domain

Nobody's really built a hardware & robotics tool for Fintech yet.