Myriad Blog 1.3.0 Monday, Jan 26th, 2015 at 05:34am 

Dev News Thursday, May 4th, 2006 at 02:35pm
On change ?
Les changes de document musicaux ont toujours t une de nos proccupations. Chaque logiciel de musique utilise son propre format de fichier, et il est difficile de partager des documents quand on travaille sur des logiciels diffrents.  
En gnral, le format le plus reconnu est le MIDI. Mais, c'est un format maintenant ancien, que l'on peut qualifier de spartiate et plus destin aux synthtiseurs qu'aux ordinateurs. Par exemple, le format MIDI ne comporte aucune information de mise en page et l'on se retrouve vite limit car un export puis un import ne redonne pas le mme aspect de la partition.
 
Grce MyrScript, le langage intgr Harmony Assistant, il est possible d'importer des documents musicaux provenant de toutes sortes de logiciels : Finale, Noteworthy, Encore, GuitarPro, Tabledit, etc. Depuis deux ans, une bonne partie de notre temps a t passe crire des scripts d'importation, mais il y a tellement de logiciels diffrents que je ne pense pas que nous en verrons un jour la fin. Il faut en effet, pour chaque logiciel, concevoir un script spcifique, parfois mme avec des variantes car les formats ont volus dans le temps.
 
Nous rflchissons depuis quelque temps une autre approche du problme. L'idal serait d'avoir un format de fichier qui soit commun tous les logiciels. Il y a bien l'initiative trs intressante du MusicXML mais cela suppose qu'un exporteur MusicXML existe pour le logiciel. Or, trs souvent, les nouveaux utilisateurs de Melody/Harmony utilisaient un programme dont le dveloppement a t arrt, et voudraient bien rcuprer les partitions cres avec celui-ci. Ils se retrouvent bloqus.
 
C'est alors que nous est venue une ide. Un format d'change existe : c'est le PDF. Que ce soit sur Mac OS X, o l'exportateur en PDF est intgr au systme, sur Mac OS 9 o des pseudo pilotes d'impression existent, ou sur Windows avec des programmes gratuits comme PDFCreator, il est ais de crer un document PDF partir de n'importe quel logiciel. De plus on trouve une grande quantit de partitions en PDF sur l'Internet notamment sur Choral Public Domain Library.
 
Si l'on pouvait lire ces fichiers PDF avec Harmony/Melody nous disposerions alors d'un format d'importation universel. La description du format a t publie par son crateur, Adobe. Une pr-tude a t lance cette semaine pour voir si ce format est lisible et si l'on peut faire quelque chose de ces donnes.
Ds que la nouvelle version d'Harmony et de Melody sera publie (normalement Mardi prochain 9 Mai) nous approfondirons la question.
by Didier Guillion
 1 comment.

Dev News Sunday, May 7th, 2006 at 10:35am
Les mystres du "crash.log"
Si vous tes utilisateurs de nos produits sur PC, vous avez peut-tre eu la malchance de voir apparatre un jour, avant que le programme ne se ferme inopinment, une petite bote d'alerte vous demandant de nous renvoyer un fichier appel "crash.log".
De quoi s'agit-il exactement, et quels renseignements peut-il nous apporter?
Je vais tenter d'y rpondre, sans trop entrer dans les dtails techniques.
 
Le microprocesseur de votre ordinateur, lorsqu'il est en train d'excuter une application, utilise, pour stocker les valeurs intermdiaires de ses oprations, une srie de mmoires internes appeles "registres".
Il sait tout moment, grce ces registres, quel endroit il est dans le programme (donc quelle sera la prochaine instruction effectuer), quelles sont les zones de mmoire auxquelles il va accder, en un mot tout ce qui dfinit son tat un instant donn.
 
Lorsqu'une erreur survient (division par zro, tentative d'excuter une instruction inconnue pour ce microprocesseur, tentative de lire ou d'crire dans une zone de mmoire non valide), le programme s'arrte et gnre une "exception".
Ces exceptions, donc la plus connue est numrote "C0000005" (justement, lecture ou criture dans une zone de mmoire non valide) sont traites par dfaut par Windows, et provoquent l'apparition d'une bote disant qu'un problme a t rencontr, et qu'un rapport d'erreur peut tre envoy Microsoft.
 
Aux dernires nouvelles, ces rapports d'erreur, leur arrive chez Bill, s'ils ne concernent pas des produits Microsoft (et mme!), sont envoys directement dans un dossier spcial, appel poubelle, corbeille, ou classement vertical selon les jours. Ils ne sont donc d'aucun intrt pour nous, ni pour personne d'autre, d'ailleurs.
 
Dans nos produits, nous avons donc remplac ce traitement inutile par la gnration d'un fichier "crash.log", qui contient tous les renseignements nous permettant de savoir ce qui s'est pass:
 
- Nom et version de l'application
- Date de cration de l'application
- Version de Windows de l'utilisateur
- Date et heure du crash (GMT)
- Type d'erreur rencontre
- Liste des registres du microprocesseur
- Instructions en cours d'excution lors du crash
- Et enfin, contenu de la "pile", zone mmoire permettant de connatre le sous-programme ayant appel la fonction en cause, ainsi que le sous-programme ayant appel ce sous-programme, etc.
 
A partir de cela, nous pouvons gnralement savoir:
- l'application ayant subi le crash, ainsi que sa version,
- la version de Windows,  
- approximativement quelle tait l'opration effectue lorsque le crash est survenu (mais pas toujours).
 
En aucun cas nous ne pouvons connatre le dtail de ce que faisait l'utilisateur ce moment-l, sur quel fichier il travaillait, ce qu'il voyait l'cran, quelle tte il a fait en voyant apparatre la fentre d'erreur (quoique, s'il avait sa webcam branche...), donc une explication, mme succinte, des conditions dans lesquelles cela s'est produit, le fichier en cause, bref tout ce qui nous permet de reproduire le problme chez nous, est absolument indispensable.
 
Ds que nous pouvons reproduire une erreur volont, 99% (ou mme plus) du travail est dj fait, et c'est donc l'assurance d'une correction rapide.  
Alors, en pensant nous, vous pensez aussi vous...
by Olivier Guillion

Dev News Wednesday, May 17th, 2006 at 05:05pm
Projet PDFToMusic, tape 1.
L'tude du PDF a dbut (voir le billet "On change ?"), une premire bauche du parseur (analyseur ou butineur qui balaye un fichier pour en extraire les informations) a t crite et l'on commence extraire les diffrents lments des fichiers PDF. Il apparat que, du point de vue de l'utilisation que nous voulons en faire, trois catgories de documents se dgagent.  
La catgorie 0 (zro): Ce sont les PDF n'incluant qu'une seule image de la partition par page du document. Ils ont vraisemblablement t gnres directement depuis un scanner. La seule chose que l'on pourrait faire de ces documents serait d'exporter les images de manire spare et de les faire traiter par OMeR.
La catgorie 1 : Ce sont les PDF, incluant des objets graphiques (lignes, rectangles, etc), et les objets musicaux (tte de note, nuance, etc) dessins partir d'une police de caractre. Ce sont des fichiers issus de l'exportation directe depuis un logiciel de musique, comme ce que l'on obtient depuis Harmony Assistant par exemple. L'interprtation des objets semble possible. Le problme est que la police incluse dans le document PDF est "remapp" (seuls les caractres utiliss dans le document sont prsents) et ne semble pas utilisable directement.
La catgorie 2 : Ce sont les PDF n'incluant que des objets graphiques : les objets musicaux sont dessins avec des primitives graphiques simples et non avec des polices. Je n'ai aucune ide de la faon dont ces fichiers ont t gnrs. Il va falloir isoler ces objets et construire un systme expert de reconnaissance de forme ? Probablement.
 
La catgorie 1 semble la plus rpandue. La catgorie 2 vient ensuite nettement moins souvent. La catgorie 0 est trs rare ma connaissance. La pierre d'achoppement de la catgorie 1 va tre l'extraction des donnes brutes des fichiers de polices inclus dans le document et leur analyse. Apparemment, la plupart de ces fichiers sont des polices au format TrueType qui est un format public. Bon point. Cela va tre la prochaine tape de l'analyse : serons-nous capables d'extraire ces donnes et de reconnatre la forme que ces donnes dessinent ?
by Didier Guillion
 3 comments.

Dev News Friday, May 19th, 2006 at 05:08pm
Projet PDFToMusic, tape 2.
Nous sommes dans l'tape qui consiste analyser les polices de caractres prsentes dans un fichier PDF.
Cette tape de l'tude vise extraire les donnes graphiques d'une police au format TrueType. Heureusement, la documentation est disponible. En premire analyse, le format a l'air trs complet et complexe. Mais avons-nous besoin de toutes ces informations ? Nous nous intressons en premier lieu la manire dont les glyphes (rendu graphique d'un caractre d'une police) sont encods. Aprs quelques tatonnements, nous arrivons extraire les donnes des glyphes et tracer les caractres pour vrification. Cette phase est donc valide, mme si nous laissons plusieurs problmes dans l'ombre : rencontrerons-nous des polices non TrueType ? Des polices qui encoderaient les formes en passant par le bytecode TrueType ?
Maintenant que nous avons les donnes qui dfinissent la forme des caractres, il faut associer le caractre mmoris dans le document PDF au numro de glyphe. En effet le format PDF ne stocke pas toute la police mais uniquement les caractres prsents dans le document. Ceci passe par les "Cmaps" du fichier TrueType.  
Quelques recherches sur l'Internet nous font dcouvrir un site prsentant des centaines de partitions au format PDF. Il apparat qu'une bonne proportion de ces fichiers utilisent une police de type "Adobe Type1C". La prochaine tape sera l'analyse de ce format.
by Didier Guillion

Dev News Saturday, May 20th, 2006 at 07:51pm
Du glyphe l'Unicode (1)
Dans le cadre du projet "PDFToMusic" (voir les autres articles), nous avons t amens tudier les divers moyens d'effectuer une reconnaissance simple de caractres. Ceci permettrait, lorsqu'on trouve dans un fichier PDF un caractre dessinant par exemple une cl de sol, de savoir qu'il s'agit bien d'une cl de sol et pas d'autre chose.
 
Dans ce projet, contrairement une vritable reconnaissance de textes scanns, nous avons seulement besoin de diffrencier les caractres individuels au sein d'une fonte, ce qui supprime d'un coup plusieurs problmes inhrents aux reconnaissances optiques conventionnelles :  
 
1- Les caractres sont "propres", c'est--dire que tous les pixels sont leur place, qu'il n'y a pas de possibilit de poussire, ou dfaut de numrisation qui pourraient perturber la reconnaissance
 
2- Les caractres sont isols. On connait exactement la taille et la position du caractre analyser. Impossible d'avoir malencontreusement deux caractres conscutifs confondus avec un seul (notamment avec des paires commes "ff" ou "ft" dont les constituants se touchent graphiquement), ou un caractre coup en morceaux comme par exemple avec les deux points de la cl de fa.
 
Une premire tape, de pr-analyse, consiste voir s'il n'y aurait pas des valeurs et paramtres quantifiables, indiscutables, permettant de se passer d'intelligence artificielle ou de calculs statistiques complexes pour identifier le caractre.
 
Une premire maquette est crite en MyrScript.
 
Le caractre est affich, puis le nombre de pixels "noirs" sur chaque ligne et sur chaque colonne est calcul. Un double histogramme est alors trac, avec des couleurs dpendant du nombre de "trous" dtects lors du balayage de la ligne ou de la colonne.
 
Ensuite, divers traitements sont essays.
 
Le premier combine les histogrammes horizontaux et verticaux afin d'obtenir une "empreinte" du caractre. Nous la calculons avec le mme caractre dans diverses fontes musicales, mais malgr d'assez importantes similitudes, cela ne semble pas tre suffisamment "stable" pour permettre une reconnaissance.
 
Deuxime essai. L'aspect du caractre est analys, et les "directions" des tracs sont extraites. Le graphe obtenu montre en rouge les lignes "plutt verticales", en vert les lignes "plutt horizontales" et en bleu les lignes "plutt diagonales". Une comparaison directe de ces paramtres un jeu-type semble difficile, mais les rsultats sont suffisamment significatifs pour garder ceci dans un coin et ne pas le jeter tout de suite.
 
Troisime essai. Afin de s'abstraire de l'paisseur des traits constituant le caractre, le script tente de le "fildefriser", de rduire tous les traits un seul pixel d'paisseur. Si cela ne permet pas de dterminer ce qu'est le caractre, cela pourrait au moins tre utilis pour simplifier une comparaison ultrieure.
 
Beaucoup des programmes que nous crivons sont seulement des tests destins finir la corbeille. C'est probablement le cas de ce petit outil d'analyse, qui nous a permis d'exprimenter quelques techniques, et d'essayer d'extraire des paramtres quantifiables du graphisme d'un caractre.
 
La reconnaissance du caractre s'avre cependant complexe (nous nous y attendions), et doit probablement passer par des algorithmes de discrimination un peu plus volus qu'une simple srie de comparaisons.  
 
Nous nous penchons donc sur les rseaux de neurones, qui semblent souvent employs dans les programmes d'OCR (Optical Character Recognition)...
by Olivier Guillion
 2 comments.

Dev News Tuesday, May 23rd, 2006 at 04:58pm
Projet PDFToMusic, tape 3.
Nous sommes dans l'tape qui consiste analyser les polices de caractres prsentes dans un fichier PDF.
Le format de police "Adobe Type 1C" (C pour compact) est public. A partir de cette documentation, un extracteur et interprteur de commande graphique a t crit pour pouvoir dessiner grossirement les caractres. En effet, nous avons progress dans la reflexion sur l'association "numro de caractre" vers "signification du caractre". Une solution serait de procder en deux tapes :
1- Rechercher des donnes similaires dans une base de donnes, pour savoir si le caractre dj t rencontr.
2- Si le caractre est nouveau, trac du caractre et reconnaissance automatique de celui-ci. S'il est reconnu, alors nous alimenterons la base de donne utilise en tape 1.
 
La reconnaissance de caractre passera peut-tre par des rseaux neuronaux. Un rseau neuronal a t crit (en MyrScript, c'est un excellent langage pour faire rapidement des maquettes) et donne des rsultats intressants...
 
Entretemps un nouveau type de police est rencontr, le format "Adobe Type 1". La prochaine tape sera l'analyse de ce format.
by Didier Guillion
 2 comments.

Dev News Wednesday, May 24th, 2006 at 04:55pm
Du glyphe l'Unicode (2)
Le cerveau humain, partir des informations visuelles qui lui sont transmises, distingue assez facilement (aprs un petit apprentissage), une cl de sol d'une cl de fa, un "M" d'un "T", etc.
L'ide de simuler le fonctionnement des neurones dans un programme coulait donc de source.  
 
Concrtement, un rseau de neurones "informatique" se prsente en couches, comme un plat de lasagnes:
 
- Une srie de neurones dits "d'entre", chacun d'entre eux recevant une valeur quantifiable dpendant de l'objet analyser. Ce peut tre la luminosit d'un point, mais aussi un rapport largeur/hauteur du caractre,  l'paisseur moyenne de ses traits, en fait tout paramtre pouvant avoir une utilit dans la discrimination.  
 
- Une srie de neurones dits "de sortie", chaque neurone correspondant une valeur possible dterminer. Par exemple, si on veut que le rseau de neurones soit capable de trouver quelle lettre (A-Z) correspond le caractre analys, il faudra 26 neurones de sortie, un par lettre possible
 
- Entre l'entre et la sortie, une ou plusieurs couches de neurones dits "cachs".
 
Chaque neurone de chaque couche est reli chaque neurone de la couche suivante, par une liaison plus ou moins "forte". Au dpart, la force de chacune des liaisons est choisie au hasard, et le rseau est incapable de reconnatre quoi que ce soit.
 
Ensuite, on prsente au rseau des exemples de caractres dterminer. Il essaie (et choue). Il faut alors lui enseigner de quoi il s'agissait. Cet apprentissage affaiblit les liaisons qui ont conduit l'erreur et renforce celles qui favorisent un rsultat correct.
 
Si les valeurs alimentant la couche d'entre sont bien choisies, si le rseau est correctement dimensionn, et si l'apprentissage est bien rgl, le rseau, petit petit, apprend, et au bout de quelques milliers d'exprimentations et d'apprentissages, devient capable de distinguer quelque chose. Aprs 50 100000 apprentissages, il se dbrouille pas mal.
 
Nous avons crit un prototype d'un tel rseau en MyrScript, et l'avons fait travailler sur des exemples de caractres (comme les lettres de A Z crites en diffrentes tailles et diffrentes fontes). Une dizaine de milliers d'apprentissages plus tard, le rseau obtient un taux de fiabilit de 99% sur les exemples qui lui ont dj t fournis, et plus de 90% sur des exemples issus d'autres fontes proches mais pas identiques.
 
Globalement, les rsultats sont donc encourageants. Seul petit bmol : la masse de calculs devient assez consquente. Pour un tout petit rseau de neurones de 3 couches de 26 neurones, il faut effectuer 1352 oprations pour obtenir un rsultat. Si on passe le nombre  de neurones par couche 120, il en faut 28800.
 
MyrScript commence peiner un peu, et nous nous apercevons que le rglage du "taux d'apprentissage" s'avre crucial. Il dtermine si le rseau apprend vite ou lentement de ses erreurs.
Trop vite, et une correction d'une de ses erreurs lui fait "oublier" ses apprentissages prcdents, et trop lentement, il commet inlassablement la mme faute, sans apprendre se corriger.
 
Enfin, si on dsire rduire le nombre de paramtres d'entre pour simplifier le rseau, il faut choisir des critres quantifiables facilement extractibles du dessin du caractre. Quels qu'ils soient, leur choix sera dict seulement par notre propre intuition, et risque de s'avrer moins performant qu'attendu.  
 
Cette mthode fonctionne donc, mais avant de passer l'tape suivante de l'analyse, nous prfrons explorer d'autres voies similaires, bases sur les statistiques de rpartition des pixels dans chaque forme de caractre. Cela permettrait d'allger les calculs et d'obtenir un apprentissage plus rapide qu'avec un rseau neuronal classique...
by Olivier Guillion
 7 comments.

Dev News Tuesday, May 30th, 2006 at 04:50pm
Projet PDFToMusic, tape 4.
Nous sommes toujours dans l'tape qui consiste analyser les polices de caractres prsentes dans un fichier PDF.
Comme le format "Adobe Type 1C", le format "Adobe Type 1" utilise un interprteur PostScript pour dessiner les formes de caractres. La diffrence entre les deux formats est que le "Adobe Type 1C" est compact, le "Adobe Type 1", est au format texte, non compact. Par contre, le format "Adobe Type 1" est encrypt (certaines polices peuvent tre protges). Heureusement, l'algorithme d'encryptage/dcryptage est public. Aprs quelques tatonnements et fausses pistes, le format "Adobe Type 1" est dcod. Nous crivons alors un interprteur PostScript rudimentaire pour tracer les caractres. Le rsultat semble correct et utilisable.  
Maintenant, il va falloir analyser un autre type de police : le type 3, c'est un format o les caractres sont dessins avec des commandes PDF. L'intention gnrale est d'uniformiser tout ceci et de convertir "Type 1", "Type 1C", "Type 3" en un format de description commun et homogne qui permettra un trac plus uniformis.  
Paralllement ceci, Olivier a essay d'autres voies que le rseau neuronal pour la reconnaissance et obtient des rsultats prometteurs...
by Didier Guillion


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Dev News
Technical
Mood
Memories
Myriad Life
To be seen
30 previous days
Apr 2006
May 2006
Jun 2006
Jul 2006
Aug 2006
Sep 2006
Oct 2006
Nov 2006
Dec 2006
Jan 2007
Feb 2007
Mar 2007
Apr 2007
May 2007
Jun 2007
Jul 2007
Aug 2007
Sep 2007
Oct 2007
Nov 2007
Dec 2007
Jan 2008
Feb 2008
Mar 2008
Apr 2008
May 2008
Jun 2008
Jul 2008
Aug 2008
Sep 2008
Oct 2008
Nov 2008
Dec 2008
Jan 2009
Feb 2009
Mar 2009
Apr 2009
May 2009
Jun 2009
Jul 2009
Aug 2009
Sep 2009
Oct 2009
Nov 2009
Dec 2009
Jan 2010
Feb 2010
Mar 2010
Apr 2010
May 2010
Jun 2010
Jul 2010
Aug 2010
Sep 2010
Oct 2010
Nov 2010
Dec 2010
Jan 2011
Feb 2011
Mar 2011
Apr 2011
May 2011
Jun 2011
Jul 2011
Aug 2011
Sep 2011
Oct 2011
Nov 2011
Dec 2011
Jan 2012
Feb 2012
Mar 2012
Apr 2012
May 2012
Jun 2012
Jul 2012
Aug 2012
Sep 2012
Oct 2012
Nov 2012
Dec 2012
Jan 2013
Feb 2013
Mar 2013
Apr 2013
May 2013
Jun 2013
Jul 2013
Aug 2013
Sep 2013
Oct 2013
Nov 2013
Dec 2013
Jan 2014
Feb 2014
Mar 2014
Apr 2014
May 2014
Jun 2014
Jul 2014
Aug 2014
Sep 2014
Oct 2014
Nov 2014
Dec 2014
Jan 2015
Jan 23rd, 2015 at 04:53pm 
Article from Didier Guillion
ACAM sur Mac tape 18
Jan 22nd, 2015 at 04:53pm 
Article from Olivier Guillion
Acam Winter tape 32
Jan 21st, 2015 at 04:54pm 
Article from Didier Guillion
ACAM sur Mac tape 17
Jan 20th, 2015 at 04:58pm 
Article from Olivier Guillion
Acam Winter tape 31
Jan 19th, 2015 at 04:55pm 
Article from Didier Guillion
ACAM sur Mac tape 16
Jan 16th, 2015 at 05:49pm 
Comment from dheo
Keyboard Input
Jan 16th, 2015 at 05:49pm 
Comment from dheo
Keyboard Input
Jan 16th, 2015 at 05:49pm 
Comment from dheo
Keyboard Input
Jan 16th, 2015 at 05:49pm 
Comment from dheo
Keyboard Input
Jan 16th, 2015 at 05:49pm 
Comment from dheo
Keyboard Input

Top of page
Last update:  (c) Myriad