Greetings, Well, it seems like there may be some interest after all. :) Not that I was trying to pull you away from your release schedule.
Having complete a release of the talking bible project I have learn't quite a bit about what will work and what won't. I rather took the easy approach to try and get something up and running quickly (rather than concentrate on brilliant design which would have pushed my release schedule back even further). In fact the Truth2000 project is several years of work and dates back before its release on sourceforge when it was a personal Perl project using TK and POE. Prior to uploading it to sourceforge I rewrote it in C\C++ using GTK. So I have learn't alot in that time. Some things you should know. 1) Festival TTS is blocking and can cause a sluggish user interface. At the moment I am thinking threads. Using sockets to a separate running server process (not thread) eliminated much of this sluggishness but I could see that it was still present in some cases. Linking directly into these festival libraries (without using threads) would make this problem much worse. 2) Festival TTS uses letter-to-sound rules to pronounce words that it doesn't recognize. Gets them right alot of the time but mispronunciation shows up quite frequently with biblical words. eg. Elijah - pronounced as e-lid-jar. Integration : (To answer question below) ---------------------------------------------- I integrated festival into truth2000 very loosely. Festival runs as a separate server process (unrelated to truth2000). Truth2000 talks to festival through a TCP Socket. This is the easiest approach. Festival could be linked to C\C++ programs directly as a library. I have written a few very small programs as "proof of concept" to satisfy myself that it would work for me. But going this way will definitely require threads, in my opinion, as the calls are blocking. Threads was a layer of complexity that I decided to avoid in the initial stages. For the Future ---------------- I would like to see festival integrated as libraries rather than as socket calls. However I am sure this would be a ***big*** project. If you want to go this way I could take on the role of advisor. I will probably try and concentrate my efforts on getting Festival to pronounce biblical words correctly. This can be done relatively simply by adding entries to Festival's lexicon using a well defined set of phonemes. I will probably work on creating a tool in Perl or Python \ TK to aid in this work to automatically create the Festival script for the lexicons. It can be done on the festival command line but is very awkward. I believe this would benefit both our projects irrespective of what directions we decide to go in the future. - Glenn. On Sunday 08 September 2002 06:54 am, you wrote: > On Sat, 7 Sep 2002 [EMAIL PROTECTED] wrote: > > > I believe your text-to-speech mechanism would be a very cool addition > > > to Sword. How difficult would it be to integrate it? > > > > A false belief (if you are about Sword library, not BibleCS). Individual > > Sword's front-ends can just call some speech engine (such as Festival) > > themselves directly, not through Sword. > > Actually, we would tend to do just this (integrating with Sword, not > frontends) whenever possible. If we wanted TTS, we should try to build it > into Sword at the library level to provide the functionality to ALL > frontends. This helps keep the frontends on an equal level as much as > possible, which allows us to provide similar feature sets to users on > different platforms. If all our TTS options were platform dependant, that > would be about the only good reason to avoid integration with the library > and go straight to the frontend. > > It's essentially the same as we have done with ICU. > > --Chris
