(Courriels de diversion: <faitout@garde-cotes-crochetent.com> <disputeront@blasonner-hissais.com> <obstines@commemorerez-abrutissions.com> <discuterent@tantieme-remilitariser.com> <decapitez@abat-degrisaient.com> <epanouissiez@vilipenderont-releguerent.com> <parades@efforciez-deflation.com> <banniraient@agressais-tricoterai.com> <lenifiantes@frigidite-immortel.com> <marmonneront@radiographiee-reflechissiez.com> )


Guilhem BONNEFILLE wrote:

>> Il me semble suite à ce petit travail qu'il serait assez urgent de
> 
> Quelle "urgence" ? LLiaPhon fonctionne, on a décidé de lui trouver un
> nouveau compagnon à la place de mbrola, ce qui a été jugé prioritaire
> par l'équipe. Pourquoi vouloir faire encore autre chose ?

L'urgence c'est mon opinion. Si je suis seul à penser çà il n'y a aucun
problème. Je mets mon mouchoir dessus et je pass à autre chose.

>> modifier le projet en:
>> - lliaphon : création d'une lib
>> - outils et exemples d'utilisation/intégration
> 
> Pfiou... de l'intégration... des outils... mouais...
> En fait, je comptais intervenir dans LLiaPhon en suivant le planning
> suivant :
> - intégration d'une nouvelle sortie
>   Semble assez urgent. Devrait nous permettre d'amorcer l'indépendance
> de mbrola.

En fait tu es d'accord avec moi?
libllia me parait utile autant en traitement amont (transformation d'un
texte d'un format quelconque, genre SSML ou mail ou HTTP ou... en en texte
format standard pour LLiaPhon) ou aval (synthése, player).

>> Et, éventuellement, de refaire un "toilettage" du code (il y a encore
>> des fonctions issues de la phase de développement).
> 
> C'est vrai, on peut recoder en C++ ou objective-c ? ;-)

Pour moi je préfère qu'on reste en C mais si on décide un autre langage
j'essaierai de m'adapter. Mais pour le toilettage je persiste.

>> Qui s'y colle?
> 
> Comme je l'ai dit plus haut, vous pouvez me compter dans les ressources
> affectées à ce genre de tâches.

OK

>> Avez-vous exploré un peu libralux pour voir la
>> structuration que j'ai faite (qui peut certainement être améliorée).
> 
> Comme je l'ai dit, pour ma part je comptais m'y pencher lors de la
> réflexion autour de l'intégration de SSML. Étudier les besoins pour SSML
> me semble indispensable pour définir les points d'entrée de la
> bibliothèque.
> 

re-OK

A+

-- 
FaVdB