No, it's on the software (computer) side. It's not in the demo site because I created that in 2019 [0] for use with a regular keyboard (since I was having issues with the software I'd previously been using for playing MIDI). I only upgraded to the Wooting keyboard in late 2021.
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.
[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.
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.