current TTS options for Fedora-core 1

["T. V. Raman" <tvraman@xxxxxxxxxxx>]

Actually there is very little that needs to be done to make option 1
complete, and as you say the other speech server frameworks out there
are not sophisticated enough since they've mostly done a least common
denominator approach.

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

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

The name "dtk" is legacy and should be thought of as a synonym for tts
--- I made sure of this the last time I refactored the code and named
things that were dectalk 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"

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