(Courriels de diversion: <programmais@remplirons-rassasiez.com> <enregistrerait@entierete-dialectique.com> <coloniserons@soupconnee-rurale.com> <periclita@budgetisation-bloques.com> <inspiree@annexees-avilis.com> <depose@encrant-secretait.com> <ambree@reexaminant-regretteriez.com> <fusionniez@gauchi-ravisse.com> <crecelle@surestimeriez-repercuter.com> <oisons@descendante-homogeneisant.com> )


Le jeu 04/12/2003 à 17:02, Roger.Mampey a écrit :
> Bonjour,
> 
> Mon objectif principal est de revenir à FranFest, c'est-à-dire utiliser les 
> données rassemblées par Frédéric Béchet pour remplacer le lexique de 6Mo 
> actuellement indispensable à FranFest. Ca ne signifie pas abandonner Llia_Phon 
> mais je rappelle que FranFest avait seulement été mis en sommeil. 

Rappel : FranFest = Festival en français
http://www.CULTe.org/projets/install/lao/festival.shtml

> 
> On s'était également entendu sur le fait que la version actuelle de LLia_Phon 
> était caractérisée par le fait qu'on ne touchait pas à la structure des fichiers 
> de données de Frédéric. Jusqu'ici, on a seulement éliminé le passage par 
> certains fichiers dérivés (précompilés) mais la logique des évolutions sur 
> Llia_Phon nous conduit à faire un peu plus pour les fichiers de données 
> statistiques. Comme tous ces fichiers de données doivent être conçus comme 
> variables au cours du temps (ajout/retrait d'entrées dans les lexiques, de 
> règles dans les catalogues, modification des données statistiques), il vaut 
> mieux spécifier une bonne fois le contenu de ces fichiers, les liens qu'ils ont 
> entre eux (lexiques et données statistiques) ainsi que les opérations de 
> pré-compilation indispensables si une modification doit être faite.
> 
> Même si la structure superficielle des fichiers n'est pas la même pour FranFest 
> et pour Llia_Phon, ce travail de spécification est identique dans les 2 cas.
> 
> Ca donne en gros, et dans cet ordre :
> 
> 1/ Blocage des évolutions sur la version courante de Llia_Phon, ce qui ne 
> signifie pas qu'il n'y a plus rien à y faire, j'en parle plus bas.
> 
> 2/ Création d'une nouvelle version de FranFest. Ce qui nécessite de voir de plus 
> près comment la version courante a été intégrée dans Oralux par Pierre Lorenzon.

Précision : P. Lorenzon travaille sur EFM qui est un patch d'Emacspeak
pour FranFest ... ensuite repris par la distribution Oralux de Gilles
Casse.
Il semble d'ailleurs qu'il y ait actuellement un problème d'accès à
l'hébergement d'EFM.
Au fait, Roger, as-tu installé le lexique français complet de FranFest
chez TuxFamily ???

> 
> 3/ Création d'une nouvelle version de Llia_Phon. Outre la redéfinition des 
> fichiers de données, il faudrait peut-être aussi étudier de plus près la 
> possibilité de passer à une structuration client/serveur.
> 
> En ce qui concerne le point 1/ il y a, à mon sens, 2 choses à faire avant de 
> considérer la version courante comme intéressante à "porter" sous Windows ou 
> Apple ou Sun ou ...
> 
> a/ Fournir une autre prosodie et donner à l'utilisateur la possibilité de les 
> paramétrer (j'ai vu la vitesse que Nath et David estiment raisonnable alors 
> qu'elle n'est pas modifiable dans la version courante). On n'aura pas une 
> prosodie satisfaisante avant un bout de temps si un linguiste (prosodiste de 
> surcroit) ne nous rejoint pas, mais on peut faire mieux que ce qu'on a. 
>    Je vise fin janvier au plus tard sur ce point.

La vitesse d'élocution et la hauteur de la voix Mbrola sont réglables a
posteriori après génération du fichier phonétisé par LLiaPhon.
Il suffit de placer un en-tête :
;; F= (pour modifier la fréquence/pitch)
;; T= (pour la vitesse/time)

ParleMax ou un autre serveur vocal sauront faire cela.

> 
> b/ Faire la chasse aux sources d'erreurs dans le code. Il y en a au moins 3 qui 
> vont demander un certain travail, vous allez sans doute en trouver d'autres.
> 
> */ Eliminer tous les appels aux fonctions de gestion des chaines ascii qui   
> ignorent les lettres accentuées (isupper, tolower, ...). Remplacer par les 
> fonctions fr_ introduites récemment dans util.c
> 
> */ Eliminer toutes les lectures de fichier qui présupposent une organisation 
> binaire particulière en mémoire (suite à la remarque de Franz à l'Oxford). Après 
> enquête, il en reste pas mal dans l'étiquetage grammatical.
> 
> */ Eliminer tous les risques de débordements de tableau et de pointeurs non 
> définis. Ca, c'est un gros boulot, il y a des réservations à la louche un peu 
> partout dans le code et il y a déjà eu au moins un bug de débordement corrigé de 
> façon complétement supercielle.
>    Pour l'instant, je vise aussi fin janvier sur ce point (avec l'aide de Phil   
>    évidemment).

C'est noté pour moi. Mais ne soyons pas restrictifs. Des nouveaux
peuvent entrer dans le sujet en chassant les (quelques) bugs.

Merci, Roger, d'avoir inventorié ces perspectives.

A+
-- 
Phil