Re: [orca-list] Built in Controls for Espeak Pretty Please with Sugar, cheeries, whatever it takes on top :)

[Thomas Ward <thomasward1978 gmail com>]

Hi,

As you rightly have observed its a case of developer convenience
verses end user experience. Speaking as a software developer myself
anything that eases the job of coding, simplifying the job of
development, and offers some out of the box functionality is going to
be the ultimate choice out of convenience. Speech Dispatcher in this
case is such a tool in a developers toolbox. It simplifies access to
many different software text to speech systems, offers a universal way
to get onscreen information spoken, and therefore that is why Speech
Dispatcher is and has been the primary method Orca uses for text to
speech.

On the flip side I am also an end user too, and recognize Speech
Dispatcher isn't necessarily the best way of going about supporting
any specific text to speech system. With Espeak Speech Dispatcher is a
little slow and sluggish, doesn't support variants, and there are
occasionally quarks like the backspace bug which has been mentioned.
It is important to point out that other text to speech systems such as
the Cepstral voices which also experience similar drawbacks because
the Speech Dispatcher support is very basic at best. I can remember
using my Cepstral voices with Gnome Speech and getting much better
stability and performance than with Speech Dispatcher.

Bottom line, I think we as end users have a choice where to go with
this. One, we can build that support, a Python module, directly into
Orca which means any other text to speech application can not and will
not benefit from our work, or two, we can write a new speech service
that replaces Speech Dispatcher. In other words if we don't like the
current mousetrap build a new one. I myself would be in favor of
writing a new speech service which replaces or upgrades Speech
Dispatcher with something that offers more direct and better support
for Espeak, Festival, Cepstral, Dectalk, etc while being separate from
Orca. That way other apps and screen readers can share the new speech
service. It could essentially be a new version of Gnome Speech, but be
more universally shared among desktop and console applications. Any
thoughts?


On 8/28/14, Alex Midence <alex midence gmail com> wrote:
> Classic case of dev convenience versus user convenience.  Devs  seem
> to prefer spd because of its abstraction and so forth.  Users prefer
> anything that makes the software do its job better regardless of
> development philosophy.  I'm strongly in the "make e-speak and Orca
> talk directly to each other" camp.  Too many moving parts is not good
> sometimes.  Take the bug in Debian with speech-dispatcher 8.
> Basically, unless you have pulse, it can't open sockets and pretty
> much doesn't talk at all.  Thank god for Espeakup on that box or I'd
> be only able to use it remotely via putty.  If Orca coud talk to
> Espeak directly, this would be a non issue for me.  IMHO too much
> depends on speech dispatcher.  if it goes belly up, there is
> absolutely nothing else you can use to make Orca talk anymore.  Used
> to be, there was libgnome-speech but Orca support for it was
> discontinued.  Now, it's speech-dispatcher or the sound of silence.  I
> can't tell you how frustrating it is to know your machine has a
> perfectly functioning speech synth that works like a charm with one
> package but not with another.  Speakup and Emacspeak talk just fine.
> Orca, does not.  Dedicating work hours to speech-dispatcher is very
> cold comfort if you don't code.
>
> Alex M