Speech synthesis / screen reader?

The discussion in the MONITOR WANTED thread about all the arcane incantations that must be blind-typed to get a working display made me realise something – in 99% of cases the only way the computer provides feedback to the user is via the display. But almost every machine will have audio output available, and in general it’s a lot harder to misconfigure your audio than it is to misconfigure your video. If the ROM contained a built-in speech synthesiser that was capable of acting as a screen reader when at the CLI, then that would remove a lot of the guesswork when it comes to trying to reconfigure a machine which has a non-functional display. No doubt, visually impaired people would favour the addition of speech-oriented features as well.

Extra points if it sounds like Kenneth Kendall.

Would be nice as long as it’s not on by default. Maybe a keyboard shortcut could turn it on?

and in general it’s a lot harder to misconfigure your audio than it is to misconfigure your video

Ah… but on modern machines it’s apparently pretty simple – either hardware a suitable display type and mode (as I have with my Pi), or let the machine read the EDID, or just use a default (like SVGA) to start with¹?

The majority of the blind typing? That happens with older machines, due to the eccentric “monitor detection” methods, and the inability to use EDID as IIC was never wired to the VGA socket.

As for the voice reader, it would be interesting having such a thing on a system that is extremely mouse-centric, however the blatantly easy place to patch in support for such a thing would be !Help. The only additional change necessary would be for !Help to prefix its messages with the name of the application, so “This is the Title bar…” would give an indication of which title bar.

To see how well such a thing might work as a proof of concept, maybe provide some hooks to: http://espeak.sourceforge.net/ ?
But, for a built in module, maybe not – it’s GPL…

¹ One of the reasons I think the Pi starting in FullHD is dumb…it only works with monitors capable of such a thing, anybody using analogue “TV” video output or an HDMI→VGA adaptor with an older monitor will be stuck.
I imagine this may be what newer versions of NOOBS is doing, as not a single one of them in the last three or so years creates any sort of viewable output on any of my Pi devices. But, then, since my monitor can’t do 1920×1080, that’s only logical…

To see how well such a thing might work as a proof of concept, maybe provide some hooks to: http://espeak.sourceforge.net/ ?
But, for a built in module, maybe not – it’s GPL…

Which, if I recall means that it can’t distributed with the OS content but it could be downloaded by a link or default start script such that both espeak and the source(or pointer to the source) end up on the users drive.
Just because GPL people can be total ‘holes doesn’t mean RO users should suffer if the means to do something that still complies is possible.

Maybe what we need first is a module called “GPLwiggle” that can take commands (or a simple script) to download and install some things that could not be directly built into the OS? Sort of like PackMan, only scriptable?

Extra points if it sounds like Kenneth Kendall

Negated if it starts calling me Dave.

Maybe what we need first is a module called “GPLwiggle” that can take commands (or a simple script) to download and install some things that could not be directly built into the OS? Sort of like PackMan, only scriptable?

Yup. “Sort of like Packman” or webget is what I was thinking. Probably even a suitable(non-GPL) set of code for a version of webget around somewhere.

If I understand things correctly then there’s no problem with including GPL apps in the disc image; it’s just the ROM that’s problematic. If you softload a module through Boot (or GPLwiggle!) then I don’t believe it runs afoul of the static-linking restriction.

If I understand things correctly then there’s no problem with including GPL apps in the disc image;

I believe it needs to be distributed separately, hence the GPLwiggle¹ use to ensure the GPL components end up where required.

¹ Part of my mind sees an animated image of a single digit being wiggled

As a real-world example, NetSurf is GPL and is distributed in the Pi SD image, seemingly without any problems.

You could always approach Superior about !Speech, never used it myself so don’t know what it sounds like, probably pretty awful by today’s standards!

Being able to type blind a few different VESA standard modes with a simple command could be useful. Say VESA640 & VESA1920. Not using the loaded MDF!

Being able to type blind a few different VESA standard modes with a simple command could be useful.

Even simpler is to make sure that you have a file in your library called something memorable that will restore a basic valid screen mode.

My file is called “Restore”, and says, simply,

WimpMode 32|m

Even simpler is to make sure that you have a file in your library called something memorable that will restore a basic valid screen mode.

Typing a wimpmode 27 command is something I’ve done frequently over the years. But if the currently loaded mode definition file isn’t suitable it gets difficult and what happens when !Boot doesn’t complete.

I have resorted to obey files in Library which loaded an MDF and set wimpmode x y c ex ey LGBT…

Having VESA modes in ROM and overiding any loaded MDF would be very useful.

Having VESA modes in ROM and overiding any loaded MDF would be very useful.

This.

And no problem with overriding (implies you can’t change the VESA modes) because a VESA mode with the correct timings is a VESA mode with the correct timings, and anything else…isn’t.

ScreenModes has a few big tables of VESA modes so that it can include them in mode lists that are generated from EDID. Which means that a *VESA640 command (or maybe “*VESA <name>” to allow arbitrary modes to be selected) should be pretty straightforward to implement, only needing to do two tasks:

1. Load a static EDID file from ResourceFS which indicates it supports the necessary VESA modes
2. Change to the requested mode (auto-selecting a colour depth which the system supports). Probably using *Wimpmode so that the Wimp won’t try and switch to a different (potentially unsupported) mode if you then enter the desktop.

But the point about the screen reader is that if something goes wrong with the above (typo in your command, ScreenModes is unplugged, video driver is unplugged, current GraphicsV driver is configured incorrectly, keyboard layout isn’t correct, monitor cable is unplugged, something crashes during the mode change, etc.) you’ll get some feedback instead of just being left to guess at the problem when the command doesn’t work.

The idea of a screen-reader is a good one. Another use-case (deaf user?) might be to press a key or combination of keys which enables you to type in a mode number directly, or how’s about a key that starts a process of going through the most common modes or successfully used screen modes. A final thought, allocate a key (or set of keys) to start mode detection again.

set wimpmode x y c ex ey LGBT…

Sounds a bit PC, is that one of those non-discriminatory modes? :)

one of those non-discriminatory modes?

Well, we all know VGA is easy and gets around pretty much everywhere with everything and really isn’t choosey.
QHD, on the other hand, one of those posh entitled gits…

or how’s about a key that starts a process of going through the most common modes or successfully used screen modes.

Only if this is implemented at boot time and nowhere else.

Actually, that’s not such a bad idea – we have various magic keypresses that do stuff when the machine powers up. Why not one that can switch to a mode tester? Like start off in 640×480, 60Hz and just cycle to a different mode if SPACE is pressed, go to the previous mode if DELETE is pressed, force RISC OS to the current mode if ENTER is pressed, and give up and begin booting if ESC is pressed…?
This can be augmented with beep codes (though check on behaviour of audio over HDMI if the video signal is out of range, are they interdependent in any way?) and most importantly some sort of test pattern with the resolution information (x, y, fps) visible on screen.

Maybe, just maybe, I might be able to get some sort of stable video output from my Brake – ‘cos my HDMI to VGA adaptor (which works flawlessly on the Pi) really really doesn’t like the Beagle’s output.

one of those non-discriminatory modes?

Well, we all know VGA is easy and gets around pretty much everywhere with everything and really isn’t choosey.

Are you saying VGA “swings both ways”? (non-PC¹)

¹ Politically correct.

Are you saying VGA “swings both ways”?

I think the polite phrase is “curious”, as in “hmm, I wonder what this does?”.