Re: [g-a-devel] gnome-speech driver parameters

[Bill Haneman <Bill Haneman Sun COM>]

Hi George:

For ECI it would make sense to separate the speaker and driver 
parameters, and I expect other engines will have similar 
properties/parameters tied in some cases to the engine as opposed to the 
voice.  However since gnome-speech is intended to be engine-agnostic, I 
think any such separation should be grounded in semantics rather than 
implementation convenience.

One possible issue is what to do about parameters which can _only_ be 
set on the engine, and which would therefore interfere with one another 
in cases where multiple Speakers have been instantiated from such an 
engine.  As long as it is possible to accomplish this via switching of 
engine parameters on-the-fly (when switching voices), and voices are not 
multiplexed, then I don't mind some additional bookkeeping overhead in 
the drivers for doing this.  But there may be cases where this is 
difficult or perhaps impossible to implement. 

So if you don't mind, I'd like to return the question to you; are there 
parameters which the end-user is likely to wish to change on-the-fly 
which cannot reasonbly be associated with Speakers (aka 'voices') rather 
than engines, in the ECI model?  My test for identifying such a 
parameter would be something like this:

1) parameter is something we may wish to expose to the end-user, or 
which an important end-user feature suggests should be modified on a 
per-voice basis;
2) parameter actually applies to the engine;
3) parameter cannot be switched on the engine on-the-fly in such a way 
that the parameter appears to be associated with a virtual 'Speaker' 
rather than the engine.

I suppose if we identify a few important parameters of this type, that 
would be justification for adding a get/setParameter API to the 
Gnome_Speech_SynthesisDriver.

regards

Bill

George Kraft wrote:...

> The ECI APIs segregated _speaker_ and _driver_ parameters.  The
> _speaker_ parameters were per speaker.  The _driver_ parameters were
> global for all speakers. This is how eloquence, ibmtts, viavoice, and
> ttsyn on Linux work.   I agree with you that the existing speaker
> parameter interface could be used.  It's your call, I won't strong lobby
> or object to either direction. :-)  Thanks.
>  
>
> George (gk4)
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>