Implement keyboard event hook on Windows#212
Merged
micahrj merged 13 commits intoRustAudio:masterfrom Oct 29, 2025
Merged
Conversation
micahrj
requested changes
Oct 20, 2025
micahrj
requested changes
Oct 22, 2025
Contributor
Author
|
(Just for the record: it turns out the message zeroing is in fact important (causes duplicate inputs if omitted) and we agreed in the Discord to leave it in) |
micahrj
reviewed
Oct 23, 2025
micahrj
approved these changes
Oct 23, 2025
Hornfisk
added a commit
to hyperfocusdsp/slammer
that referenced
this pull request
Apr 22, 2026
The pinned nih-plug commit `28b149e` transitively pulls baseview at `9a0b42c` (via egui-baseview) and `579130e` (direct). Both pins predate RustAudio/baseview#212 — "Implement keyboard event hook on Windows" — which adds a `SetWindowsHookEx` keyboard hook that forwards WM_KEYDOWN to the baseview window. Without it, Win32 hosts (and the standalone harness here) never deliver key events to egui. Confirmed via diagnostic logging in the previous commit: zero `[keyboard] event #...` lines in slammer.log after a full user test session on Windows, despite audio and mouse input working fine. Patch baseview via a `[patch."https://github.com/RustAudio/baseview.git"]` entry pointing at a Hornfisk/baseview fork at master (237d323, which includes #212). Cargo requires the patch source URL to differ from the URL being patched, hence the fork. The PR is a pure add with no public API change — both dependents compile unchanged. Lockfile delta: only the two baseview entries are replaced. All other pinned versions are preserved.
Hornfisk
added a commit
to hyperfocusdsp/slammer
that referenced
this pull request
Apr 22, 2026
Windows standalone is now usable end-to-end: T/Space shortcuts fire, BOUNCE renders without crashing the paint thread, and any future panic lands in the persistent log with location + backtrace. Baseview patched to RustAudio/baseview#212 so plugin hosts that intercept keyboard messages (Ableton etc.) route them to Slammer. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR implements keyboard event hooking on Windows, a technique also used by JUCE to get around restrictions on keyboard input imposed by various hosts. By intercepting Win32 messages using
SetWindowsHookEx, we can bypass the host and forward keyboard messages to thebaseviewwindow directly.This resolves the longstanding issue with keyboard input in Ableton, and likely renders many existing hacks for this problem obsolete (though I haven't tested that part yet.)
The meat of the implementation is in the new
src/win/hook.rsmodule, which registers a simple event hook that intercepts keyboard-relatedWM_events addressed tobaseviewwindows, and forwards them into the relevant window's event handler directly, consuming the message in the process.Couple notes:
baseviewwindows and forwarding events to them inhook.rs. If anyone has any better ideas for how to achieve this, I'm all ears, but it does seem to work as is.dtorcrate to thewindowsdependencies to properly detach the hook on DLL exit. Hope that's okay!The keyboard hook in action:
