current TTS options for Fedora-core 1

[Tim Cross <tcross@xxxxxxxxxxx>]

One other thing I forgot to mention is that I'm not sure if we should
totally ignore other TTS interfaces. While it would be necessary to
investigate what would be involved, something like the speech-dispatcher
approach is probably worth investigating further. I know that it has
become a lot more sophisticated, with support for auditory icons,
multiple voices and multiple languages plus SSML. While it is possible
that the approaches are so different that no true integration can be
achieved, it should still be evaluated fully. The benefit of such
approaches is that by creating just a single interface, we immediately
gain support for a number of different TTS engines, including
festival, flite, apollo, software dtk, epos, llia_phon etc - all of
which can be maintained with a single interface.


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 they've
 tvr> mostly done a least common denominator approach.

 tvr> As things stand in the design the intent is that you shouldn't
 tvr> have to modify elisp or tcl files; in practice, thsi can be
 tvr> proven only by writing more servers, discovering where mods are
 tvr> needed, and refactoring code appropriately; discussion in the
 tvr> abstract usually leads to mud slinging and stone throwing,
 tvr> nothing else.

 tvr> If you examine how the dectalk and viavoice support works today,
 tvr> the dectalk specific code is now in dectalk-voices.el; the
 tvr> viavoice code in outloud-voices.el, and the TCL layer mirrors
 tvr> this, with the common TCL code in tts-lib.tcl.

 tvr> The name "dtk" is legacy and should be thought of as a synonym
 tvr> for tts --- I made sure of this the last time I refactored the
 tvr> code and named things that were dectalk specific with a dectalk-
 tvr> 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 servers
 Tim> for emacspeak. The current job I'm in means I will not have a
 Tim> lot of time for this project until after August, but am
 Tim> certainly willing to try and contribute when possible.

 Tim> If the emacspeak community decides this would bea good model to
 Tim> follow for providing speech server support, I think we need to
 Tim> start by looking at how we may be able to slightly modify the
 Tim> architecture of emacspeak so that additional servers do not
 Tim> require modification to the core emacspeak code-base. Currently,
 Tim> if you want to create a new server which is integrated into
 Tim> emacspeak in the same way as existing servers, you need to
 Tim> modify some of the emacspeak source code. I feel that if we are
 Tim> going to introduce another group, as far as possible, we need to
 Tim> have an architecture where Raman (or whoever) can extend
 Tim> emacspeak functionality without reference to the work done by
 Tim> another group which is 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 very
 Tim> well defined speech server interface layer. This would be the
 Tim> easiest option in my view as Raman has already got much of the
 Tim> work done - its really just a bit of cleanup work and moving
 Tim> some processing which currently happens at either the TCL server
 Tim> script level into the elisp layer or vice 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 an
 Tim> example of this sort of approach. I also believe a group has
 Tim> been formed to create a uniform speech interface which KDE, GNOE
 Tim> et. al. would use and perhaps we should examine how feasible
 Tim> this might be. The main drawback I can see is that some of these
 Tim> projects don't seem to support the advanced features of
 Tim> emacspeak (e.g. don't handle multiple voices well, auditory
 Tim> icons etc), plus this would require possibly substantial changes
 Tim> 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 servers
 Tim> but also for the emacspeak code base itself. Raman has held it
 Tim> together for a long time now, but he has other interests and
 Tim> responsabilities and its probably time us as users started
 Tim> taking on some of the tesponsability for its maintenance and
 Tim> 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 and
 tvr> maintaining speech servers. The reason I have not bothered
 tvr> updating the Software Dectalk support is that no more than
 tvr> ahandful of users out there bothered with even 4.61, and it's
 tvr> just not worth the effort required to maintain multiple speech
 tvr> servers for such a small user base. Under those the only thing
 tvr> that works is if the person who wants it the most puts in the
 tvr> effort. In this case, it's not me, since I already have my needs
 tvr> fully met.

 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 IRC:
 tvr> irc://irc.gnu.org/emacspeak

 tvr> -----------------------------------------------------------------------------
 tvr> To unsubscribe from the emacspeak list or change your address on
 tvr> 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 on
 tvr> the emacspeak list send mail to
 tvr> "emacspeak-request@xxxxxxxxxxx" with a subject of
 tvr> "unsubscribe" or "help"

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