The three keyboard commands every person who uses speech for accessibility wants are:
- Read this now (stop whatever else you're doing.)
- Read this when you're done (don't stop … I'm just adding this to your hopper.)
- OMG shut up, Shut Up, SHUT UP!! (🤣)
I'm legally blind, so I'm no stranger to TTS, and I've used a lot of screen readers including Orca before. Still, if I can use large print and dark themes, that's usually faster because my ability to interpret 400wpm gibberish is not what it was in 1986, and the specifics speech tends to leave out are significant when we're talking source code. Ain't nobody giving me $13,000 for a Braille display…
I've purchased Nuance TTS engine licenses via Oralux and have been using speech-dispatcher with them. Here's the script that runs for alt-super-x:
#! /bin/sh
xclip -out -selection primary | sed -e 's/^!-!/ !-!/g' -e '$a\' | spd-say -e -w
The sed removes the potential for embedded speech commands in the clipboard contents.
How this breaks is if I feed it paragraphs 1, 2, 3, and 4, then select a new block of text while it's reading and call this again with paragraphs 5 and 6, what will happen is that paragraphs 1, 5, 2, 6, 3, and 4 will be read in that order. Whyyyyyy?? I could probably fix this by writing my own spd-say replacement that does what I actually want … but you've already done some of that, using piper, so it's not limited to x86_64 and doesn't cost $35 per voice. (Also annoyingly spd-say -S only stops speech-dispatcher reading the current paragraph.)
I set up shortcuts to my scripts directly so there's no xterm -e needed.
If you decide to to implement this suggestion, I have thoughts on how you might do it. You could have mintPiper expose itself via DBus while it's running. If so, the freshly called instance can issue the silence command and/or add text to the queue and exit. If nobody's home, become the DBus listener, fork, daemonize, etc. Exit when there has been nothing to speak and no command for … however long. I'd considered trying to do this with PIDfiles, signals, and a fifo … but why? DBus exists and works.
Hope it's an interesting idea!
The three keyboard commands every person who uses speech for accessibility wants are:
I'm legally blind, so I'm no stranger to TTS, and I've used a lot of screen readers including Orca before. Still, if I can use large print and dark themes, that's usually faster because my ability to interpret 400wpm gibberish is not what it was in 1986, and the specifics speech tends to leave out are significant when we're talking source code. Ain't nobody giving me $13,000 for a Braille display…
I've purchased Nuance TTS engine licenses via Oralux and have been using speech-dispatcher with them. Here's the script that runs for alt-super-x:
The sed removes the potential for embedded speech commands in the clipboard contents.
How this breaks is if I feed it paragraphs 1, 2, 3, and 4, then select a new block of text while it's reading and call this again with paragraphs 5 and 6, what will happen is that paragraphs 1, 5, 2, 6, 3, and 4 will be read in that order. Whyyyyyy?? I could probably fix this by writing my own spd-say replacement that does what I actually want … but you've already done some of that, using piper, so it's not limited to x86_64 and doesn't cost $35 per voice. (Also annoyingly spd-say -S only stops speech-dispatcher reading the current paragraph.)
I set up shortcuts to my scripts directly so there's no xterm -e needed.
If you decide to to implement this suggestion, I have thoughts on how you might do it. You could have mintPiper expose itself via DBus while it's running. If so, the freshly called instance can issue the silence command and/or add text to the queue and exit. If nobody's home, become the DBus listener, fork, daemonize, etc. Exit when there has been nothing to speak and no command for … however long. I'd considered trying to do this with PIDfiles, signals, and a fifo … but why? DBus exists and works.
Hope it's an interesting idea!