speech dispatcher

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

This is good ---  hope you are able to get it to be usable soon.
>>>>> "Bart" == Bart Bunting <bart@xxxxxxxxxxx> writes:

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

    Bart> Seems to work pretty well with very little work.

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

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


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

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