Earlier quoted context omitted.
I've kind of done this, just without the actual "build" part—I instead use a Wooting computer keyboard (which has the hall effect switches you're referring to), and I've written some program to emit MIDI based on key velocity. I've been using it very frequently for a few years, and can confirm it's quite fun to use, though I don't have much experience playing other keyboard instruments and haven't tried to learn it s…
> I've written some program to emit MIDI based on key velocity. nice! Is the velocity code on the firmware side? Is that why it's not included on the demo site?
I've been meaning to look into adding Wooting support, just haven't got round to it. This would require either WebUSB or WebHID which are still "experimental", and I'm not sure if there will be latency issues.
The program I created for computing velocity and emitting MIDI is here [1]. When it's listening for keyboard data it does it in another thread so that it can attach fairly accurate timestamps to the key events, without being subject to pauses from Gtk or something. If there's inconsistency between the key event times and the relative timestamps, the velocity detection can be noticably off. I've noticed this in Wooting's own MIDI application [2]. Hopefully WebUSB/WebHID includes timestamps in the data, so it doesn't have to be subject to JS GC pauses.
As well as the Rust program above (possibly Linux-only, though should be easily adaptable to work on Windows/macOS), I've written an Android app that does the same thing so I can use it without a computer (though in Android you have to take control of the USB device rather than just read the HID data), but I haven't uploaded the code anywhere.
[0] https://gitlab.com/Maxdamantus/bayan
[1] https://gist.github.com/Maxdamantus/c5d5133cab1ef3596ac589d2...
[2] https://github.com/WootingKb/wooting-analog-midi ... as well as issues with timestamp jitter, this application seems overall a bit bloated for my taste (web-based app using Tauri), and it's inconvenient since it will continue to generate MIDI when you're focused on other applications, so you'd have to close and open it (slow startup time too) each time you want to use it. their timestamp jitter occurs because the Wooting SDK (at least at the time, haven't looked at it recently) worked by running a thread that would update a shared HashMap and you would have to poll that hash map; it wasn't possible to see all updates, and there were no timestamps attached. I avoided the SDK and instead just read the data directly from the "hidraw" device.