Re: Proposed Extension: Flite (a small, fast run time synthesis engine)

> > 1) __construct() should have ZEND_ACC_CTOR in its flags field.
> What does that do specifically?
It's a hint for the engine... Causes special handling in cases like 
exceptions being thrown from the constructor.
> > 2) Speaking of __construct(), you could save some memory/cpu by
> > storing your resource in an extended zend_object struct using an
> > overrided object_ctor method and tossing out __construct() since
> > you don't need any parameters anyway.
> True, I just found it a handy place to store the voice pointer
> which I knew worked from prior code I had written. Do you
> happen to have a short code snippet illustrating your suggestion.
Sure, not only is it a more tried-and-tested (and familiar) method, but it's 
the only PHP4 compatable one.   Which brings up one thing... Seems like this 
implementation could be made ZE1 compatable with a few conditional defines 
(though that'd preclude going the overloaded zend_object route of course). 
PHP4 is pretty crusty and probably not worth supporting, but it's a 
thought....
Anyway, on the subject of zend_object overloading.... I wouldn't call it a 
simple example, but Runkit_Sandbox does this (and then some), when I've got 
a minute I'll see if I can cobble a simpler one together.
> > 3) A save_to_file() method would seem appropriate
> Agreed, I just needed to learn more about that first to
> make sure I was doing it the "PHP" way.
Take a look at file_put_contents(), it'll probably be the simplest example 
for you to work from.
> > 4) Are there other voices? Is there a way (planned)
> > to change them?
> Not by default, but it's possible to have additional voices
> if converted. I'm still exploring this and once I have
> something working I will start tying that in.
I look forward to it!

> > 5) It'd be handy to be able to fetch metadata about
> > the wave (num channels, samples per second, etc...)
> > Are the samples always a particular format?
> > (16bit, signed/unsigned, big/little endian)
> Currently they are always little endian. I haven't built
> big endian support in yet. It would be a simple matter
> to have getters for num channels, samples per second,
> etc so I will add them later this week.
Is that because of the WAV standard?  The library implementation? Or just 
because your ext doesn't take advantage of any ability to change that 
setting.
> > 6) Would you like some exports in oggvorbis so that
> > TTS data can be pumped striaght into an ogg/vorbis
> > output file?
> That would be awesome! I was looking into doing mp3,
> but ogg/vorbis would be much better due to licensing issues.
I thought twice about this after sending my last post, it'd probably be 
simpler just to send the wav data to the user and let them pump it out to 
the stream rather than complicating source with optional dependencies.
file_put_contents('ogg:///path/to/file.ogg', $tts->get_wave());

Although.... then the user has to be aware of and pass the right PCM 
encoding constant LE16...whatever it was.... I havn't touched oggvorbis 
in....well a very long time....
We can kick this particular idea around a little more....See what falls 
out...
-Sara