In general, avoid writing lisp code using +compiler and -compiler directives -- it leads to untold grief. It's as bad as writing #ifdef in C by hand without the aid of gnu autoconf and configure. For unix level bits such as networking, escape from lisp as quickly as you can, i.e. fork a sub-process that does th ework. That separate process can be coded in something like python or tcl, and those languages take care of the cross-platform complexities. -- Best Regards, --raman Email : firstname.lastname@example.org :ã WWW : http://emacspeak.sf.net/raman/ : â GTalk : email@example.com : â PGP : http://emacspeak.sf.net/raman/raman-almaden.asc : â Google : tv+raman : ? IRC : irc://irc.freenode.net/#emacs : â BRL: ââââââââââââââ : â -- Best Regards, --raman Email : firstname.lastname@example.org :ã WWW : http://emacspeak.sf.net/raman/ : â GTalk : email@example.com : â PGP : http://emacspeak.sf.net/raman/raman-almaden.asc : â Google : tv+raman : ? IRC : irc://irc.freenode.net/#emacs : â BRL: ââââââââââââââ : â On 4/8/10, Tim Cross <firstname.lastname@example.org> wrote: >> Tim Cross <email@example.com> wrote: >> >>> The openTTS code does have a CL package that provides a speech interface. >>> At >>> least, it did when it was speech-dispatcher. The code is quite simple, >>> but was >>> a little limited in that it wold only work correctly with one specific >>> version >>> of CL. From memory, this was either CMUCL or SBCL. >> >> They're related, as you know. >>> > > Yep, SBCL was originally a fork of CMUCL. The main problem with the SSIP > package is that it relies on networking support to communicate with the > speech > server. Unfortunately, the ANSI CL standard didn't cover networking and many > other 'standard' areas that are usually part of standard libraries in more > recent languages - an artifact of when the ANSI standard was defined I > guess. > As a consequence, the way CMUCL, SBCL, CLISP etc handle networking varies, > so > you need to have separate code for each flavor of CL. Luckily, this is > reasonably easy to handle with the + and - compiler directives. The only > downside is it means more code and more code means more potential bugs! > >>> I did provide patches to them on at least three occasions, but the last >>> time I >>> looked (over 5 years ago at least), they had not been included. I'm not >>> sure >>> if I still have the patches or not, but theyw ere pretty trivial and I >>> can >>> easily reproduce them. >> >> The new maintainers may be more cooperative. They're also fixing large >> numbers >> of bugs, such as memory leaks, in the C code. >> > Yes, I've noticed they have had quite a few fixes in both the C code with > respect to memory leaks and fixes to improve pulseaudio handling etc. In > principal, I think the openTTS approach does have some real potential, > though > I'm not familiar enough with the specifics of the protocol to assess how > good > it really is. Experience has taught me to be somewhat reserved when it comes > to protocols that are designed by committee - they often end up over > engineered. As an example, consider CORBA, SOAP and REST. The CORBA > specification ended up so complex that even now after over 15 years since > the > spec was first developed, the OMG still has to admit there is still no fully > compliant version. SOAP started out aiming to be a 'simple object access > protocol', but over time has begun to show more complexity than was > originally > aimed for and to some extent, as a consequence, REST has developed because > often, you just want something simple and light weight. > > In comparison, while the protocol used by emacspeak may lack a clear formal > specification, it has evolved to meet actual requirements rather than > theoretical ones. Sometimes, such an approach can result in inefficient or > less than optimal design, but provided you are prepared to refactor and > refine > things as experience increases your knowledge and understanding, you will > usually end up with a better result in the end. > > In my efforts to get espeak working well, I've noticed a number of > inefficiencies and possible limitations with how it has been implemented. I > have some ideas on how things could be improved and I'm experimenting with a > few ideas, which I plan to release if they bare fruit. As part of this > process, I'm also trying to document the interface with the TTS drivers. > While > I'm hoping this will identify how to best improve the espeak integration, > I'm > also hoping this will make it easier to identify the possibilities for > adding > a speech-dispatcher/openTTS interface for emacspeak. At the very least, I'm > hopeful this may provide information that will make it easier for other TTS > backends to be added to emacspeak. > > I expect it will be a while before I have much of any substance to share. > However, once I do, I'll be writing it up and distributing to the list for > comment and improvement. > > Tim > > > > ----------------------------------------------------------------------------- > To unsubscribe from the emacspeak list or change your address on the > emacspeak list send mail to "firstname.lastname@example.org" with a > subject of "unsubscribe" or "help". > > ----------------------------------------------------------------------------- To unsubscribe from the emacspeak list or change your address on the emacspeak list send mail to "email@example.com" with a subject of "unsubscribe" or "help".
If you have questions about this archive or had problems using it, please send mail to:firstname.lastname@example.org No Soliciting!
Emacspeak List Archive | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | Pre 1998
Emacspeak Files | Emacspeak Blog | Search the archive