Progress with AsteR installation

["T.V. Raman" <tv.raman.tv@xxxxxxxxxxx>]

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			:  raman@xxxxxxxxxxx :ã
WWW			:    http://emacspeak.sf.net/raman/ : â
       GTalk		: tv.raman.tv@xxxxxxxxxxx : â
PGP			:    http://emacspeak.sf.net/raman/raman-almaden.asc : â
Google			: tv+raman  :  ?
IRC			:    irc://irc.freenode.net/#emacs : â
BRL:	ââââââââââââââ	: â

-- 
Best Regards,
--raman


Email			:  raman@xxxxxxxxxxx :ã
WWW			:    http://emacspeak.sf.net/raman/ : â
       GTalk		: tv.raman.tv@xxxxxxxxxxx : â
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 <tcross@xxxxxxxxxxx> wrote:
>> Tim Cross <tcross@xxxxxxxxxxx> 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 "emacspeak-request@xxxxxxxxxxx" with a
> subject of "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".