[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Search]

current TTS options for Fedora-core 1

I think Raman's idea is a good one and I would certainly be willing to
participate in a team which worked on speech servers for
emacspeak. The current job I'm in means I will not have a lot of time
for this project until after August, but am certainly willing to try
and contribute when possible. 

If the emacspeak community decides this would bea good model to follow
for providing speech server support, I think we need to start by
looking at how we may be able to slightly modify the architecture of
emacspeak so that additional servers do not require modification to
the core emacspeak code-base. Currently, if you want to create a new
server which is integrated into emacspeak in the same way as existing
servers, you need to modify some of the emacspeak source code. I feel
that if we are going to introduce another group, as far as possible,
we need to have an architecture where Raman (or whoever) can extend
emacspeak functionality without reference to the work done by another
group which is adding speech servers. 

I feel we have a couple of options along these lines -

1. We could modify the existing code base so that we have a very well
defined speech server interface layer. This would be the easiest
option in my view as Raman has already got much of the work done - its
really just a bit of cleanup work and moving some processing which
currently happens at either the TCL server script level into the elisp
layer or vice versa. 

2. Possibly examine modifications to emacspeak so that it can work
with other frameworks which have been developed for interfaces to
generic speech servers. The speechd project is an example of this sort
of approach. I also believe a group has been formed to create a
uniform speech interface which KDE, GNOE et. al. would use and perhaps
we should examine how feasible this might be. The main drawback I can
see is that some of these projects don't seem to support the advanced
features of emacspeak (e.g. don't handle multiple voices well,
auditory icons etc), plus this would require possibly substantial
changes to the emacspeak architecture. 

Other points of view, comments, concerns etc welcomed and
encouraged. We need to contribute if we want emacspeak to evolve. I
actually feel we are getting close to a time where emacspeak requires
more maintainers, not just for speech servers but also for the
emacspeak code base itself. Raman has held it together for a long time
now, but he has other interests and responsabilities and its probably
time us as users started taking on some of the tesponsability for its
maintenance and development. 


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

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"