I have noticed a small inconvenience, and hoped that someone here has an
idea of a workaround. For AISquared, is there any reason why this
happens, and could there be a fix implemented into the API?
Several developers on this list, have been using either the Keyboard or
Mouse voice, for speaking out messages in their apps. One benefit of
that approach, is the chance to alter the voice parameters, without
affecting the general speech output of the screen reader.
I have set my screen reader to interrupt on all keystrokes. Typically, I
would hit things like Ctrl or Shift-keys, to interrupt any ongoing
speech from the system. But when I let my app send a number of strings
to one of the alternative voices - that is, Keyboard or Mouse - I can
hit ctrl a thousand times, without any interrupting taking place.
Will I need, to have any further lines of coding implemented, for the
interruption to be effectuated also under the alternative speech output?
Or, at least, is there any piece of code, that would ensure this kind of
interruption, that I could insert more like an extra measure of "security"?
First on the topic, AISquared, one wish for upcoming versions of the
screen reader and its API, would be for us to have a chance of assigning
different synths for speech output. We then would not have to stick to
one and same synth, for all three voice alternatives. You even could let
us have a specially designated channel, named things like
MessageSynth,
which could be set to any synth installed on the current system. By
setting that channel, and then sending a string to it, the synth would
be activated, speak the string, and then deactivated. Of course, I don't
know if it needs to be fully activated and deactivated on each call,
maybe you can somehow put it into some kind of sleep mode, which may
shorten the invoking time for each call. Would greatly have expanded the
capabilities of our apps.
Thanks for any feedback.
--
David