Hypra contributions shipped into speech-dispatcher ? (new punctuation mode from NVDA, new TTS: Kali and Voxygen)

[Luke Yelavich]

Hi Alex, everybody.

I am sorry it has taken a while to respond. I am busy with Vinux project 
duties, as well as other things outside of Linux and software development 
that could lead to employment opportunities in the future. Reply is inline.

On Fri, Jul 21, 2017 at 06:07:15PM AEST, Alex ARNAUD wrote:
> Dear Luke and speech-dispatcher contributors,
> 
> For a year, we've developed the following features for speech-dispatcher:
> - two modules for adding the support of two new TTS : Kali TTS and Voxygen
> (Baratinoo).

We need to work out a way hat I can test these modules, since they are 
proprietary, more on that below.

> - a punctuation engine to support punctuation level for TTS which don't
> incorporate their own punctuation management. It's a port of the NVDA code
> from Python to C++.

I am actually looking at merging this now, disabled by default, but of course 
users can easily enable it in the config file so that it can be tested. We do 
have some users who choose to run speechd git master, and I am not about to 
cause those users any trouble yet, although they should know that if things 
break, they do get to keep both pieces.

> We really want the code to be shipped into speech-dispatcher because we
> think it's the most efficient way to ensure the quality of the module due to
> the review by the community.

This makes sense, however drivers for proprietary synthesizers are a concern. 
Long term, the plan is to get to a point where drivers can be maintained and 
built out of tree, but a lot of work needs doing before we can get to that 
point. Until then, I am hesitant to add more driver code for proprietary 
synthesizers to the Speech Dispatcher tree. Already with the work that is 
slowly getting done to move to GSettings, there will be a high chance of 
dropping one or more modules that are currently in Speech Dispatcher, that 
require other proprietary components, because they cannot be tested.

For the proprietary synthesizers you are wanting to add support for, not 
being able to even build the code to make sure it compiles cleanly etc makes 
refactoring and implementing functionality difficult. As the project 
maintainer, I don't feel comfortable making required code changes to 
proprietary synthesizer drivers, and committing those changes to git or 
releasing them in a tarball, unless I have been able to verify that my 
changes at least work, and don't break things horribly.

I guess we could consider having some sort of maintainer model, where every 
driver has someone responsible for it, and if functionality is added/changed 
that affects all drivers, then a driver is not buildable until the driver 
maintainer gives the ok that things work, or submits patches to fix things to 
make their driver work.

Would Hypra be willing to be maintainers of these synthesizer drivers you 
have proposed, knowing that if the drivers are not tested prior to a release, 
they will be disabled from building in the release tarball?

> Lot of distribution come with speech-dispatcher package, so if our code is
> shipped into speech-dispatcher more people could use it easily.
> 
> What is your plan for the integration ? What could we do to help you for the
> integration ?

It is a matter of me getting to it. As mentioned above, I am involved with 
other projects, i.e Vinux, and am also taking time to pursue other interests 
for possible future work. I am trying to make as much time for these projects 
as I can. Of course, other community members are welcome to come forward and 
help with review and get the branches committed.

Luke