PrimTux, la distribution éducative

Comme vous le savez, je me débrouilleun peu en python et j'ai apporté mon premier correctif à ce projet : https://github.com/lusum/gSpeech/pull/1

De l'autre, il commence a y avoir pas mal de questions sur ce soft dans la discussion sur la PTX4.

Il y a notamment des dépendances à rajouter à ce paquet : gir1.2-gstreamer-1.0 évoqué aujourd'hui mais aussi xfce4-notifyd
évoqué la semaine précédente.

Néanmoins, j'aimerais sans doute proposer une option qui évite l'affichage des notifications (je trouve ça pénible et sans intérêt une fois qu'on a pris en main)

Est-ce que ça vous parait judicieux ?

C'est toujours intéressant de permettre à l'utilisateur de pouvoir choisir s'il souhaite ou non l'affichage de notifications, sans lui imposer un choix.

C'est fait. J'ai ajouté une boite de dialogue avec une checkbox qui permet d'afficher ou non les notification. Ca édite un fichier de config dans ~/.config/gSpeech/gSpeech.conf.

Mon correctif : https://github.com/mothsART/gSpeech/tree...tification

J'ai effectué une pull request au mainteneur.

J'ai traduit l'ensemble de l'interface (il manquait 6 chaines de caractères) + pull request au mainteneur.

Pour info : le mainteneur a fusionné (non sans quelques péripéties) mes modifs !

Bonjour
Je souhaiterai ralentir la vitesse de lecture
comment peut-on régler ce paramètre ?
Merci
Alain

Bonne question dont je n'ai malheureusement pas de réponse. (même après recherche).
Gspeech est un soft qui se base sur SVox Pico : un moteur de synthèse vocale dédié à Android qui a progressivement été abandonné par Google.
Il n'y a aucune option permettant de règler la vitesse. Une solution serait sans doute d'effectuer une seconde passe sur le fichier wave généré afin de le ralentir ou l'accélérer. (avec gstreamer ?)
Le risque c'est sans doute d'avoir un son plus grave si ralenti et plus aigu si accéléré.

Je le note pour évolution mais je ne promets rien.

En revanche, je vous invite à améliorer la lecture de certains mots, expressions ou phrases en éditant ce fichier : https://github.com/mothsART/gSpeech/blob.../fr-FR.dic

Çà ne nécessite pas de connaissances techniques mais ça peut apporter un réel plus.

Peut-être qu'un jour il faudra adapter Gspeech pour qu'il puisse utiliser plusieurs synthèses vocales. (par exemple : festival, espeak)

Je suis en pleine réflexion de l'amélioration de la lecture de Gspeech.
Y'a quand même pas mal de cas ou il se vautre lamentablement et ou les correctifs ne demande pas d'efforts trop conséquent :

- terme provenant de l'anglais => ex: hacker, wiki, hardware, ram
- abréviations courantes => ex: SNCF
- logiciels utilisés dans Primtux => ex : openboard
- marques connus => ex: google
- langage sms ou abréviation

plus délicat :

- quelques soucis de liaison => ex: tout à fait
- quelques mots => ex: menu (et par conséquent handymenu)

Je suis en train de préparer une version (ça demande de toucher un peu au code) qui prendrait tous les motifs uniques et les remplacerait à la volée.

Motif unique : c'est une chaîne de caractère qui, qu'elle soit en minuscule ou majuscule, contenu dans une chaîne ou mot à part n'a pas d’ambiguïté de prononciation.

Par exemples :

"google" peut se retrouver dans "dégooglelisons" et sera prononcé "gougeulle"
l'abréviation odt ne se retrouvera pas dans une autre chaine donc il n'y a que "o d t" qui est acceptable.

Bref, mon but est d'avoir une liste correspondant à ces critères la plus longue possible afin d'avoir une lecture plus fluide sur des cas simple.

Une fois que j'aurais réalisé cette passe, il sera sans doute possible de se concentrer sur des cas plus complexes.

Tiens, ça me fait penser que je peux sans doute faire participer d'autres communautés (Debian facile, Ubuntu)...

Une petite question

si je fais en mode administrateur
cd /usr/lib/libreoffice/program
sudo ./swriter

je tombe sur la version de libre office avec pico vox et dans parameters je peux régler la vitesse d'élocution
en mettant 0 j'arrive à quelque chose qui est aidant pour des non lecteurs
remarque cette vitesse une fois réglée reste en memoire et après redémarrage c'est encore celle-la qui s'affiche...

Or la vitesse standard qui est proposée avec gspeech est trop rapide
Comme gspeech est basé sur svox pico et que gspeech propose des paramètres ne serait pas possible d'inclure un choix de vitesse qui resterait en mémoire ?
Car pour moi quand gspeech sera utilisé, c'est que l'élève sera en grande difficulté de lecture et il faut que la vitesse 0 de picovox soit réglée par défaut même si à nous adultes cela parait lent...

Bonne remarque Alain : j'ai repris le code source de gspeech et me suis familiarisé avec l'interface en ligne de commande svox pico.
Seulement, je n'ai jamais trouvé d'arguments correspondant à la vitesse. Je vais, de ce pas, lire le source de l'extension : je trouverais peut-être la clé de l'énigme. (le métier de développeur n'est pas très éloigné d'un inspecteur)

Bon
une autre piste sans gspeech

En réinstallant l'extension picovox telechargeable ici http://extensions.openoffice.org/download/18026 après avoir fait un
sudo chmod -R 777 /home/02-super/.config/libreoffice/4/user/config/
j'arrive à mettre l'extension picovox dans la barre d'outils de libre office pour super
cette extension permet un réglage fin de la vitesse de lecture ( le standard est à 100 et ce que je recherche est autour de 60 )


problème
Impossible de définir précisément les boutons visibles ( je ne voudrais avoir que le bouton lecture selection ) et impossible de sauvegarder la barre d'outils avec picovox present
Voici ce que je souhaiterai


Alain

Ps Peut être que ce post a plus sa place dans la section libre office des écoles

Alors, oui Alain : ton dernier post à d'avantage sa place dans la section libre office des écoles.

L'extension est développé en python (comme gspeech) mais n'utilise pas du tout pico de la même façon. Il se base sur l'api en C au lieu de la ligne de commande et par conséquent a des fonctionnalités en plus comme la vitesse de lecture !!

Je pense donc étendre mes travaux de refonte sur la création d'une librairie qui viendrait enroller pico.
Ca permettra, à terme, plusieurs fonctionnalités :
- amélioration de la lecture
- utilisation sur des logiciels web via un mini-serveur
- factorisation et harmonisation entre gspeech et picovox

Un petit état d'avancement rapide.

J'ai fini par retrousser les manches en créant un soft de A à Z que j'ai appelé SpeechTux. (ouais, niveau originalité, c'est pas ça)
Mon but est donc un nouvel outil unifié qui viendrait pallier aux manque de Gspeech.

J'ai déjà effectué un travail de fond, à savoir :
- comprendre le fonctionnement de l'extension **picovox** de libreoffice.
- compréhension de la libc de picoTTS
- création d'un binding en Rust

Ces étapes m'ont demandé de la persévérance, quelques énervements mais au final une base solide pour partir sur un bon pied.

Les sources du projet.
Une présentation avec ce que j'envisage : https://github.com/mothsART/speechtux/bl...ntation.md

Bonne initiative, parce que niveau synthèse vocale c'est pas top.

Nouvelle itération :
- binding C pour que d'autres langages puisse facilement l'utiliser.
- wrapper en python et fichier d'exemple qui lit du texte à vitesse normal, lente, accéléré, voix grave.
- Gspeech modifié pour qu'il soit pleinement compatible avec python3 et qu'il s'appuie sur ma lib.

La prochaine itération se concentrera sur :

- permettre à Gspeech de régler la vitesse d'élocution.
- mise en place de jeux de test pour améliorer la lecture de certains mots.
- packager tout ça pour que ça puisse être testé facilement.

Bref, ça avance. Bientôt du concret.

L'appli de Philippe (merci à lui) "j'écoute puis j'écris" http://forum.primtux.fr/viewtopic.php?id=1991&p=4 m'a permis de corriger pas mal de soucis de lecture de gspeech sur des mots, expressions assez courantes.

Néanmoins, c'est un terrain assez friable car une petite modif peu avoir un impact significatif. (apporter des régressions)
Pour améliorer la maintenance, j'ai fini par mettre en place de l'intégration continue (CI).
Je vais bien entendu expliquer qu'est-ce que c'est, les avantages et comment ça marche.

1. On met en place des tests automatisés qui vont testés une partie du soft.
2. on utilise un outil de CI : ici Travis qui est couplé à Github. (mais y'en a plein d'autres)
3. A chaque commit sur le dépôt, l'ensemble des tests vont être joués et si ils passent tous, le build est vert, sinon il est rouge.
Dans le cas ou ça ne passe pas, il est possible de voir la raison sur Travis (https://travis-ci.org/github/mothsART/gSpeech) ou de rejouer les tests en local.
Je reçois d'ailleurs un mail à chaque push avec le résultat du build.
On peut voir "build passing" en vert dans mon README : https://github.com/mothsART/gSpeech/

Dans le cas de Gspeech, j'ai mis en place des tests fonctionnels.
Dans un premier temps, je fais lire des phrases à Gspeech et si je les considères comme "juste", je sauvegarde le résultat (fichier son en .wav) dans un dossier spécifique : https://github.com/mothsART/gSpeech/tree...ests/fr_FR

Les tests vont rejouer ce type de phrase automatiquement, les mettre dans un fichier temporaire et je vérifie qu'ils sont conforme à ceux enregistés.
(je compare les md5)

Pour l'instant, je n'ai mis qu'un texte en place mais je pense incorporer l'ensemble des textes de "j'écoute puis j'écris".

Une fois fait, à chaque fois que je rajouterais une règle de lecture spécifique, il vérifiera que l'ensemble des lectures précédentes n'ont pas été impactés.

Les tests se lance en local comme ceci :


et Travis est configuré ici : https://github.com/mothsART/gSpeech/blob...travis.yml
Travis lance en réalité une Ubuntu donc je lui dit d'installer préalablement la lib "libttspico-utils" puis je lance mes tests. (exactement comme en local)

Voilà, j'espère que mes explications ont pu vous éclairer sur l'intérêt de l'intégration continue et pourquoi il faut commencer à en distiller (intelligement) dans Primtux.

Et une fois terminé, je mettrais un nouveau n° de version et donc nouveau paquet en conséquence.

Je viens de mettre à jour le dépôt avec du contenu.
Comme convenu, il y a une couverture de tests plus conséquente et donc un soft plus abouti en conséquence.

J'ai pris soin de segmenter les entrées du dictionnaires dans des dictionnaires séparés.
Désormais, il y a la notion d'abréviations, d'acronymes, d'expressions, de nom propres, de termes techniques.

N'hésitez pas, bien évidement à me remonter toute phrase qui poserais soucis.

Voilà, j'ai peaufiné la version 0.8.0 :
quelques améliorations mineurs et surtout un "vrai" paquet debian digne de ce nom. (avant, tout était dans /opt si je ne me trompe pas).

Pour créer le paquet, voir : https://github.com/mothsART/gSpeech#crea...an-package

Je pense faire une annonce sur linuxfr.

L'annonce sur linuxfr : https://linuxfr.org/users/mothsart/journ...speech-0-8

Du coup, édition rapide du wiki : https://wiki.primtux.fr/doku.php/gspeech

Je viens de passer le soft en version 0.9 :
- ajout d'une option sur l'affichage des notifications
- correctifs mineurs divers
- meilleur support de traduction
- grosse refacto en vue de tout piloter par des tests
- le soft peut désormais être intégrer à nix

Le résumé peut sembler bref mais y'a eu un gros travail de fond d'harmonisation du code, de respect de l'écriture en python, du découplages en briques atomiques.

Bref, c'est propre et il ne manque plus que :
- le contrôle de la vitesse de lecture qui ne devrait pas être trop difficile à mettre en place
- des tests unitaires sur l'ensemble du code. (code coverage)
- quelques améliorations sur les dictionnaires

pour pouvoir atteindre une version 1.0 digne de ce nom.

J'ai intégré le soft sur Nix : https://github.com/NixOS/nixpkgs/pull/86641
C'était pas sans efforts mais ça à permis de découvrir quelques vulnérabilités du soft, d'apprendre beaucoup à divers niveaux.

J'espère que ça donnera un peu de visibilité à gSpeech.