speech dispatcher

["Bart Bunting" <bart@xxxxxxxxxxx>]

Hi,

Spent a little time this morning hacking up the beginnings of an interface
to speech-dispatcher.

Seems to work pretty well with very little work.

I just started from the dtk-soft server and hacked it around a bit.

Festival sounds quite nice but is still not that responsive.  The theta
interface is much more snappy.


Bart

> -----Original Message-----
> From: T. V. Raman [mailto:tvraman@xxxxxxxxxxx]
> Sent: Saturday, January 08, 2005 11:43 AM
> To: Tim Cross
> Cc: tvraman@xxxxxxxxxxx; peter.rayner@xxxxxxxxxxx; emacspeak@xxxxxxxxxxx
> Subject: current TTS options for Fedora-core 1
>
>
>
> well, investigate it, and tell me what you discover.
>
> >>>>> "Tim" == Tim Cross <tcross@xxxxxxxxxxx> writes:
>
>     Tim> One other thing I forgot to mention is that I'm not sure if
>     Tim> we should totally ignore other TTS interfaces. While it would
>     Tim> be necessary to investigate what would be involved, something
>     Tim> like the speech-dispatcher approach is probably worth
>     Tim> investigating further. I know that it has become a lot more
>     Tim> sophisticated, with support for auditory icons, multiple
>     Tim> voices and multiple languages plus SSML. While it is possible
>     Tim> that the approaches are so different that no true integration
>     Tim> can be achieved, it should still be evaluated fully. The
>     Tim> benefit of such approaches is that by creating just a single
>     Tim> interface, we immediately gain support for a number of
>     Tim> different TTS engines, including festival, flite, apollo,
>     Tim> software dtk, epos, llia_phon etc - all of which can be
>     Tim> maintained with a single interface.
>
>
>     Tim> Tim-
> >>>>> "tvr" == T V Raman <tvraman@xxxxxxxxxxx> writes:
>
>     tvr> Actually there is very little that needs to be done to make
>     tvr> option 1 complete, and as you say the other speech server
>     tvr> frameworks out there are not sophisticated enough since
>     tvr> they've mostly done a least common denominator approach.
>
>     tvr> As things stand in the design the intent is that you
>     tvr> shouldn't have to modify elisp or tcl files; in practice,
>     tvr> thsi can be proven only by writing more servers, discovering
>     tvr> where mods are needed, and refactoring code appropriately;
>     tvr> discussion in the abstract usually leads to mud slinging and
>     tvr> stone throwing, nothing else.
>
>     tvr> If you examine how the dectalk and viavoice support works
>     tvr> today, the dectalk specific code is now in dectalk-voices.el;
>     tvr> the viavoice code in outloud-voices.el, and the TCL layer
>     tvr> mirrors this, with the common TCL code in tts-lib.tcl.
>
>     tvr> The name "dtk" is legacy and should be thought of as a
>     tvr> synonym for tts --- I made sure of this the last time I
>     tvr> refactored the code and named things that were dectalk
>     tvr> specific with a dectalk- prefix.
>
> >>>>> "Tim" == Tim Cross <tcross@xxxxxxxxxxx> writes:
>
>     Tim> I think Raman's idea is a good one and I would certainly be
>     Tim> willing to participate in a team which worked on speech
>     Tim> servers for emacspeak. The current job I'm in means I will
>     Tim> not have a lot of time for this project until after August,
>     Tim> but am certainly willing to try and contribute when possible.
>
>     Tim> If the emacspeak community decides this would bea good model
>     Tim> to follow for providing speech server support, I think we
>     Tim> need to start by looking at how we may be able to slightly
>     Tim> modify the architecture of emacspeak so that additional
>     Tim> servers do not require modification to the core emacspeak
>     Tim> code-base. Currently, if you want to create a new server
>     Tim> which is integrated into emacspeak in the same way as
>     Tim> existing servers, you need to modify some of the emacspeak
>     Tim> source code. I feel that if we are going to introduce another
>     Tim> group, as far as possible, we need to have an architecture
>     Tim> where Raman (or whoever) can extend emacspeak functionality
>     Tim> without reference to the work done by another group which is
>     Tim> adding speech servers.
>
>     Tim> I feel we have a couple of options along these lines -
>
>     Tim> 1. We could modify the existing code base so that we have a
>     Tim> very well defined speech server interface layer. This would
>     Tim> be the easiest option in my view as Raman has already got
>     Tim> much of the work done - its really just a bit of cleanup work
>     Tim> and moving some processing which currently happens at either
>     Tim> the TCL server script level into the elisp layer or vice
>     Tim> versa.
>
>     Tim> 2. Possibly examine modifications to emacspeak so that it can
>     Tim> work with other frameworks which have been developed for
>     Tim> interfaces to generic speech servers. The speechd project is
>     Tim> an example of this sort of approach. I also believe a group
>     Tim> has been formed to create a uniform speech interface which
>     Tim> KDE, GNOE et. al. would use and perhaps we should examine how
>     Tim> feasible this might be. The main drawback I can see is that
>     Tim> some of these projects don't seem to support the advanced
>     Tim> features of emacspeak (e.g. don't handle multiple voices
>     Tim> well, auditory icons etc), plus this would require possibly
>     Tim> substantial changes to the emacspeak architecture.
>
>     Tim> Other points of view, comments, concerns etc welcomed and
>     Tim> encouraged. We need to contribute if we want emacspeak to
>     Tim> evolve. I actually feel we are getting close to a time where
>     Tim> emacspeak requires more maintainers, not just for speech
>     Tim> servers but also for the emacspeak code base itself. Raman
>     Tim> has held it together for a long time now, but he has other
>     Tim> interests and responsabilities and its probably time us as
>     Tim> users started taking on some of the tesponsability for its
>     Tim> maintenance and development.
>
>     Tim> Tim
>
> >>>>> "tvr" == T V Raman <tvraman@xxxxxxxxxxx> writes:
>
>     tvr> An FAQ would be a good start. The next step would be to put
>     tvr> together a small team that took responsibility for creating
>     tvr> and maintaining speech servers. The reason I have not
>     tvr> bothered updating the Software Dectalk support is that no
>     tvr> more than ahandful of users out there bothered with even
>     tvr> 4.61, and it's just not worth the effort required to maintain
>     tvr> multiple speech servers for such a small user base. Under
>     tvr> those the only thing that works is if the person who wants it
>     tvr> the most puts in the effort. In this case, it's not me, since
>     tvr> I already have my needs fully met.
>
>     tvr> -- Best Regards, --raman
>
>
>     tvr> Email: raman@xxxxxxxxxxx WWW:
>     tvr> http://emacspeak.sf.net/raman/ AIM: TVRaman PGP:
>     tvr> http://emacspeak.sf.net/raman/raman-almaden.asc IRC:
>     tvr> irc://irc.gnu.org/emacspeak
>
>     tvr>
> ------------------------------------------------------------------
> -----------
>     tvr> To unsubscribe from the emacspeak list or change your address
>     tvr> on the emacspeak list send mail to
>     tvr> "emacspeak-request@xxxxxxxxxxx" with a subject of
>     tvr> "unsubscribe" or "help"
>
>     tvr> -- Best Regards, --raman
>
>
>     tvr> Email: raman@xxxxxxxxxxx WWW: http://emacspeak.sf.net/raman/
>     tvr> AIM: TVRaman PGP:
>     tvr> http://emacspeak.sf.net/raman/raman-almaden.asc
>
>     tvr>
> ------------------------------------------------------------------
> -----------
>     tvr> To unsubscribe from the emacspeak list or change your address
>     tvr> on the emacspeak list send mail to
>     tvr> "emacspeak-request@xxxxxxxxxxx" with a subject of
>     tvr> "unsubscribe" or "help"
>
> --
> Best Regards,
> --raman
>
>
> Email:  raman@xxxxxxxxxxx
> WWW:    http://emacspeak.sf.net/raman/
> AIM:    TVRaman
> PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
>


-----------------------------------------------------------------------------
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"