-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optional keyboard passthrough #259
Comments
On second thought, if the suggestion of having a list of individual keys seems to complicated for what it's worth, just having the variant with Reason being that once one starts to forward lots of individual keys (esp. numbers and letters), it likely ends up with oneself forming the habit of always "hovering with shift key held" whenever one wants to input some text into text fields, cause that's less of a mental burden as keeping track of which keys are being forwarded and which aren't and when |
The main problem with keyboard handling (and the reason why yabridge's current approach is about as good as it gets) is that there is (to my knowledge, I've spent hundreds of hours tweaking editor behavior) no real way to detect that the main Windows child window made a If REAPER won't implement similar behavior to Bitwig and moving your mouse off to the side a bit to press space is too much work (remember, you don't need to click, just move your mouse outside of the plugin's client area) then you could try using a MIDI controller for play/pause, or use some sort of WM scripting tool to send a space press directly to REAPER's main window. |
Wasn't aware of that, so for now I'm simply trying to keep that mind. the rabbit hole
This sent me down somewhat of a rabbit hole. I had a couple takeaways from that:
So coming back to this comment, at least to me it seems like that isn't entirely the case:
new suggestionAll this research actually makes me pretty much abandon my initial feature request and instead think if the following isn't possible for So the new proposal is this:
I know you've wrote this I sense some kind of frustration in that short phrase, but would the above proposal maybe be doable? Or is there a rather clear reason for why that simply can't work? Would it maybe break dragndrop (maybe it would just work after further comments
I honestly didn't think of that at first. But yeah, as noted, I've given up on having individual keys being forwarded as I initially
IMO the goal with these kind of workflow matters is not "works with a bit of effort by the user", but "as frictionless as possible (i.e. least amount of mouse and keyboard interaction needed)". Or in this specific case, "same as for other OS and native linux plugins".
Yes, I've been aware of that. Certainly better than having to click in addition.
Without even trying that out, the thought of having to reach one of my hands away from keyboard or mouse for something like hitting play/stop already feels annoying. Basically more workflow friction, not less.
This made me remember that I've actually done things like that already in the past (e.g. using
Using this python script in e.g.
IMO, scripting user input like that should be a last resort. Always more robust all around for the end user if an application provides such functionality natively. |
+1 on this. Just installed Melodyne using YaBridge into Reaper. Was very happy to see it loaded up with no issues, but quickly realized keyboard shortcuts do not work at all, which slows me down by a lot. (Using GNOME on Wayland btw). Hope this issue can get resolved soon! EDIT: upon further testing, I found out that shortcuts in Melodyne do work... but only when 1) "Send all keyboard input to plugin" is checked and 2) when the mouse is in the area that is outlined on the screenshot: This small area is the only area drawn by Reaper - the rest is Melodyne (+ the GNOME window title bar). So I guess that's why it's capturing the events? Not sure whether this is realted, but it would definitely be great to get this fixed. EDIT 2: the same setup with the same install of Melodyne works fine in Ardour. So it seems like this is truly a Reaper-only issue. EDIT 3 (final edit for today): using Carla-Rack inside of Reaper and loading Melodyne through it works as expected. This is a crappy setup and it comes with its own problems, but for now it works. Still hoping to get it resolved. |
Feature description
Hi robbert-vdh!
First off, thanks to you and the community for creating
yabridge
!I recently started trying it out to see how it performs.
Status quo
One thing that stuck out bit negatively to me is the keyboard input handling, specifically on
reaper
.Right now it's like this:
reaper
When I looked through existing issues, I found this one: #38
I certainly can see that it was quite a journey to get where it is now!
But even though it's an older topic, I hope suggestions are still welcome.
I'm not sure I fully understand the last part. Focus only seems to return to
reaper
when placing mouse outside of plugin window.Furthermore, the README mentions in section
Input focus grabbing
, that there's this mechanism regarding "holding shift key" to direct allkeyboard input (e.g.
spacebar
) to plugin window. I tried it out withbitwig
just to see how that behaves. It's certainly better than inreaper
.Suggestion
To get to the main point of me writing all this, here is a suggestion on how
yabridge
could handle keyboard input even better from an UX perspective:I assume there's a way to forward keyboard input to host even if mouse is over plugin window (i.e. technically possible).
If so, let's say we add something like this
keyboard_passthrough
option toyabridge.toml
:Or even something like this:
Then the behavior could be like this:
plugin group
to plugin window, except for those events that are listed in thiskeyboard_passthrough
listplugin group
to host (except modifier keys likealt
,shift
, etc. when used in conjunction with mouse events)Why would this be helpful?
From a workflow perspective, I certainly need the ability to have at least certain keys reach the host (
reaper
) by default at all times. I simply use this way more often than I type anything into a plugin window's input box.But I'm aware that different users have different needs and the way things are now is perfectly fine for them.
This suggestion would allow for letting users decide the behavior themselves.
The above config ideas are based on editing
plugin groups
.But it might make sense to have a "global"
keyboard_passthrough
list as well (e.g.spacebar
might be a key that always should be forwarded to host, regardless of plugin group).Of course, this will make it bit more complex, cause then the "global" and "plugin group" lists need to be merged on the fly.
Furthermore some edge cases like have
keyboard_passthrough: true
set globally, but then also having a list of keys in aplugin group
would need some precedence re evaluation (e.g. "global" wins in this case).But IMO it's important to have both the
global
and theplugin group
specific configuration, as this gives the greatest amount of flexibility to the end user, helps avoiding having to repeat a common setting for all plugin groups and likely will cover most workflow scenarios that could come up.Possible technical challenges here might be:
keyboard_passthrough
list in case of individual keys:Do you think this is technically doable?
Maybe I'm missing something for why this is a bad idea. So I'm open to critique or suggestions!
Anything else?
Some technical notes:
The text was updated successfully, but these errors were encountered: