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

Accessibility: Give additional announcements for screen readers #50

Open
pitermach opened this issue Mar 19, 2023 · 4 comments
Open

Accessibility: Give additional announcements for screen readers #50

pitermach opened this issue Mar 19, 2023 · 4 comments

Comments

@pitermach
Copy link

pitermach commented Mar 19, 2023

This is following up from the conversation on Discord and the initial work in the TTS branch, The implementation there is already doing almost everything that I think would be helpful with some minor tweaking:

  • Reduce verbosity - When toggling various effects, instead of "setting robot: true" just say "robot on", same for turning the encoder knobs, instead of "setting pitch value to: -1" just say "pitch -1"
  • Announce the FX preset name when switching to it
  • Announce mute state for the fader buttons in addition to the cough mute
  • Speak volume level changes when using the faders (though perhaps this should be a separate toggle because I don't know if I'd personally want it but I can see how other people might)
  • Although, thinking about volume having a warning announcement when you start adjusting a fader which is currently globally muted could be helpful, regardless of if you want normal fader volume changes spoken or not
@FrostyCoolSlug
Copy link
Member

The fact that at 10 minute random spamming of TTS got such a positive result is delightful!

I'm probably going to need to abstract out the TTS service, the tts-rs crate appears to have a few problems on MacOS, running more than one service can cause crashes, as well as not working without an NSRunLoop (which only currently happens in the daemon if the system tray is enabled), so these are likely going to be on the 'To Solve' list. At the end of the day, MacOS support for the daemon is a little on the weak side as I don't own a Mac, but I can at least use my hackintosh to try and get things working, and use a mpsc channel for the TTS messages.

The main difficulty will be reporting what the UI sees, and not what the internal values are. Raising a fader shouldn't say "Volume: 255", it should say "Volume: 100%", this applies to the faders and the effects dials, I do also need to ensure that if a user changes the channel on a fader, there's an announcement about that as well.

This will likely get a focus for 0.11.0, at least for now I know how to make it work, and how to plumb everything together, but I've hit most my targets for 0.10.0 already so tidying up that release will be a priority.

All the suggestions are good, and I'll make sure when TTS comes into play that they're all implemented :)

@FrostyCoolSlug
Copy link
Member

Ok, the first pass at this is now committed in 0.11.0, There's an option in System -> Settings to enable TTS on button press.

As far as announcements, I've hit most the major points above, including:

  • The Effect Buttons announce as 'Effect On/Off'
  • Effect presets, and Sample Banks are announced as 'Effects X' and 'Sample X'
  • Mute states on all faders are announced as 'Channel Muted to Target' / 'Channel Unmuted'
  • I'm not announcing changing the volume currently, but I do announce fx dial changes.. I'm a little on the fence because monitoring and listening to the changes seems like it would be more helpful than having numbers announced when things are changed..
  • I still need to look into this, it's a little complicated, but might be possible.

@FrostyCoolSlug
Copy link
Member

So, as far as the announcement of a fader move when a channel is muted, this is actually a little problematic.

When you hit the 'Mute' button, the mechanical faders of the full sized GoXLR move themselves to the bottom, but they also announce that movement back to the util. The problem was that for every step along the way the util churned out a 'Warning' for that movement, overwriting and replacing the announcement that it WAS muted.

So for now, I'm going to have to not implement that. There's possibly changes coming in the future which will help resolve this issue, but I'll hold for now.

Thanks.

@FrostyCoolSlug
Copy link
Member

So fun update, with the Mix2 firmware, the problem described above is actually solved, The GoXLR will immediately report the 'end' value and will no longer report values along the way.. I'll take another look at that for the last step :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants