[PD] [OT] Voice Synth

Bryan Jurish moocow at ling.uni-potsdam.de
Sat Jun 9 01:22:55 CEST 2007

moin Patrice,

On 2007-06-08 17:21:48, patrice colet <megalegoland at yahoo.fr> appears to
have written:
>  thank for making pd speak, I've successfully compiled [flite] for amd64
> on ubuntu feisty, but i had to hack the configure file,
> the -fPIC flag was missing, so I've added this one at line 3845:
> WFLAGS="-Wall -fPIC"
> I didn't test if this code is compatible with other architectures, I'm
> not an expert, :D.

-fPIC should be linux-safe; I'm actually surprised it wasn't there
already... at any rate, it's there now (in cvs): thanks for the report.
 just for the record, what happened when you tried to compile without
-fPIC ?

> It wasn't enough, [flite] dependances has been installed with apt-get,
> then the flite headers and libraries wasn't in a place expected by the
> configure file (I didn't have chace with --with-flite-dir option). I
> didn't modify the configure file very elegantly for having the script
> finding headers and libraries, but it has worked...
> IFLAGS="$IFLAGS -I/usr/include/flite"
> LFLAGS="$LFLAGS -L/usr/lib"

Funny, it works here (debian) with the deb-default flite (and -dev)
locations... in such situations (i.e. "non-standard" prefab installation
locations), the "official" solution for anything built with the gnu
autotools (like flite or any other of my externals) is to set the
environment variables such as CPPFLAGS (C preprocessor flags, *not*
c-plus-plus flags), CFLAGS (C compiler flags), LDFLAGS (linker flags),
LIBS (additional libraries) etc.; so you could do something like:

 $ export CPPFLAGS="-I/usr/include/flite"
 $ export LDFLAGS="-L/usr/lib"
 $ ./configure ; make ; make install

... and the build ought to work without having to hack the configure
script.  I think that this is a pretty good way to handle arbitrary
installation locations & distribution foibles, so I do not plan on
changing this behavior or the default locations.

>  The attached file is a modification of the help patch I've made for
> resolving a buffer issue, I've just added a banged message 
> [;array const  0( 
> before flite computes the voice, for emptying the buffer, it's one
> method among many others...

what happens on your system if you don't explicitly zero the array
before re-synthesis?

>  And finaly, anyone knows how to configure the synthetized voice?

Basically: you can't do that with the pd [flite] object in its current
form (sorry).

It is (supposedly) possible, though: there is a bizarre and cryptic
C-level flite API to allow tweaking of some of the many configuration
parameters that festival offers, but I'm not a festival expert, I rather
dislike SCHEME (give me LISP!), and trying to figure out which of
festival's SCHEME-coded options got transmogrified into which of flite's
C structures & parameters without sufficient documentation or examples
is more than I felt like dealing with; I may get around to it some day,
but it's not too high on my list of priorities as long as [flite]
continues to block the cpu during synthesis.  If you want/need
user-configurable _offline_ synthesis, consider using festival directly
(e.g. from pd with SayWhat over OSC).


Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology

More information about the Pd-list mailing list