You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the NSView's keyDown/keyUp methods are never getting called in Reaper when there's keyboard input with the plugin window in focus. neither turning on "Send all keyboard input to plugin" or opening the UI in its own window changed the situation.
curiously, the events are still consumed on some level as Reaper is also not receiving keyboard events when the plugin window is in focus (space doesn't toggle playback, for example).
i'm running macOS 13.5.2 and Reaper 6.43 and using baseview with nih_plug
wondering if the problem actually lies within nih_plug: the VST3 onKeyDown implementation returns kResultOk, but according to the API docs it should return either kResultTrue or kResultFalse depending on whether the key is consumed. perhaps kResultOk is interpreted similarly to kResultTrue?
i have a feeling that Reaper might be using these VST3 key handlers more pedantically than most hosts
returning kResultFalse from the VST3 key handlers indeed allows the key events to flow to the plugin (this has been fixed in nih-plug now robbert-vdh/nih-plug@245add6)! but now the problem is that no key events are being consumed from Reaper's perspective, so e.g. the spacebar and enter keys will always get passed to Reaper. to fix this, baseview would need to have some way to signal to the VST3 key handlers about when to consume/ignore key events, but not sure what that would require.
I'm blocked by this same problem. I'm using NIH-Plug and implementing the UI with egui. Key input doesn't work in either the VST3 or CLAP versions of the plugin. Is there any possibility of this getting fixed?
I'll be closing this, since the suggested fix of #202 has been merged, and NIH/Nice-plug's implementation has since been changed to properly return notImplemented for these event handlers, which should also fix the issue. I'm also not able to reproduce the issue on my system for now either.
Please comment if this is actually still an issue for any of you, and I'll reopen this.
Activity
httnn commentedon Mar 18, 2024
wondering if the problem actually lies within nih_plug: the VST3
onKeyDownimplementation returnskResultOk, but according to the API docs it should return eitherkResultTrueorkResultFalsedepending on whether the key is consumed. perhapskResultOkis interpreted similarly tokResultTrue?i have a feeling that Reaper might be using these VST3 key handlers more pedantically than most hosts
httnn commentedon Mar 18, 2024
returning
kResultFalsefrom the VST3 key handlers indeed allows the key events to flow to the plugin (this has been fixed in nih-plug now robbert-vdh/nih-plug@245add6)! but now the problem is that no key events are being consumed from Reaper's perspective, so e.g. the spacebar and enter keys will always get passed to Reaper. to fix this, baseview would need to have some way to signal to the VST3 key handlers about when to consume/ignore key events, but not sure what that would require.this is also an issue with JUCE btw: https://forum.juce.com/t/reaper-stealing-spacebar-keystrokes-in-texteditor/30689/8
peastman commentedon Jan 4, 2025
I'm blocked by this same problem. I'm using NIH-Plug and implementing the UI with egui. Key input doesn't work in either the VST3 or CLAP versions of the plugin. Is there any possibility of this getting fixed?
peastman commentedon Feb 11, 2025
This problem can be fixed by the code change suggested in #202.
fix(macos): override hitTest: so first click in non-key window reache…
fix(macos): override hitTest: so first click in non-key window reache…
fix(macos): override hitTest: so first click in non-key window reache…
fix(macos): override hitTest: so first click in non-key window reache…
fix(macos): override hitTest: so first click in non-key window reache…
fix(macos): override hitTest: so first click in non-key window reache…
fix(macos): override hitTest: so first click in non-key window reache…
prokopyl commentedon Oct 2, 2026
I'll be closing this, since the suggested fix of #202 has been merged, and NIH/Nice-plug's implementation has since been changed to properly return
notImplementedfor these event handlers, which should also fix the issue. I'm also not able to reproduce the issue on my system for now either.Please comment if this is actually still an issue for any of you, and I'll reopen this.