Re: Using emacspeak with speech-dispatcher

[Milan Zamazal <pdm@xxxxxxxxxxx>]

>>>>> "TC" == Tim Cross <tcross@xxxxxxxxxxx> writes:

    TC> While thats quite true, my experience has been its easier to add
    TC> support for a speech server in emacspeak than adding a new
    TC> server to speech dispatcher. 

It's probably true that adding a specialized Emacspeak server is as easy
or easier than adding an output driver to Speech Dispatcher.  But the
benefit of the specialized solution is limited to Emacspeak users, while
the general solution can serve much wider user base.  If you think about
using Speech Dispatcher in Emacspeak only for the purpose of adding new
drivers then it makes little sense to add new drivers elsewhere.

Multiple implementations of TTS drivers (Speakup, Emacspeak, Speech
Dispatcher, GNOME, KDE) are a serious problem, forcing us to spend our
limited resources on duplicate efforts.  Avoiding this was one of the
reasons Speech Dispatcher was created.  KTTSD and Speech Dispatcher have
already decided to merge and there are Speech Dispatcher backends for
Speakup and gnome-speech, so adding new output driver to Speech
Dispatcher has quite wide impact.  Note we can't add many new drivers
ourselves because we use only free software synthesizers, but Hynek
Hanke (the Speech Dispatcher maintainer) actively cooperates with
anybody who wants to add new output driver to Speech Dispatcher.

There's also the TTS API proposal, but currently in an inactive state.

    TC> The more I think about it, given your objectives, I feel the
    TC> better approach would be to enhance speechd.el to increase its
    TC> power by using emacspeak as a guide on how to add features etc.

Here I must mention another important architectural difference between
Emacspeak and speechd-el, not related to Speech Dispatcher use:
Emacspeak is based on wrapping user commands with custom speaking code
while speechd-el provides generic alternative (e.g. speech) output
infrastructure.  While the Emacspeak approach allows very specific
customizations of the interface, the speechd-el approach is generally
more flexible and efficient:

- When new Emacs program is written, it works in speechd-el immediately,
  while in Emacspeak the wrappers must be first written.

- When an Emacs program is updated, in speechd-el it still works as
  before, in Emacspeak some functionality may break and has to be
  updated.

- Some users may and other users may not like the very specific
  Emacspeak customizations.  In the latter case it may be difficult to
  get rid of them.  speechd-el doesn't impose anything on users and lets
  them to choose themselves.

- Emacspeak changes Emacs behavior while speechd-el doesn't.

In the final result speechd-el is more powerful than Emacspeak, but on
the other hand you may miss some specific customizations.  Because of
the architectural differences, it is important to make speechd-el
customizations in the speechd-el way, not in the Emacspeak way.  You can
use the following guidelines:

- There are customization variables in speechd-el determining what
  should be read and how.  They should be used whenever possible.

- Sometimes speechd-el can't speak something, because the corresponding
  Elisp program is written in an unclean way.  While it is tempting to
  write a wrapper in such a case (because it's easier), never do this.
  Fix the unclean Elisp program instead.

- You may need to make personal customizations that you'd put normally
  to your ~/.emacs.  In such a case, do so.

- If you need to emulate Emacspeak behavior such as Emacspeak command
  key mapping, then writing a library for that purpose is appropriate.

- If you need something that is not covered by the previous points, then
  I'd say it's a speechd-el bug or missing feature.  Report it to
  speechd@xxxxxxxxxxx

    TC> The main and obvious disadvantage is that we would be splitting
    TC> the user community, which is a real concern. 

Yes, Emacspeak and speechd-el are completely different systems, perhaps
targeted at different users.  But this doesn't mean we can't benefit
from it.  For instance, speechd-el wouldn't be as good as it is if
Emacspeak wasn't available at the time speechd-el was written -- we
utilized experience from Emacspeak use and could get ideas about both
how things should be done and how they shouldn't be done.  Or the other
way round, speechd-el is a demonstration of the Speech Dispatcher
concept which one can use to judge to what extent the concept can be
useful in Emacspeak.  And there are things which can be shared directly,
such as Speech Dispatcher output drivers.

Regards,

Milan Zamazal

-----------------------------------------------------------------------------
To unsubscribe from the emacspeak list or change your address on the
emacspeak list send mail to "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help"