Closed baconpaul closed 2 years ago
Oh and thank you!
Yeah, the menu does work so it's also what I've been doing. I brought this up because it'd be nice to have access to all the patches under a specific category from all authors. But for now like you said using the menu and also the jog controls does work. ☺️
On 20 Nov 2021, at 14:54, Paul @.***> wrote:
This is great feedback and I will update my todo list here in the beta period. yes the patch tool has no values now and some of the sub screens are also not accessible yet.
to load a patch I have been using the show menu action on the patch selector. That brings up the menu which at least on mac I can traverse with a screen reader. Does that not work in your environment?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/surge-synthesizer/surge/issues/4616#issuecomment-974653551, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAABTIPZNYWA5WJV2XGKTTUM6R7TANCNFSM45YHRRLA.
Yes I have a new typeahead overlay which I just haven’t added reader support to yet. It and the mod list are on my radar
I will also figure out how to check tab order. I think my Python automation lets me do that
super glad it is working out for you and appreciate the help
Hello folks! i am just joining the watch of accessibility improvement on Surge synthesizer because I am starting to turn on this synth in my professional work. I see milestones and I have no one word to say anymore. Just waiting! I am just waiting to step sequencer be accessible. As I understood, drawing gives us the flexibility with lengths and scales of sequence modulation. If it is that, I cannot imagine how to realize this in accessible model. But if 16 these sequence cells obey the LFO rate and have equal lengths it can be provided as 16 sliders where we can set the needed scale value at this step. Excuse me if this sequencer has been realized and my oppinion is been late... In any case @baconpaul you have to know: you do the great work! Thank you for that!
Nope it’s still not done
with some of our heavily drawn controls I have been adding invisible child components which are exposed via the screen reader api. That’s how the wavetable jog and select works for instance, with sort of unpainted accessible buttons to match the hand painted bits. When I turn to step sequencer I imagine I will make it look like 16 vertical sliders to the screen reader. At least that’s my plan right niw
Hey folks just an update
With the next nightly (which should be available after around noon eastern Dec 9) we will have the ability to create modulations with the reader api and do some basic step sequencer manipulation.
the modulation works really well. Each modulation source gets 2 or 3 buttons: Select, Arm and Target. "Select" means it is the modulator in effect for edits, "Arm" means it is modulating and "Target" works only for LFOs if you want one modulator to modulate an LFO. My script finds vecocity, arms it, and then changes the modulation on pitch, and it all works through the reader API.
The step sequencer is a little harder. For a moment I thought we would have to ship 1.0 with nothing, but i have a better, albeit somewhat incomplete, solution. If you change the LFO type to step sequencer you will get 16 new sliders in the UI (Step Value 1 .. 16). These respond to values from -1 to 1 to modify the SS and it works. The only problem is, because of a real annoyance in the way the surge UI works, they are at slightly the wrong point in the component hierarchy, peered with the LFO type. I may be able to fix this. I am also considering if I can add the trigger and rotate buttons cleanly to step, so may be updates in the next 8-10 days
Finally the new modulation list and the typeahead patch search are still totally "dark" to accessibility. I plan on getting at least the mod list working.
But right now, you can manipulate the entire core synth including the mod matrix using a screen reader (or will be able to like I said with the next nightly later today). I would continue to enjoy feedback. We still plan a production release of surge in mid Jan 2022, so have time if you find things, but with the holidays approaching we are getting to the end of our cycle.
Oh I'm a goof - I have figured out a solution to that mis-grouping. I will try and merge it today :)
Hello, @baconpaul !
Before starting I don't tire to thank you for your work!
I'm testing the step sequencer right now. Yep, you're right, we need a method to set an absolute slider value for example when we are drawing the tonal sequence (i.e., 0.000000>>0.300000>>0.600000 and etc). On Windows we have to use physical mouse wheel to set the needed slider value. It is not problem for most of the people because any Windows screen reader provides the option to route mouse cursor to specific control. I've found out that mouse wheel set the big steps when scrolling without any modificators and sets more little step when we are scrolling this with Shift key pushed. But even with shift key scrolling I couldn't set an accurace value. I would propose a few methods to do this:
Thank you again for your great work!
So the accessible interface provides a slider type when in step sequencer mode which responds to the set value method. On my mac I can find it with the screen reader and set a value just like i can on any other slider. Does this not work on windows?
(@outsidepro-arts if you can let me know your version of surge you are testing also that would be great; I added the step sequencer stuff just in the last 24 hours so you will have had to do a very recent download).
@baconpaul I'm testing the Surge-xt-win64-NIGHTLY-2021-12-10-0dd5206.
So the accessible interface provides a slider type when in step sequencer mode which responds to the set value method. On my mac I can find it with the screen reader and set a value just like i can on any other slider. Does this not work on windows?
The most of all modern accessibility actions and patterns does not supported by custom screen readers in Windows. However, the custom screen readers more fastest, less overloaded, it is extensible. All of VST plugins we are working with able to use only thanks to add-ons for these screen readers. So, no, unfortunatelly we cannot do this you described above. For example, popular screen reader NVDA provides the object navigation (it looks like as VoiceOver navigation on MacOS), but waits that you will interract with any control using standart key sending. That is why @ScottChesworth was beeing surprised that Surge doesn't provides linear navigation by Tab/Shift+tab. Finalizing, the most of custom screen readers can only process UIA events, but not generate this.
Well that is very disappointing news. I’ve done a lot of work to make the accessible features all bidirectional through the api.
I’m not quite sure what to do about your comment. With that being true, the work I’ve done will only be useful to mac users because the windows readers don’t support the full api?
can you manipulate sliders with your windows screen reader? Or press buttons?
@baconpaul You've doing big deal! Even if Surge accessible on specified platform - it is huge revolution! Believe me, this little defect of Juce accessibility will be fixed more easy than in other plug-ins where we need to have genius head comprehending zen to scan a pixels on a screen image, match image patterns to search for JUST ONE BUTTON! I am personally grateful to you even for this accessibility model, because for today Surge is first synthesizer which implemented accessibility!
yeah ha but lets try and get it right
so i just fired up windows and found i had one thing set wrong on the step sequencer. I'm going to do a new build tonight which perhaps you can try in a couple of hours
with that in place, using the windows accesibility inspector 'inspect' I can navigate to mainframe/lfo controls/step sequencer/step value 1 and send the accessible "Value.SetValue" action on windows and the step sequencer does change. (Without the change i've made that group is only on mac).
That's the same way I manipulate a slider
Does NVDA let you do that? Namely can you find the well named slider and send a setvalue to that with NVDA screen reader?
So I guess what would be really helpful for me to know is "What's the difference between what the built in accessibility inspectors on windows do and what NVDA does?" On Mac the inspectors and readers are all the same, and I'm kind of assuming that you can do things like find a button and press it using the 'press' action, or find a slider and set it using the 'set value' action. If that's not true then windows will be harder going (although with my upcoming fix, better at least!)
Does NVDA let you do that? Namely can you find the well named slider and send a setvalue to that with NVDA screen reader?
I don't know any method to send this action to any control by default in NVDA.
So I guess what would be really helpful for me to know is "What's the difference between what the built in accessibility inspectors on windows do and what NVDA does?"
MacOS has only one screen reader - VoiceOver and all users forced to use this. Therefore MacOS's accessibility inspection tools will guide you to one well right results for VoiceOver. Windows's inspection tools rely on build-in system screen reader (Narator) and do not suppose that user will be work with another screen reader ☺ Yeah, I've tested Narator with Surge and it really sets the needed value step by step. But we have note: Narator increases the slider value when user sends default action and decreases this value when the extended (or custom? I'm using not english language on my OS) action has sended.
I'll explore the NVDA UIA API abilities a little later: now in my country 07:38 AM, and I still didn't slep... ☺ @baconpaul
Ok! Well I’m still able to make changes to the exposed widget access layers so I look forward to what you find and suggest. I’m glad it works with narrator also - thst at least means my code isn’t wrong even if it isn’t great in nvda
appreciate the testing and patience
Hello Paul,
I also did some testing across yesterday and today on both Mac and Windows, and man I haven't gotten lost in preset browsing and experimentation like I did with Surge in a very long time! ☺️
For the Windows side, I tried with all 3 major screen readers and Narrator is definitely the one that's the easiest to use because it works the most like VoiceOver, with more hotkeys to jump from group to group and adjust sliders. JAWS is similar with its touch cursor, it also gives you an option to "adjust value" if a slider is navigated to. NVDA's object navigation just has one command you can use, "Perform primary action", and there doesn't seem to be any way that I see to do any other actions.
I'll raise this with the NVDA people because having a way to do secondary UIA actions will be useful in situations like this, but ultimately what you'll want to do if not for this version then for the next release is make it possible to tab to and adjust every slider with the arrow keys, with home and end to quickly set them to the minimum and maximum value. At the moment, if you tab through the interface I can get to the button to open the modulation overview, access the controls in the patch browser and formula dialog, but all of the other controls are skipped over.
Also, here's a couple other minor points I noticed that could be improved for all platforms:
Thanks once again for all your work!
Well that is profoundly useful @pitermach thank you. I am happy to help the NVDA people, or please do point them at this issue also (which I am sure we will keep open after our 1.0 release).
Keybindings in plugins are so hard. I need to figure out how to enable that without interfering with the DAW actions bound to those keys for users in non-accessible states (for instance, the arrow keys in surge in logic for me move my transport around and stuff). That said, i should have correct tab ordering so that also sounds like a bug. I'll look at the traversal orders.
I'll add these to the list at the top of the issue
We are planning a 1.0 release in mid Jan, but are pretty sure we will want and need a 1.1 also; so some things may push beyond 1.0 but I want it to be as good as we can get it as long as it doesn't introduce too much shipping risk at the end of our beta here.
And finally, thanks for the really wonderfully accurate feedback. It is very useful. I've never build anything this complicated with accessibility before and so appreciate the team effort!
Have a lovely weekend. I'll ping here when there's another update to test.
Yeah, that all makes sense. I'm not sure how Logic handles this stuff, for Reaper the plugin gets some keys like tab and the arrow keys and anything not assigned to a Reaper command, for other shortcuts there's an option you can turn on which gives the plugin all keystrokes. Unfortunately I don't use Logic so I can't comment how other plugins behave regarding this.
I believe at one point you suggested turning on the additional keyboard handling if a screen reader is detected. You could also just add a second option to the workflow menu to allow arrow keys to control sliders or tie it to the enable shortcuts option you already have there now.
On 11 Dec 2021, at 18:04, Paul @.***> wrote:
Well that is profoundly useful @pitermach https://github.com/pitermach thank you. I am happy to help the NVDA people, or please do point them at this issue also (which I am sure we will keep open after our 1.0 release).
Keybindings in plugins are so hard. I need to figure out how to enable that without interfering with the DAW actions bound to those keys for users in non-accessible states (for instance, the arrow keys in surge in logic for me move my transport around and stuff). That said, i should have correct tab ordering so that also sounds like a bug. I'll look at the traversal orders.
The LFO buttons is a bug and I thought I had it right. I'll look on my mac and add it to the checklist Those buttons change the LFO trigger state but, wow, you are correct, I didn't hook them up to anything yet! That patch refresh is a bug yup and that wavetable menu lack of a value is a bug I'll add these to the list at the top of the issue
We are planning a 1.0 release in mid Jan, but are pretty sure we will want and need a 1.1 also; so some things may push beyond 1.0 but I want it to be as good as we can get it as long as it doesn't introduce too much shipping risk at the end of our beta here.
And finally, thanks for the really wonderfully accurate feedback. It is very useful. I've never build anything this complicated with accessibility before and so appreciate the team effort!
Have a lovely weekend. I'll ping here when there's another update to test.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/surge-synthesizer/surge/issues/4616#issuecomment-991713182, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAABTMDAI77RMBJBCXW75TUQOAA7ANCNFSM45YHRRLA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Oh also regarding the tab order it's actually on both Windows and Mac that it's not working. If I have surge running as a plugin with Reaper and focus the main window, tabbing moves me between the modulation overview and the main surge group - so it sounds like the container that has all the sliders is what's in the tab order rather than the controls inside it. If I'm running the app as standalone, then the situation is similar, except I can also tab to the options button that opens the menu with options like the audio and midi settings.
OK! I swear this used to work but I will look before we ship for sure.
Are you testing with the tab key or are you testing with tab generated through a reader, out of curiosity?
So far as I know, there's no such thing as tab generated through a reader. The only modern screen reader that has an annoying tendency to intercept keystrokes is one called JAWS, but even with that, I don't think I've ever seen it prevent a user from moving through a tab order. Given that tab's not working for @pitermach on Mac either, I suspect the problem is somewhere at implementation level.
Hey @pitermach and @outsidepro-arts, when you've been testing on Windows, are you both using the latest stable release of NVDA there? I'm asking because @leonardder landed a fix for how JUCE sliders are translated. Thinking it might make a difference to what's being talked about here.
@ScottChesworth Yep, on 2021.3. The slider fix you mentioned is related to how NVDA reads their value, which does indeed also help in Surge as far as reading goes but we can't adjust them.
@baconpaul Yep, I was just pressing tab on the keyboard on both Windows and Mac.
Oh cool gotcha well I can test thst easily :)
thanks all.
Somewhat embarrassingly, along the way the one line I need to activate tab order traversal on every parameter got dropped as i moved code around. I've restored it and a nightly later tonight (Dec 13 US eastern time) should have at least tab order working. The rest of the issues are outstanding still but i will look at them tomorrow.
Oops, happens to the best of us ☺️
I also discovered another very minor glitch yesterday. If I change the Twist oscillators engine by adjusting the slider, the labels of the other sliders don't update unless I either close and reopen the plugin Window/standalone app, or change it by selecting a different engine from the right click menu.
Don't worry @baconpaul, nobody tells stories about that sort of thing at accessibility parties :)
Ha! Well anyway new nightly is up with corrected tab order These invalidation things (twist, patch browser name) are one i will have to dig into a bit...
A note to myself
There's "AccessibilityHandler::notifyAccesibiltyEvent" which I am not calling at all. That's why there's all these invalidation errors.
Can confirm I can indeed now tab to everything on both platforms.
Regarding this, something you'll want to do when you start on the arrow key stuff is that if you tab into a group of radio buttons (IE LFO shape), the focus should land on the radio button that's selected rather than the group, with the arrow keys then letting you change which button is checked. THis is how radio buttons behave with keyboard focus on both Win and Mac
So folks
I'm at a loss here
I expose the value api and can manipulate it, and now have tab order and invalidation working. Great.
But this arrow key thing is really spooking me. The default juce slider doesn't respond to a keypress. i worry about intercepting arrow in a plugin hosted in a daw. And I'm not quite sure how to make editing these items accessible without that. Also I don't get a programatic chance to tell if a screen reader is in use. So my choices are
1: Like the juce::Slider don't support keypress etc... 2: Support it and have an option to turn it off for non-accessible users, but that has the disadvantage that the arrow keys are more likely to be bound than tab (where we made the tab-is-tab choice in XT) or 3: Support it but have it be an option to turn it on but then screen reader users would have to navigate to that menu once or 4: Something else clever
So I guess my question is: The best accessible plugin - what does it do? Maybe i should download it and look at it for a bit.
Any suggestions welcome.
by the way activating the arrow keys is super easy. i have a version now in my branch which does it - and honestly its' pretty awesome tabbing around and arrow keying sliders and stuff. (I want hover to follow focus too). I'm just debating whether to have this on by default or not and would love a guide from other plugs.
Comparing against other similar plugs is tricky because, so far as I know, you're already ahead of the pack going first with a synth that has a big, complex GUI. This is obviously an awesome thing from user perspective, but also means your decisions are gonna set something of a precedent. The nearest I can come to an apples to apples comparison is Nexus 4. So far, they've gone with an accessible keyboard mode that needs to be enabled by the user. That works, but based on seeing how it's been a struggle for some of my less tech-savvy students, I'm gonna start gently wheedling at them to either have it enabled by default or present some sort of prompt on first run, because right now the setting is kinda buried. Can you put up that version where you've got the arrow keys working so we can see where you're at with that? Right now, is it having any negative impact for that to be the default behaviour?
Though not a synth, Pianoteq is another plugin that recently got upgraded to the accessible Juce version and got accessibility. They have an entire settings section for keyboard shortcuts with a master "enable keyboard shortcuts" switch. I just tried turning it off to see what happens there, and while I was still able to tab from control to control, no other keys worked (arrow keys to adjust sliders or enter to press buttons). It's been a while since I clean installed that plugin but I think this option was turned on by default.
If that's the case, then these 2 plugins took the opposite paths in what the default option is. Maybe as a compromise, what you could do is if the plugin is loaded without any settings, pop up with a message asking if you want extended keyboard support enabled, briefly explaining that this will take over things like the arrow keys for adjusting sliders and that if you're a screen reader user you want this turned on. That way existing users won't be bothered while anyone trying Surge out for the first time won't have to hunt for the option in a lot of menus.
That's great and great to know. I was also thinking of a 'first time popup' as an option, or maybe a default to on.
What I'm going to do now, though, is write the code and default it off (with a sticky option). Then I'll ask our testing machine to test with it on in both accessible (here) and non-accessible settings. That will help us decide the right core setting.
I gotta say, the keyboard navigation is kinda awesome even in a non-screen reader environment. I was tabbing around the UI and using the arrow keys to adjust things and I rather liked it.....
will take me a bit of time to get it mergable, but this week. Will post here when I do with instructions about how to toggle on for now.
(oh and: pianoteq is definitely a synth! I love that plugin :) )
A third option: how about holding a modifier as the synth loads to enable arrows support? I saw JST do that to toggle OpenGL on/off a while back in one of their newer JUCE-based plug-ins and thought it was a nifty solution. So long as it's clearly documented, that'd be easy for screen reader users to do and non-invasive for everyone else.
That would also work yeah. Although, the idea of having a message at the beginning might make it more discoverable even for people who may not think they might find it useful… I mean just look at Paul's reaction to keyboarding around the UI for the first time! 😂 This feature is a good example of universal design, it was made to improve blind accessibility but will also be helpful not just for blind folks.
Perhaps both features could exist at the same time, so even if somehow you accidentally turn the shortcuts off you'd have an easy way of getting them to work again.
On 15 Dec 2021, at 17:30, ScottChesworth @.***> wrote:
A third option: how about holding a modifier as the synth loads to enable arrows support? I saw JST do that to toggle OpenGL on/off a while back in one of their newer JUCE-based plug-ins and thought it was a nifty solution. So long as it's clearly documented, that'd be easy for screen reader users to do and non-invasive for everyone else.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/surge-synthesizer/surge/issues/4616#issuecomment-994956672, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAABTIE76TWV7F7J5BOEDLURC7BDANCNFSM45YHRRLA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Yeah I would totally want this in my daw. as long as it doesn't interfere with logic keybindings. For my use case I don't think it will but folks are super duper picky about their daw keybindings it turns out.
Ok I just merged a rough draft version of arrow edits. Sliders and buttons and number fields are starting to work.
It is on by default in the standalone and off by default in the plugin. To change that do menu / workflow / allow arrow keys to edit values
I’m going to enlist our testers to test it in the in state in various daws next week and may toggle the default or do some other thing to activate it. I could also add an invisible screen reader only button to toggle it at the top level. Lots to consider
it’s not 100% but when the next nightly hits in an hour or so I would love to know if with this activated it is an improvement.
tested mac only standalone and vst3 in reaper
we got some feedback from users without screen readers last night that i merged to improve things a bit.
for now I'm going to wait for feedback from folks here on whether this is the right direction. If it is I can spend a couple of hours and finish off some of the edges i know about; but obviously i don't want to do that work if it isn't.
We are still planning on shipping Jan 15 or so, so plenty of time to wrap up these features in the next couple of weeks.
Appreciate all the help you've been giving here. This has been very educational for me!
Just took this for a spin on both platforms and it's working great. I was going to suggest adding in some of the features you have when using a mouse, like holding down shift for finer adjustments but I see that's already implemented so that's cool. I would also add pressing home and end to set the slider to the maximum and minimum values respectively which is a standard feature of sliders on Windows, but even on Mac VoiceOver doesn't have an easy way to quickly set a slider to an extreme so it'd be useful there as well.
One bug I noticed is with the controls that appear as a group of radio buttons - IE the oscillator octave. Right now, when you tab into them the group gains focus, not any of the radio buttons themselves. As a result when you press up and down to change the option, the screen reader doesn't say anything even though the option just changed. So what you should do there is when you tab into one of these, focus the selected option instead of the group and focus the newly selected option when you press an arrow.
The other bug I noticed is that I can't adjust the LFO step sequencer sliders this way even though I can tab into them.
Lastly, you'll want to add a way to press buttons that act as toggles or open menus (things like the oscillator type). I noticed that pressing down on the main menu button causes it to open so you could probably do that for the other controls as well. A more natural way to do it would be pressing space or enter but that's more likely to clash with daws so IDK how much people would like that. That's in addition to Shift+F10 to open context menus which is already on the list.
Thanks again for all your work!
On 16 Dec 2021, at 15:23, Paul @.***> wrote:
we got some feedback from users without screen readers last night that i merged to improve things a bit.
for now I'm going to wait for feedback from folks here on whether this is the right direction. If it is I can spend a couple of hours and finish off some of the edges i know about; but obviously i don't want to do that work if it isn't.
We are still planning on shipping Jan 15 or so, so plenty of time to wrap up these features in the next couple of weeks.
Appreciate all the help you've been giving here. This has been very educational for me!
— Reply to this email directly, view it on GitHub https://github.com/surge-synthesizer/surge/issues/4616#issuecomment-995864380, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAABTKD7ZGY4PTGJ3WE2MLURHY7NANCNFSM45YHRRLA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.
Excellent feedback Let me turn to these rough edges next week and see if I can get this wrapped up for our 1.0 version
thank you for all your help. This literally could not have happened without it
Hello folks!
Before start, excuse me for silenting while hot discussion! I've perhaps got Covid and was forced to spend this time in my bed... But I was watching this issue! ☺
I've just downloaded the last surge-xt-win64-NIGHTLY-2021-12-16-b1fa936 build and testing it right now. I should to go the main Surge menu>>Workflow and activate two items there: "Use keyboard shortcuts" and "Arrow keys modify values". As I understood, the left and right arrows are working with sliders. Also, the arrow keys performs mouse wheel behavior and Shift key also makes the steps performing by above descripted keys more small. I've tested this behavior on octave slider and it works fine. But the pitch slider reports not exact steps when I'm adjusting it. For example, I'm adjusting it to the right and it reports: "Scene A Osc 1 Pitch 0.70 semitones", then next "Scene A Osc 1 Pitch 1.40 semitones". I've right clicked on this slider and saw the item "Edit value: 1.40 semitones". Means it that the pitch applies this value? If it's true, seems we will have this situation at the step sequenser sliders... I am still thinking about the same popup-menu and item like as in Pitch slider where we will set the exact value... Also, i've tried to set the exact 1.00 semitones in the pitch slider with shift key and couldn't this: the slider sets the values like as "Scene A Osc 1 Pitch 0.98 semitones" and then "Scene A Osc 1 Pitch 1.05 semitones". I could set the exact value only via menu item "Edit value" on the right click menu on this slider. That's good news we can adjust this slider values via keyboard, but I think that it would be applied when we are modulating or adjusting the parameters which do not require fine tuning (filters, FX parameters and etc), but not for tune oscillator parameters. Please note that is my oppinion only and we might have a speech about. ☺
oh our sliders have quantized moves so i could use those for the arrow keys sure that's a good option
the "Edit 1.4" will give you a type where you can type in any value.
also feel better!
@outsidepro-arts hope you're recovering well!
For mouse users, doesn't holding down one of the modifiers let you move it in quantized steps? I think you could do the same thing for the keyboard as well. I like being able to make these less precise steps for sound design, and you already have holding down shift for fine adjustment, so perhaps holding down alt/option could let you move by quantized steps.
Ctrl is doing quantized steps on sliders in Surge.
Ctrl+up/down could work, but left/right are taken by Ctrl+left/right keyboard shortcut to go to prev/next patch (Shift+Ctrl+left/right go to prev/next category).
this is a checklist @baconpaul is keeping he hopes summarizing his reminders of what to do based on this thread. (Check marks mean things he has done on a branch but not merged.)
https://forum.juce.com/t/juce-accessibility-on-develop/45142/83