current TTS options for Fedora-core 1

[Tim Cross <tcross@xxxxxxxxxxx>]

Yes, very little changes are needed for most servers to get them
integrated. In fact, off the top of my head, I think I only needed to
modify dtk-voices.el and .servers to integrate the Cepstral Theta
server into emacspeak. This was mainly done to enable support for
in-line TTS commands which require "balanced tags" such as XML and
SSML in particular. The way I have implemented this, based on the
basic framework you had already put into place, needs a little more
"generalization" to enable other servers to take advantage of this
facility without requiring modifications to dtk-speak.el.

I was mainly referring to our previous
discussions concerning moving some of the "cleaning" code, currently
done in the TCL scripts, back into elisp to make processing simpler
for servers which benefit from an SSML type tags command interface -
for example, to escape XML type tags prior to adding SSML commands to
avoid them being interpreted by the SSML capable server etc. I believe
this would also make the TCL script simpler to write (although they
are pretty simple already) and help ensure features like split caps
work consistenty between servers. 

There is also some minor cleanup work needed for some legacy dtk
in-line commands which sneak through from the elisp code now and
again. This however is minor and should be easily fixed.

Some other issues which may or may not require consideration and
action are things like support for multi-byte characters. As I
understand it, one of the restrictions within emacspeak in relation to
multi-byte characters is somewhat legacy based due to the hardware
dectalk only supporting single byte characters. Newer TTS engines,
don't necessary have this limitation. Therefore, should constraints
such as character sets and associated mappings be handled within
emacspeak or within the software specific to the TTS engine? Is this
even an issue requiring consideration? I'm just mentioning it as a
possible consideration and it may or may not be relevant.

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"