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

Dev News Friday, Jun 30th, 2006 at 05:13pm
Projet PDFToMusic, Útape 18
Aujourd'hui, nous avons rencontrÚ un nouveau type de document. Les diffÚrentes lignes (ligne de portÚe, barre de mesure) sont dessinÚes Ó l'aide d'images. Le problŔme a ÚtÚ partiellement rÚsolu mais la conversion va nÚcessiter de nouveaux algorithmes de discrimination.
Les paroles sont maintenant correctement extraites et associÚes aux notes, mŕme s'il y a plusieurs lignes de paroles. De plus en plus de fichiers se chargent presque sans erreur.
 
Olivier travaille sur l'importation MusicXML des coulÚs, liÚs et accroches.
 
Nous commenšons Ó rÚflÚchir Ó ce que pourrait donner l'interface. Nous la voudrions simplissime. Du genre, une fenŕtre pour reprÚsenter le document avec en haut un nombre limitÚ d'ic˘nes. Nous pensons revenir au principe que nous avions utilisÚ pour la version 1.0 d'Harmony. Plut˘t qu'une palette flottante, les ic˘nes seraient directement affichÚes dans la fenŕtre du document, c'est plus gourmand en place Úcran, mais c'est la mode... Ce que j'aime bien personnellement, en tant qu'utilisateur, c'est de pouvoir dÚfinir les ic˘nes prÚsente parmi une liste de fonctionnalitÚs iconisÚes.  
A priori, il faudrait, pour la navigation, "Plus une page", "Moins une page",  "Augmenter/diminuer l''Úchelle". Peut-ŕtre "Aller Ó la page" avec une valeur numÚrique.
Pour le jeu : "Lancer", "Pause", "Changer le tempo" . Peut- ŕtre, la possibilitÚ de jouer un mÚtronome, mais ce n'est pas sűr.
Additionnellement, peut-ŕtre une ic˘ne pour exporter le document Ó moins que cela ne soit simplement une option de menu. Les formats d'exportation seraient MusicXML, peut-ŕtre MIDI et les pages sous forme de fichiers BMP.
by Didier Guillion
 3 comments.

Dev News Thursday, Jun 29th, 2006 at 05:10pm
Projet PDFToMusic, Útape 17

Nous bataillons avec l'Úquipe du MusicXML pour savoir comment exporter la position graphique prÚcise des objets afin d'avoir un rendu Ó l'Úcran identique dans les diverses applications. Ce n'est pas une mince affaire car c'est loin d'ŕtre normalisÚ. C'est assez frustrant de connaţtre au quart de pixel prŔs la position d'un objet dans la mesure et ne pouvoir ŕtre sűr du rÚsultat obtenu, ceci variant selon le logiciel. Nos prÚoccupations ont cependant ÚtÚ entendues, et la version en cours de dÚveloppement du MusicXML 1.2 devrait, en thÚorie, clarifier la situation.
Le principal travail de la journÚe a ÚtÚ de discriminer parmi les textes affichÚs sur la page, ce qui est un accord, une parole, un texte libre, un nom de portÚe, etc. Pour cela nous avons travaillÚ Ó partir de l'exemple de Sylvain M***,"Dimna Juda" de l'Útape 11. Un casse-tŕte trŔs intÚressant... AprŔs moultes dÚboires cela commence a fonctionner. L'export MusicXML a ÚtÚ complÚtÚ afin de gÚrer les accords extraits.
by Didier Guillion

Dev News Wednesday, Jun 28th, 2006 at 04:58pm
Projet PDFToMusic, Útape 16

La premiŔre version de l'importeur MusicXML, Úcrite en C par Olivier, a ÚtÚ intÚgrÚe au projet. Elle est considÚrablement plus rapide que la version MyrScript ! Le projet PDFToMusic a ÚtÚ liÚ avec la librairie Harmony de jeu de musique et des premiers fichiers simples ont ÚtÚ convertis depuis le PDF et jouÚs.
La question qui se pose est maintenant de faire un lien entre le PDF affichÚ et la position temporelle de jeu afin d'afficher la position courante par une barre verticale.
Ce sera l'objet d'une Útude ultÚrieure.
Pour l'instant nous testons nos algorithmes de reconnaissance de caractŔre et d'export MusicXML sur des fichiers PDF d'origine diffÚrentes. Cela montre qu'il reste ÚnormÚment de travail Ó faire...
by Didier Guillion

Dev News Tuesday, Jun 27th, 2006 at 04:52pm
Projet PDFToMusic, Útape 15

L'extraction de donnÚes depuis un PDF donne une quantitÚ d'informations terriblement prÚcises sur les symboles et leur positionnement. Notre but est d'exporter un maximum de ces informations dans le fichier MusicXML rÚsultat. Ceci a mis en exergue des lacunes importantes de l'import MusicXML d'Harmony Assistant. En fait, cet importeur est le premier d'une longue sÚrie d'importeurs qui se sont succÚdÚs : Encore, Finale, Tabledit, GuitarPro, etc. et en tant que pionnier il souffre de lourdeurs et de problŔmes de conception assez pÚnalisants. Olivier va donc repartir de zÚro et rÚÚcrire un importeur MusicXML, en C, qui sera la pierre d'achopement des Úchanges entre nos applications mais Úgalement entre nos applications et les applications extÚrieures.  
A terme, cet importeur sera vraisemblablement Úgalement disponible dans Melody Assistant et sera une composante du MMPlug-in qui pourra alors gÚrer les fichier MusicXML
by Didier Guillion

Dev News Monday, Jun 26th, 2006 at 05:18pm
Projet PDFToMusic, Útape 14

Dans l'Útape actuelle, nous travaillons sur la comprÚhension des symboles afin de recrÚer une partition valide. Les questions qui se posent sont trŔs proches de celles que nous avons dÚjÓ rencontrÚes lors de la conception d'OMeR en 1999. L'approche est par contre totalement diffÚrente. Par exemple plut˘t que d'adapter les durÚes de symboles Ó la mÚtrique, nous allons faire le contraire. En reconnaissance de partition musicale, une simple erreur entre une barre d'accroche simple ou double par exemple (et c'est graphiquement trŔs semblable) a de forte rÚpercution sur la durÚe des notes et donc sur toute la structuration de la partition Ó partir de cette position. Les algorithmes utilisÚs devraient ŕtre beaucoup plus souples et limiter les Úventuelles erreurs Ó la mesure.
by Didier Guillion

Dev News Thursday, Jun 22nd, 2006 at 05:10pm
Projet PDFToMusic, Útape 13

Une fois le document PDF analysÚ et affichÚ, nous voudrions que l'utilisateur puisse le jouer... Or, et c'est lÓ le problŔme, il n'y a strictement aucune information sur l'instrument dans un document PDF. Souvent, le nom de la portÚe est prÚsente, et quand on voit "Guitare" on doit ŕtre capable de savoir quoi faire... Mais ce n'est pas toujours le cas.
Olivier Ó donc dÚmarrÚ l'Úcriture d'un module qui, Ó partir des informations prÚsentes dans un document, essaie de dÚterminer quel instrument associer Ó chaque portÚe.
Les critŔres sont, entre autre, la clef, la tonalitÚ, la prÚsence ou non d'accords, la tessiture, les groupes de portÚes dÚfinis...  
Nous prÚvoyons d'intÚgrer Virtual Singer dans PDFtoMusic, ce qui permettrait de chanter Úgalement les paroles.
 
by Didier Guillion
 1 comment.

Dev News Wednesday, Jun 21st, 2006 at 04:25pm
Projet PDFToMusic, Útape 12

Il apparait maintenant de maniŔre de plus en plus Úvidente que le MusicXML va ŕtre le format d'Úchange entre PDFToMusic et les autres programmes.
Il va donc nous falloir Úcrire un importeur Music XML en C afin de pouvoir charger les fichiers obtenus avec Melody Assistant.
Ceci implique qu'il serait donc possible d'intÚgrer cet importeur au Myriad Music Plug-In et donc d'utiliser le MMPlug-in pour afficher et jouer des fichiers Music XML sur le web.
Bien sur, les fichiers devront ŕtre compactÚs car le Music XML est trŔs verbeux. La question a ÚtÚ posÚe Ó M. Good, qui gŔre le projet Music XML, de savoir si un standard de compactage a ÚtÚ dÚfini. Ceci a apparemment mis en chantier la version 1.2 du Music XML qui devrait proposer cette fonctionnalitÚ.
Pour exemple, un fichier Music XML de 100Ko est rÚduit Ó 4Ko une fois ZippÚ.
 
Note: C'est avec plaisir que nous recevons vos suggestions sur ce projet, mais envoyez-nous plut˘t un email, cela facilitera les Úchanges...
by Didier Guillion
 3 comments.

Dev News Monday, Jun 19th, 2006 at 05:02pm
Projet PDFToMusic, Útape 11
Les diffÚrents objets prÚsents dans une partition sont isolÚs et classÚs selon leur catÚgorie : clefs, notes, silences, barres de mesures,etc. La position sur la page de ces diffÚrents objets va nous permettre de crÚer un "squelette" de la page : ensemble d'aire de portÚes divisÚes en aires de mesures.  Le type de clef, et la tonalitÚ associÚe Ó chaque mesure semble correctement interprÚtÚ.
Les objets plus ÚlÚmentaires (notes, silences) sont associÚs aux mesures selon leur position. Il est nÚcessaire de mettre en place une analyse des "ledgers lines" (lignes de repÚrage) pour pouvoir trouver la portÚe lorsque le symbole est situÚ en dehors de l'aire des lignes de la portÚe. Ensuite, il va falloir associer Ó chaque symbole ses attributs : altÚration, paroles associÚes, ornements, etc. Les paroles posent un problŔme car il est difficile de savoir si un texte en pied de page fait partie du pied de page ou de parole associÚs Ó la derniŔre portÚe de la page.  
DŔs qu'une nouvelle Útape de la reconnaissance est validÚe, l'export MusicXML correspondant est Úcrit afin de pouvoir comparer visuellement le rÚsultat.
La partie analyse de document qui fonctionnait sur Macintosh depuis le dÚbut Ó ÚtÚ transfÚrÚe sur Windows et compilÚe. Une fois de plus Acam nous Ó fait gagner un temps considÚrable de portage.
by Didier Guillion
 1 comment.

Dev News Thursday, Jun 15th, 2006 at 04:59pm
Projet PDFToMusic, Útape 10

Plusieurs fichiers PDF, encodant les caractŔres sous forme d'images bitmap sans indication de dÚbut et de fin de symbole ont ÚtÚ localisÚs. Une catÚgorie a donc ÚtÚ crÚÚe pour les regrouper, ce sera la catÚgorie 3.
Nous avons donc actuellement 4 catÚgories, divisÚes en sous-catÚgories :
La catÚgorie 0 (zÚro) : Ce sont les PDF n'incluant qu'une seule image non vectorielle de la partition par page du document. Non utilisable.
La catÚgorie 1 : Les symboles musicaux sont dÚlimitÚs et dessinÚs Ó partir d'une police de caractŔre. á
La catÚgorie 2 : Les symboles musicaux sont dÚlimitÚs et dessinÚs Ó l'aide de tracÚs vectoriels (catÚgorie 2.1) ou d'images bitmap (catÚgorie 2.2).  
La catÚgorie 3 : Les symboles musicaux ne sont pas dÚlimitÚs et dessinÚs avec des images non vectorielles (catÚgorie 3.2). On peut supposer que la catÚgorie 3.1 existe (symboles musicaux vectoriels non dÚlimitÚs) mais elle n'a pas ÚtÚ rencontrÚe pour l'instant. Son traitement serait des plus dÚlicat...
 
Les catÚgories 1, 2 et 3 convergent vers le module de reconnaissance de caractŔre mis au point par Olivier qui a ÚtÚ connectÚ Ó l'ensemble et donne des rÚsultats probants.
La base de donnÚe des tracÚs est alimentÚe avec l'ensemble des donnÚes extraites des catÚgorie 1 et 2. J'hÚsite encore Ó gÚnÚraliser ceci Ó la catÚgorie 3 car ceci risque de faire "enfler" la base de maniŔre drastique.
Le module de reconnaissance arrive Ó sÚparer les coulÚs et liÚs des autre symboles, eux aussi n'alimentent pas la base de donnÚe.
 
Lors de l'analyse des PDF en notre possession, un cas particulier de la catÚgorie 1 a ÚtÚ rencontrÚ. Certains fichiers ne codent pas les lignes des portÚes avec des commandes PDF (ligne, ou rectangle) mais utilisent un caractŔre particulier d'une fonte embarquÚe reprÚsentant 5 lignes horizontales sur quelques pixels. Ce cas devra ŕtre traitÚ.
by Didier Guillion
 1 comment.

Dev News Tuesday, Jun 13th, 2006 at 05:13pm
Projet PDFToMusic, Útape 9

Les caractŔres musicaux sont maintenant isolÚs depuis le document PDF original. Une collection des diffÚrents tracÚ des glyphes est mÚmorisÚe sous la forme d'un fichier de donnÚe.  
Lorsque l'on rencontre un caractŔre, on le recherche dans la base de donnÚe, et s'il n'y est pas on le rajoute. Pour l'instant la relation entre le glyphe et sa signification (par exemple tŕte de noire, ronde,etc) se fait "Ó la main". TrŔs bient˘t cette tache sera confiÚe au module de reconnaissance de caractŔres dÚveloppÚ par Olivier.
L'analyse de la page dÚtermine les ensembles de portÚes (systŔmes), puis les aires des lignes de portÚes dans le systŔme, puis les aires des mesures dans ces lignes, enfin, chaque caractŔre musical reconnu est collectÚ dans la mesure le contenant. Pour contr˘ler si ceci est correct, il faudrait redessiner ce que nous comprenons sur l'image de la page. Mais cela demanderait de rÚÚcrire quasiment un affichage complet de tous les symboles et nous ne sommes pas sur que cela servira dans la version finale. Nous prÚfÚrons donc Úcrire (en fait rÚÚcrire puisque cela existe dÚjÓ en MyrScript) un exporteur au format MusicXML. Le format MusicXML a d'ailleurs de forte chance d'ŕtre un des formats d'exportation prioritaire de PDFToMusic. La procÚdure de validation est donc plus simple : crÚer un document avec Harmony, l'imprimer en PDF, le traiter avec PDFToMusic, recharger le MusicXML obtenu et contr˘ler les diffÚrences.
Des premiers essais sont menÚs sur des partitions simples.
 
Voici le document original crÚÚ avec Harmony puis exportÚ en PDF.

 
Le PDF est chargÚ par PDFToMusic et exportÚ en MusicXML.
 
Le fichier MusicXML gÚnÚrÚ par PDFToMusic est chargÚ avec un autre logiciel :

Toute la chaţne de traitement est maintenant en place, mais il reste une part Únorme de travail : comprendre et convertir le maximum des informations que l'on peut trouver dans dans une partition.
by Didier Guillion

Dev News Thursday, Jun 8th, 2006 at 04:51pm
Projet PDFToMusic, Útape 8

Un tracÚ des caractŔres en courbe de BÚzier a ÚtÚ implÚmentÚ, cela nous permet de faire avancer de maniŔre drastique le visualiseur de document PDF.
D'autant plus que l'encodage des diffÚrents types de polices a ÚtÚ uniformisÚ et que tous les tracÚs convergent maintenant vers ce module unique.
Voici par exemple un fragment de partition, visualisÚ Ó l'aide du logiciel "Aperšu" qui utilise les fonctions de Mac OS X:

Et le mŔme fragment, affichÚ Ó l'aide de notre visualiseur.

Le rÚsultat nous semble encourageant...
by Didier Guillion
 2 comments.

Dev News Wednesday, Jun 7th, 2006 at 04:54pm
Projet PDFToMusic, Útape 7

Il nous faut mettre en place une rŔgle de dÚcision qui dÚtermine si une police est musicale ou non, avant d'invoquer la reconnaissance de caractŔre. Pour ce faire, on utilise la statistique de rÚpartition des caractŔres sur la page.
A partir d'une collection des lignes prÚsentes sur la page, les aires des portÚes sont extraites, ainsi que les aires des systŔmes, puis les aires des mesures sont calculÚes.
L'algorithme de raboutage de caractŔres en mot a ÚtÚ Úcrit, on obtient donc une liste de mots associÚe Ó chaque page. Apparemment, le PDF fonctionne en Unicode pour l'encodage des caractŔres, cela tombe bien, Harmony Assistant est Unicode depuis peu...
 
Nous allons fournir ici trŔs bient˘t les premiers rÚsultats prÚliminaires.
by Didier Guillion

Dev News Monday, Jun 5th, 2006 at 08:32am
Projet PDFToMusic, Útape 6

Le travail sur ce projet a dÚbutÚ depuis trois semaines. Nous attaquons maintenant le problŔme posÚ par ce que nous avions appelÚ prÚcÚdemment la catÚgorie 2. Dans cette catÚgorie, les textes sont dessinÚes en utilisant des commandes PDF sans aucune rÚfÚrence Ó une police ou indication de dÚbut et de fin de caractŔre, contrairement Ó la catÚgorie 1. áL'extraction des caractŔres en est difficile mais nous construisons un algorithme de dÚcomposition de chemin PDF qui donne de bons rÚsultats. LÓ aussi, tous les tracÚs sont convertis dans notre ensemble de commande de tracÚs communs.
En l'Útat, nous traitons 99% des documents musicaux PDF en notre possession, mais de nouveaux cas particuliers peuvent encore survenir...
La prochaine Útape sera de rendre tout ceci plus propre (pas mal de sources ont ÚtÚ Úcrits/rÚÚcrits plusieurs fois et sont un peu de guingois) et de le valider sur un maximum de fichiers PDF.
Comme nous avons choisi d'extraire les caractŔres un par un, il va falloir rÚflÚchir Ó un module qui raboute (concatŔne) les caractŔres isolÚs en mots, (voire phrases) associÚs Ó une position prÚcise sur la page.
 
Plusieurs personnes nous ont Úcrit pour nous soutenir dans ce projet PDFToMusic et nous les remercions de leurs avis et conseils. Dans notre esprit, nous essayons de converger vers une gÚnÚralisation de la reconnaissance de caractŔres musicaux et de crÚation de structure de partition. Cette "couche", qui recevrait des symboles bruts non reconnus et en produirait du MusicXML, MIDI, document Melody/Harmony ou autre, pourrait ŕtre alimentÚe soit Ó partir de l'extraction depuis des documents PDF, soit Ó partir d'images scannÚes.  
Si cela pouvait fonctionner, cela aboutirait Ó un programme d'OCR entiŔrement nouveau. Un genre de Super-OMeR...
by Didier Guillion

Dev News Thursday, Jun 1st, 2006 at 04:32pm
Projet PDFToMusic, Útape 5

Les polices de type TrueType, Adobe Type 1, Adobe Type 1C,Type 3 et une police dÚrivÚe du TrueType, le Type CiD type 2, ont ÚtÚ uniformisÚes en un ensemble de commandes de tracÚ. Ceci nous permet d'avoir un module de tracÚ commun pour toutes les polices rencontrÚes et ainsi pouvoir comparer plus facilement les glyphes.
Certains fichiers PDF encodent les glyphes des polices, non pas sous forme de tracÚs vectoriels (courbes de BÚzier) mais d'images bitmap monochromes. On peut repÚrer ces fichiers au fait que, lorsque ál'on augmente l'Úchelle de visualisation du PDF, certains caractŔres deviennent crÚnelÚs.
Ceci a ÚtÚ traitÚ et uniformisÚ.
Afin de valider nos extractions, un visualiseur de document PDF est mis en place. Ceci nous permet de contr˘ler "de visu" ce que nous "comprenons" dans un fichier PDF et servira vraisemblablement ultÚrieurement Ó montrer le document chargÚ Ó l'utilisateur.
Lors de l'analyse du document, les glyphes sont isolÚs et tracÚs dans une image en niveau de gris. Cette image est donc prŕte Ó s'interfacer avec le module de reconnaissance de caractŔre en cours de mise au point par Olivier.  
La plupart des fichiers PDF avec police se chargent plut˘t bien, nous allons maintenant nous plonger sur la catÚgorie 2 : fichiers PDF sans police de caractŔre incluse.
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