moin Patrice,
On 2007-06-08 17:21:48, patrice colet megalegoland@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).
marmosets, Bryan