Please wait before releasing 0.9, more voices available soon.

[Samuel Thibault]

Didier Spaier, le dim. 25 nov. 2018 21:02:51 +0100, a ecrit:
> > Well, it is interesting to include support for more flite voices, but
> > the generic.conf way poses a lot of problems:

[...]

> Well, I disagree.
> A specific module can technically better, however I am not convinced
> that makes a big difference for the end user, running Orca for instance.

It does make a big difference.  Being able to interrupt the speech as
quickly as possible is a very important one, for instance.

> won't be bothered by the lack of indexing (or does that manifest?)

He will.  That manifests in Orca by the cursor being positioned where
the speech was interrupted (and Hypra is working on showing the speech
progression).

> and have other ways to increase or decrease the volume.

But they are not integrated in the normal speech process.

> Listing all potential voices in the generic.conf file is only to be done
> once

No, it needs to be done everytime somebody creates a new voice in the
world.

> Yes there can be a maintenance issue but new voices are not provided
> frequently.

That's true, but it still means that either speech-dispatcher
maintainers have to be aware of all flite voices in the world (they are
not necessarily provided on festvox.org), or the user has to modify the
configuration file, which is not user-friendly. The user just having to
put the .flitevox file in /usr/share/flite/, however, is user-friendly,
and could just work with appropriate support in flite.c.

> Yes extending flite.c to support listing the voices available in
> /usr/share/flite woudl be better, but who will do it and when? Do we
> have to wait to provide more voices?

flite support has been available in speech-dispatcher for ages. Can't
supporting more voices wait for an appropriate implementation??
Providing bad support (missing features mentioned above) may even be bad
publicity.  I really appreciate your help on speech-dispatcher, it is
very welcome, but we need to be careful with not hasting too much.  I
have too often seen half-backed solutions actually last for a long time
and hurt on the long run, while a proper solution can be implemented
with not much more effort.  Also, delaying a release just for yet
another feature is not usually a good thing to do: you'll potentially
never end waiting for new features.  The Linux and Debian processes, for
instances, is harsh, but does work: only bugs & regressions can delay
the release.

> Introducing an other way to use flite can only confuse the user if
> speechd.conf is not set by the package or distribution maintainer to
> avoid that: there is no point enabling flite if flite-generic is enabled
> IMO.

As mentioned above, flite support is way better than flite-generic
support, so we'd want to have both, to both have proper support with
only the integrated flite voices, and reduced support but with much more
voices.

> But this is not the only case: if we want to limit these confusions
> better get rid of generic.conf files that provide zero added value, like
> pico-generic.conf and espeak-generic.conf

We should get rid of them, yes. We should just make sure that the binary
modules do not miss any feature.

> (I'd tend to also remove espeak.conf and espeak-mbrola-generic.conf
> in future releases but I understand that not all users will replace
> espeak with espeak-ng soon).

We'll want to remove them as well once distributions have finished
migrating to espeak-ng, yes.

> > As mentioned previously, you shouldn't need that with 0.9 RC2. If you
> > still have issues with RC2, please provide more details. At any rate,
> > this is not a proper fix since putting a space there is not without
> > consequences.
> 
> I confirm: that's not needed any more

Good :)

> Incidentally other files have a space between double quotes:
> didier[/data/GitHub/speechd/config/modules]$ grep ^GenericPunctNone *
> espeak-generic.conf:GenericPunctNone ""
> espeak-mbrola-generic.conf:GenericPunctNone " "
> espeak-ng-mbrola-generic.conf:GenericPunctNone " "
> mary-generic.conf:GenericPunctNone " "
> pico-generic.conf:GenericPunctNone " "

I guess they encountered the same issue and worked around it instead of
just fixing it.  I have now fixed them, thanks!

So, to summarize: thanks for your caring about it, but I'm sorry of
saying that I don't want to introduce another flite module module with
really reduced functionality while the existing one could be extended
with not too much effort.

Samuel