Skip to content
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

Surge KeyBindings #611

Closed
baconpaul opened this issue Feb 15, 2019 · 11 comments
Closed

Surge KeyBindings #611

baconpaul opened this issue Feb 15, 2019 · 11 comments
Labels
Design Required We need to design a solution to this issue Linux Issues which only occur on Linux UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc.

Comments

@baconpaul
Copy link
Collaborator

baconpaul commented Feb 15, 2019

On linux I had to disable arrows to navigate patches because of the way menus are implemented in vstgui there. But it got me thinking we should think more about keybindings.

Here's some ideas. Not coding anything until I get some feedback, but

  • p / shift-p move forward or backwards a patch in current category (mac/win get < > also)
  • c / shift-c move forward or backwards a patch category (mac/win get ^ v also)
  • z / shift-z zoom up or down 10% (mac win get +/- also)
  • A / B change screen to A or B
  • 1-6 select modulation source 1-6
  • shift-1-6 select scene modulation source 1-6 (may be hard)
  • control 1-8 select control modulation 1-8 (may be hard)
  • tab - toggle modulation green blink (works today using tab)

Your thoughts welcome.

@baconpaul baconpaul added the Design Required We need to design a solution to this issue label Feb 15, 2019
@baconpaul
Copy link
Collaborator Author

@esaruoho reminds us that the person who implements this should update manual and perhaps in app help also

@baconpaul
Copy link
Collaborator Author

Oh #500 willcouple with this also

@esaruoho
Copy link
Collaborator

what happens if i have logic musical typing keyboard enabled, and press A (which is C-note), does both the A/B screen change occur, or just the note?

@baconpaul baconpaul added this to the 1.6.n milestone Feb 24, 2019
@baconpaul
Copy link
Collaborator Author

The opportunity to conflict with the keybindings in multiple daws makes this too risky. I'm going to close it.

@mortfell
Copy link

I was just thinking about something like this specifically for modulation sources....
The ability to switch to modulation assignment mode by hitting "tab", or "mouse 3" in Surge is so good! I am already starting to wish other synths would implement it. It would be really great to be able to continue that idea. Selecting mod sources with keyboard sources with this layout:
surgeKeyMod

I think this lines up really well, the most mapped sources (for me at least) The first couple LFOS, velocity, and Macros 1-4 are on the left side of the keyboard, which makes them easy to select without looking. Clicking the one that is key for the already selected modulator could switch between unipolar and bipolar also?

I think this could be a really neat feature for sound design!
Your mouse cursor would be able to spend more time in the parameter design area of the interface your left hand could stay on the left side of the keyboard. I'm not sure how doable this idea is.

With regards to being risky

  • Since this layout wouldn't require any modifier keys would it be less invasive?
  • I know it wouldn't work in every DAW but that wouldn't really be Surge's fault, a lot of DAWS seem to be able to play well with plugin keyboard shorcuts.
  • I'm thinking of Renoise Redux.... It's basically a tracker inside a plugin, it uses one button keyboard shortcuts and accepts key input. Works really well in every DAW i've tried it with. (maybe the issue of debugging all of that is unrealistic though)

Hopefully this isn't annoying to post this here in a closed thread. Just think this would be a really cool feature that I haven't seen in another synth.
I was about to start a new feature request for this and noticed this so I thought I'd ask here.

@baconpaul
Copy link
Collaborator Author

Not annoying at all. But I think the idea to not do it was the right one.

The wide variety of DAWs and keybindings scared us off, basically, especially since there's uneven support of suppressing or passing. All the keys you mention are bound in logic for instance. Reaper is even starting transport if you put a space in a patch name right now.

So while I would love this (I mean, heck, I use emacs, I love the keyboard) I haven't figured out a safe way to do it which will not mean I get a report that some DAW I haven't heard of can no longer play because I ate the p key or something.

@mortfell
Copy link

ahhh i see.
I didn't know that could happen.
Like its holding on to keyboard input, even when it's interface is closed?
I personally don't really mind if a plugin is taking keyboard input when it's interface is open. ( it is annoying when it takes spacebar though, I guess thats the issue. different daws have different important keys)

Perhaps someday it could be considered again as an optional setting you can turn on in the menu or a config file, just for people who want it. Would be very cool!

@baconpaul
Copy link
Collaborator Author

No it’s worse than that. You do “Store” on a patch in Windows Reaper in Native mode and call the patch “My CoolPatch” and when you press the space after ‘y’ transport starts!

You are correct, though, that we implemented this before user preferences so I’ll reopen it and think about making it togglable with default as off. That’s a good idea.

@baconpaul baconpaul reopened this Aug 14, 2019
@mortfell
Copy link

Nice Ok thats great! Excited to test whenever you get around to implementing something.

Oh yes, I've noticed it does that with REAPER when writing in text fields. That's actually fairly common with plugins in REAPER in my experience, not sure why. Maybe I should compile a list of plugins I've found that do that and send it to them. I've gotten really used to the "shift+spacebar" workaround.

I was actually talking about a different common space bar issue.

Some plugins completely hog ALL spacebar input when open.
(Melda EQ for instance used to do this but not anymore)
So if you are tweaking in the plugin and want to stop and start playback you have to mouse focus out of the plug-in, space-bar and then go back to what you were doing.

@baconpaul baconpaul added the UI Issues related to UI look&feel label Aug 14, 2019
@baconpaul baconpaul modified the milestones: 1.6.n, Currently Unscheduled Oct 4, 2019
@mkruselj mkruselj added UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc. Linux Issues which only occur on Linux and removed UI Issues related to UI look&feel labels Feb 5, 2020
@windowsrefund
Copy link

Regarding the patch browser, I'd say at a minimum, it's all about not closing the menu once a patch has been selected. That way, I'd be able to navigate through the menu with arrow keys. Enter would select the patch and Exit would close down the menu. Personally, I'd avoid app-specific "2 hander" bindings especially when it comes to patch browsing. Most of the time when I'm auditioning patches, I've got 1 hand on my MIDI controller anyway. The current hardcoded rodent-based menu navigation thing is kinda unusable for auditing purposes in real time since it forces the user to start from the beginning of the menu tree each and every time. Even if I were to loop over a clip or something in my DAW in order to provide a constant stream of input, having to start from the root of the navigation menu every time is too tedious.

The latest UI for ZynAddSubFX (I forget the name) solves this problem very nicely with their "filter" design which allows the user to drill down. The point being is that the navigation is always visible so the user never has to start from the beginning when they're shopping around.

@baconpaul
Copy link
Collaborator Author

Surge definitely needs a better patch browser which among other things allows easier browsing. That’s #2359 plus loads of discord and slack chat. My guess not in the next release but maybe the one after.

But keybindings are really not a good idea with the variety of daws and their handling. We should close this particular issue, (although #1257 has interesting convo)

For now the best we have is the patch next previous keys in the ui.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Required We need to design a solution to this issue Linux Issues which only occur on Linux UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc.
Projects
None yet
Development

No branches or pull requests

5 participants