Repository navigation
Implement keyboard event hook on Windows - #212
Merged
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/niner
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/niner
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>
BurningTreeC
added a commit
to BurningTreeC/gainstagefx
that referenced
this pull request
Sep 24, 2026
A Windows host's message loop sees every keystroke before the plugin. The reporting host dispatches the key-down but keeps the WM_CHAR for its own shortcuts, and baseview holds each key-down back until its WM_CHAR arrives, so every letter was lost while Delete and the arrows worked. Backport upstream baseview's WH_GETMESSAGE keyboard hook (RustAudio/baseview#212), narrowed to exist only while a text field is open, so the host keeps the space bar the rest of the time. The editor switches it with the new baseview::set_text_input, kept in step with the save dialog. While a field is open the window also takes Win32 focus and gives it back afterwards. The hook is reference-counted per thread and removed when the last field closes or its window is destroyed. Saving from scratch no longer offers the "-" (nothing loaded) as a name. Native tests under Wine reproduce the lost letter and cover the fix, gating, focus and hook lifetime. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XDe7439i4Ka11arrBhnXq2
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
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:
