[Kde-accessibility] Proklam and KMouth

[Pupeno]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 23 September 2002 06:47, Gunnar Schmi Dt wrote:
> I think the phrases that are spoken via KMouth should be classified as
> messages? I do not need to navigate through them, but a feature to stop
> speaking a phrase would be nice. (Is it possible that KMouth gets informed
> when Proklam finishes speaking a message?)
Stoping the phrase won't be posible as the speaking function, at least in=20
=46estival, is atomic from this side of the street. Once I call the Festiva=
l=20
function, the program is blocked untill it ends, and even when Proklam bein=
g=20
multithreading there's nothing I can do tu interrupt a function.
You'll have a number which will be a unique number to identify messages or=
=20
warnings and you could use that to know if a warning or message has been=20
spoken or not. We could add a feature that you can 'register' with proklam =
so=20
it will send you a dcop message when a message or warning is spoken, but=20
then, that won't be covered in the API KSpeech (mixing everything, what cou=
ld=20
be done is make a blocking call to sayWarning and sayMessage in KSpeech).
I think KMouth should normaly say messages but with the posibility to say=20
warnings because someone may be listening to a long text and may have=20
something to say imediatly... then that would be a warning.

> > > 4th idea: Make it possible to load several plug-ins, and implement a
> > > parameter forwarding mechanism. When the program asks for special
> > > parameters ("language" =3D "en" and "sex" =3D "female"), then Proklam=
 calls
> > > a parameter function in the default plugin. If the function returns
> > > with "false", then the next plugin is tried. If none of the active
> > > plugin is found, then the default configuration is used.
> >
> > [...]
> > My idea is this... as you say, load more than one plug in at a time. In
> > the KControl module, you'll chose to add a language... so, you add the
> > language English and a tab or something like that for English is added,
> > then, inside that tab, you chose which plug in you want and which voice
> > you want (Festival for example, doesn't trully separate languages, but
> > voices, you could end up defining an spanish voice for a english), then
> > if you add Spanish, another tab for Spanish is added.
> > [...]
>
> With KMouth in mind I could work with both ideas. However, I need a list =
of
> languages that are supported by Proklam (I assume that Proklam has a
> function that can be used to enquire this list). The former idea needs to
Ok, it'll be there.

> be extended for that (each plug in needs to contain a function that retur=
ns
> a list of languages).
>
> The formar idea is more work to implement:
> -There needs to be a larger interface between Proklam and the plug ins.
> -Proklam needs to contain some more complex code in order to determine
> which plug in is used.
> -Each multilingual plug in needs to have a multilingual configuration,
> which is more complex both to implement and to use than a single-lingual
> configuration (selecting multiple voices for multiple languages for
> example).
>
> As both ideas contain the fact that Proklam can load multiple plug ins at
> the same time, I do not see why we need to implement this overhead.
> Therefore I would prefer the latter idea.

The problem allowing multilingual plug ins to manage multiple languages is=
=20
that it turns the complete system in something much more complex, from my=20
point of view (developer), from the user point of view (to configure the=20
system), and maybe even to you (the developers using Proklam).
The problem with that is that it should allow you to load any amount of plu=
g=20
ins and configure languages inside them, any amount of languages and then i=
f=20
you load Festival it should load by default one voice with one language whi=
ch=20
may interfeer with another TTS already working and that requires a lot of=20
checking-if-the-configuration-will-work. Another problem with that as you=20
said, plug ins and Proklam will need a greater comunication so plug ins cou=
ld=20
register the language they are supporting. And I think this could even have=
=20
another drawback... how much times takes Festival to switch from one voice=
=20
(language) to another ? supouse that you triggered the reading of a long te=
xt=20
and something triggers a bunch of messages and warnings and although you=20
speak english, you're desktop is english and that messages and warnings are=
=20
in english, the text could be in german and it will be hell of loading voic=
es=20
which will consump a lot of resources.

So, reformulating my previous idea, it would work this way:
In the configuration, you chose a language and press [ADD], so a tab with t=
he=20
language name in it is added at the bottom of the configuration... in that=
=20
tab, you chose the plug in you want to use for that language, and then you=
=20
configure it (of course, you have to be carefull to chose an english voice=
=20
for english and a spanish voice for spanish in the case of Festival for=20
instance). If you want another language, you select another language and=20
press add, another tab is added... then, you can select festival or whateve=
r=20
plug in you have installed... so, each language will have it's own plug=20
in/configuration. Do you understand ? do you like it this way ? The main=20
drawback of this is having a lot of plug ins loaded at the same time... but=
=20
who will need more than 4 languages at the same time ? An important feature=
=20
is that with advanced configurations I'll be able to tune the system. For=20
example, in Festival, you have the heapsize... supouse that you load spanis=
h=20
because from time to time you want to say/hear something in spanish, but yo=
ur=20
main language is english and that's what you'll use all the time, then you=
=20
may configure Festival in english with a big heap size and festival in=20
spanish with a smaller heap size.

Another thing... for example, there's no easy way to say which languages=20
support Festival, since they're just voices, to know which languages it=20
supports I'll have to dig inside the available voices to build the list of=
=20
languages and it doesn't seem a nice practice... with other TTS it may not =
be=20
posible at all (I'm not sure that it's posible with Festival).

I'll take a look at gnome-speech API and Architecture to polish this and I'=
ll=20
try to send ASAP a mail with the next API/Arch of Proklam here so we can=20
discuss over that, ok ?

Thank you.
=2D --=20
Pupeno: pupeno@pupeno.com
http://www.pupeno.com
=2D ---
Help the hungry children of Argentina,=20
please go to (and make it your homepage):
http://www.porloschicos.com/servlet/PorLosChicos?comando=3Ddonar
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9j1YRLr8z5XzmSDQRAo/mAJ9+0X4iyXMxm1VSEl2hKd2sWIzxogCg4OWb
Nxtjj75qvwottQqxGzjZkTA=3D
=3DrDzU
=2D----END PGP SIGNATURE-----