HomeProductsDownloadOrderSupportSearch
  
 
 Myriad Blog 1.3.0 Friday, Mar 15th, 2024 at 06:24am 

Dev News Monday, Oct 2nd, 2006 at 04:48pm
Projet PDFToMusic, étape 71

 
- Les documents présents à la fermeture de PDFToMusic sont rechargés automatiquement au lancement suivant (débrayable dans les préférences)
 
 
- Dans certains cas, PDFToMusic est incapable de comprendre la signification d'un symbole ou a un doute sur ce qu'il a localisé.  
Par exemple, un symbole de coulé a été extrait, PDFToMusic a trouvé le symbole d'origine du coulé mais pas le symbole de destination.
La position précise du problème est matérialisé sur la partition par une icône d'alerte.  
 

 
Lorsque l'utilisateur passe le pointeur de la souris sur l'icône, un phylactère s'ouvre donnant le libellé de l'erreur. La pointe du phylactère indique le positionnement précis.
 

 
A noter qu'il s'agit plus d'erreur à corriger par la suite avec un éditeur musical plus qu'avec PDFToMusic lui-même.  
Afin de permettre à l'utilisateur de localiser rapidement les pages comportants une erreur, une icône de même type s'affiche dans le tiroir.
 
by Didier Guillion

Dev News Tuesday, Oct 3rd, 2006 at 04:55pm
Projet PDFToMusic, étape 72

- Un sous menu "Internet" fais son apparition,avec la possibilité d'envoyer des emails (avec attachement) directement depuis le programme.
 

 
Il ouvre la boîte de dialogue d'envoie de mail, similaire à ce que l'on peut trouver dans Harmony/Melody:
 

 
- Suite à une suggestion de M Belkin, les erreurs localisées lors du traitement sont affichées dans une fenêtre texte :
 

 
Un click sur la fenêtre permet, entre autre, de sauvegarder le texte ou de l'imprimer.
 
by Didier Guillion

Dev News Wednesday, Oct 4th, 2006 at 05:03pm
Projet PDFToMusic, étape 73

 
- L'OMNI (objet musical non identifié) de l'étape 48 fait un retour en force avec une nouvelle variante amusante. Les altérations sont à la fois en dessus et en dessous. Difficile de savoir à quelles notes il doit s'appliquer. Cela a été traité en l'attribuant à la note la plus proche.
 

 
-L'impression du texte de la fenêtre des erreurs a été implémenté.
 
-Le projet a été recompilé sur XCode. Nous allons maintenant tester la différence de performance entre CodeWarrior et GCC (le compilateur de XCode) pour savoir sous quelle forme l'executable va être fourni.
Pour Harmony/Melody les performances d'XCode étaient si désastreuses que deux versions séparées avaient été compilées. La version PPC sous CodeWarrior, la version MacTel sous XCode.
Nous espérons pouvoir fournir un executable unique pour PDFToMusic.
 
by Didier Guillion
 2 comments.

Dev News Thursday, Oct 5th, 2006 at 05:10pm
Projet PDFToMusic, étape 74

 
- La première version pour MacTel (Macintosh à base de processeur Intel) a été compilée et testée.Tout fonctionne correctement. Elle sera donc proposée dès la première béta.
 
- Des chronométrages serrés ont été fait pour départager, en terme de rapidité, la version compilée sous CodeWarrior et la version compilée sous XCode. La différence dans le cas précis de PDFToMusic n'est pas sensible. On peut donc raisonnablement supposer que PDFToMusic sera fourni comme un Universal Binary fonctionnant indifféremment sur PPC et MacTel.
 
 

- A titre expérimental, nous allons essayer de voir si l'on peut traiter les caractères alphanumériques dessinés avec des chemins ou des images, afin de reconstituer titres, pieds de pages, paroles, etc... Cela revient à faire de la reconnaissance de caractères et s'annonce "chaud". Mais, un point important : dans l'optique du projet suivant qui serait le traitement de pages scannées, images bitmap et non plus vectorielles comme dans le PDF, ce module est indispensable.  
Un petit pas à essayer dans la direction d'un "Super-OMeR".
by Didier Guillion
 2 comments.

Dev News Friday, Oct 6th, 2006 at 05:08pm
Projet PDFToMusic, étape 75

-Aujourd'hui, peaufinage de l'algorithme de localisation des notes associées aux tuplets, et plus particulièrement lorsque des ambiguités sont résolues par le compositeur par l'utilisation de crochets.
En fait, toute cette portion de code a été réécrite entièrement et traite maintenant correctement les cas suivants :
 
(machefert);
 
(belkin)
 
(Pedone)
 
 
-Comme on nous la fait justement remarquer, nous sommes en retard pour la Beta qui devait être fournie fin Septembre. Il nous reste deux points importants à finaliser. Tout d'abord, lors du traitement par lot, un crash mémoire survient parfois,et ce, avec une fréquence très faible. Par exemple, en ce moment, le programme tourne  en fond  depuis plus de quatre heures sans erreur. Le problème est que le fichier PDF traité lors du crash, se charge normalement individuellement. Probablement un problème de mémoire mal initialisée.
 
Ensuite, l'import MusicXML prends plus de temps que prévu. Sans vouloir, critiquer basiquement le format MusicXML, car c'est incontestablement un magnifique travail de la part de l'équipe de Recordare, il y a vraiment des choses plutôt bancales dedant. Nous y reviendrons plus tard en détail.
by Didier Guillion

Dev News Monday, Oct 9th, 2006 at 05:05pm
Projet PDFToMusic, étape 76

- Nous avons amorcé, suite à un exemple proposé par Sylvain Machefert, le traitement des portées mono-ligne de notation des percussions.
 

 
Il faut maintenant s'assurer que cela n'interfère pas avec des lignes horizontales d'autre nature, comme, par exemple les lignes soulignant des textes.
 
- Il apparait que sur certains document PDF, le jeu de caractère est incorrectement défini.
Ceci se localise rapidement lorsque, après chargement du document avec Adobe Acrobat, on tente de copier le texte et de le coller sur un traitement de texte : la chaine de caracteres obtenu est incohérente. On peut maintenant, sous PDFToMusic, police par police, définir que la determination des caractères se fera par reconnaissance optique.
 
- Enfin, en complément à l'étape 67 : lorsque l'utilisateur refuse que les corrections apportées au PDF soient sauvegardées dans le fichier PDF lui même, elles sont mémorisées dans un dossier spécifique de ses documents utilisateurs.  
by Didier Guillion

Dev News Tuesday, Oct 10th, 2006 at 05:02pm
Projet PDFToMusic, étape 77

 
- L'import MusicXML gère maintenant les extensions au format associées aux images. (Voir l'étape 51). Nous essayons de normaliser ce type d'objet de manière la plus claire possible, en espérant que cela deviendra un standard pour la prochaine version du MusicXML.
La déclaration d'une image ressemble, pour l'instant à :
<image page="1" default-x="240" default-y="1263" x-size="216" y-size="203" colorbits="8bitgray" source-width="1144" source-height="1073" encoding="base64" packing="none">
ici les données encodées en base64 afin de permettre leur transfert au format texte via l'Internet.
</image>

 
Ce qui défini respectivement :
la page à laquelle associer l'objet,
les positions X et Y par rapport au bas gauche de la page, de début de l'aire de l'objet,  
la taille X et Y de l'objet sur la page,  
le type d'image qui peut être "bitmap", image monochrome, "8bitgray", image 256 niveaux de gris, "24bitcolor" image couleur en 24 bits par composant,  
la taille X et Y de l'image source (pour une meilleure précision, l'image incluse dans le fichier est plus grande que l'image affichée),
le mode d'encodage des données dans le fichier, ici c'est l'encodage en "base64" mais cela pourrait être autre chose...
le mode de compactage des données, ici "none", mais un compactage "RLE" pourrait être utilisé pour réduire de façon conséquente la taille du fichier.
 
- Certains fichiers PDF utilisent des polices de caractères pour afficher des graphismes, comme par exemple des notations pour accordéon (Machefert)

 
Une nouvelle option dans la boîte de configuration des polices permet de spécifier que les caractères de cette police seront exportés dans le fichier MusicXML comme des graphismes.
 

 
Et une fois importé dans Harmony Assistant cela donne :
 
by Didier Guillion
 1 comment.

Dev News Wednesday, Oct 11th, 2006 at 05:12pm
Projet PDFToMusic, étape 78

 
Il peut y avoir une très grande diversité de types de textes associés à un document musical. Pour n'en citer que quelques uns, les texte d'en-tête, textes des paroles, nom des portées, accords, indications diverses ajoutées sur le document, etc.
PDFToMusic met en oeuvre des algorithmes assez complexes pour déterminer le type de texte et créer l'objet MusicXML associé. Bien sur, il peut se tromper.
La possibilité est donc offerte à l'utilisateur de "rectifier" le tir et de corriger par un simple click droit sur l'objet le type du texte.
Par exemple, dans ce fichier, l'auteur a décalé une syllabe de parole ("vi") ce qu'il fait qu'elle n'est pas associée à la ligne de parole et donc plus reconnue comme une parole mais un texte libre.

 
Un click droit ouvre la palette contextuelle de changement de type et corrige le problème.

 
 
Maintenant, il va falloir trouver un système de représentation qui permettra de repérer rapidement les erreurs et de les corriger... Peut être en utilisant des couleurs différentes pour chaque type de texte ?
 
 
by Didier Guillion
 3 comments.

Dev News Thursday, Oct 12th, 2006 at 05:15pm
Projet PDFToMusic, étape 79

 
- Lorsque l'utilisateur demande de visualiser le résultat du calcul les différentes classes de texte sont différenciées par des couleurs ( Recordare) :

 
On peut y voir, les texte libres en bleu, les noms de portée en orange, les noms de groupe en vert clair, les paroles en vert foncé.
 
- Un algorithme simple de discrimination entre coulé et lié a été implementé. Coulés et liés sont exportés dans le document MusicXML.
 
- L'import de graphisme amorcé à l'étape 77 est en phase de finalisation.
Voici un exemple d'une partition PDF originale (Machefert) :
 

 
Et du résultat après chargement sous Harmony Assistant :
 

 
Donc, ca avance, plus lentement que prévu, mais ce qui est fait n'est plus à faire...
by Didier Guillion
 8 comments.

Dev News Friday, Oct 13th, 2006 at 05:09pm
PDFToMusic, étape 80

 
- Dans certains cas, un objet mal reconnu peut perturber non seulement sont propre résultat lors de la reconnaissance, mais également la signification des objets suivants. C'est assez rare, mais a été rencontré sur quelques partitions. Un mécanisme a donc été mis en place pour permettre à l'utilisateur de demander d'ignorer cet objet lors de la reconnaissance.
 

 
Il reste à montrer maintenant qu'un objet a été désactivé, et permettre de le réactiver...
 
- Afin de rapprocher la date de la béta, nous avons fait le tri parmi les fonctionnalités manquantes afin d'établir une liste de tout ce qui est essentiel d'implémenter pour la béta.
Dans l'import MusicXML : les groupes de portées, nom des portées, nom des groupes, les symboles de tempo et pédale, tous les ornements associés aux notes, le sens des coulés, la gestion des tablatures. Eventuellement, la gestion des noms d'accord.
 
Il serait également intéressant d'améliorer la reconnaissance optique des caractères amorcée à l'étape 77. Cela fonctionne plutôt bien mais avec encore des confusions. Par exemple un "c" peut être confondu avec un "e". D'autre part, la reconnaissance est censée fournir la casse (italique,gras...) du caractère, mais ceci n'est pas géré.
 
Enfin, il persiste un problème récurrent de débordement de voix qu'il faut corriger...
by Didier Guillion
 1 comment.

Dev News Monday, Oct 16th, 2006 at 05:04pm
Projet PDFToMusic, étape 81

 
- Lorsqu'un objet est désactivé, un click droit ouvre la palette permettant de réactiver cet objet. La page contenant l'objet est alors recalculée.

 
- L'OMNI de l'étape 48 :

 
 
Est maintenant traité de manière plus élégante : la note est marquée comme altérée mais sans altération visible et un effet de type "accidental-mark" est ajouté à la note. Ceci devrait fournir, via le MusicXML une représentation très proche de l'original.
 
- Les textes libres sont concaténés (raboutés) horizontalement pour former des lignes de mots et verticalement pour créer des paragraphes.
Par exemple, depuis ce fichier PDF (Machefert) :
 

 
On obtient dans Harmony Assistant un seul bloc de texte :
 

 
A noter que la discrimination avec les textes des paroles fonctionne parfaitement.
by Didier Guillion

Dev News Tuesday, Oct 17th, 2006 at 05:10pm
Projet PDFToMusic, étape 82 et autre...

 
- Dans PDFToMusic, un système d'aide contextuelle sous forme de bulles a été implémenté. Lorsque le curseur de la souris reste plus d'une seconde immobile sur un objet, une information apparaît.
 

 
- Le problème de débordement de voix a été mis à l'étude. Il est très certainement lié aux notes en accord mais non alignées verticalement, amorcé à l'étape 38.
 

 
- La société AMI vient de nous livrer notre nouveau PC, un core duo 6600 à 2.4 Ghz. Dans l'immédiat il va nous permettre de valider les algorithmes de PDFToMusic sur l'ensemble des fichiers PDF dont nous disposons. Sur mon "petit" Mac Bipro 1x1.6, la validation des 500 Go de fichiers prend tout de même plus de 14 heures.
Je lorgne avec intérêt sur les Mac Pro à base d'Intel mais une application est toujours manquante, Resedit, développée par Apple, essentielle à nos développements et qui ne fonctionne pas sur ces machines. La solution viendrait peut être de ResKnife, un substitut open-source, mais pour l'instant indisponible.
 
- Nous avons dépassé cette nuit les 2 000 000 (deux millions !) de visiteurs sur le serveur de gestion de commentaires de Galerie. Nous en sommes ravis. Plusieurs fois par semaine des personnes nous remercient de cette application gratuite, certains même insistent pour verser leur écôt. Proposition que nous déclinons bien sûr car c'est un projet collaboratif qui doit rester gratuit. Plus rarement certains trublions nous agressent, voire nous insultent gravement , nous menacent même, quand nos réponses ne leur semblent pas satisfaisantes.  
Nous les ignorons, comme l'on dit par chez nous : "Bien faire et laisser braire."
by Didier Guillion
 2 comments.

Dev News Wednesday, Oct 18th, 2006 at 05:25pm
Projet PDFToMusic, étape 83

 
- L'algorithme de recherche d'altération a été amélioré, il gère beaucoup mieux les cas où l'altération est décalée à cause de notes trop proches en accord.
 

 
Une fois de plus les partitions avec tablatures se sont révélées plus que précieuses : la moindre discordance entre les informations extraites depuis la portée standard et son équivalent en tablature révèle automatiquement une erreur.
 
- Suite à une discussion sur la mailing list du MusicXML, les commandes additionnelles ne seront plus mémorisées à l'intérieur de commentaires mais dans des "processing instructions" du XML.
 
- Lors de la conversion des tablatures, les textes placés en entête, comme 'TAB' ou les indications d'accordage sont ignorés. C'est assez bénin mais donne des documents plus "propres".
by Didier Guillion

Dev News Thursday, Oct 19th, 2006 at 05:23pm
Projet PDFToMusic, étape 84

 
- La distribution des notes sur les différentes voix a été amélioré, surtout en ce qui concerne les notes sans tige (rondes). En effet, le sens de la tige est le principal indice permettant de savoir à quelle voix appartient une note. Lorsqu'il n'y a pas de tige, le programme doit se débrouiller pour "deviner".
 
- La durée des silences qui occupent toute la mesure est maintenant mieux calculée. En effet, ce symbole ne représente pas la même durée selon qu'il est seul dans sa mesure, comme ici:

ou précédé ou suivi par d'autres notes, comme là:

(extraits de la même partition, CPDL)

 
- Enfin nous sommes partis du postulat qu'une portée devait être lisible par elle-même. Or nous sommes tombés sur ce genre de cas:

où le silence après la ronde en 2e portée est sous-entendu. Ce type de cas, très rare, ne sera probablement pas géré.
by Olivier Guillion
 1 comment.

Dev News Friday, Oct 20th, 2006 at 04:37pm
Projet PDFToMusic, étape 85

 
Voici un petit résumé de la manière dont PDFToMusic gère les polices. Ceci pourrait éventuellement constituer un chapitre de la future documentation...
 
PDFToMusic extrait les polices de caractères du document PDF afin de reconstituer le document musical. Lors de la création du document PDF, les polices ne sont pas mémorisées telles quelles dans le fichier mais transformées. Tout d'abord, pour réduire la taille du fichier, seuls les caractères utiles sont inclus. Souvent, le nom même de la police est encodé. De plus, aucune indication n'est fournie qui permettrait de différencier à coup sur une police textuelle d' une police musicale.
 
Dans une première étape, PDFToMusic essaie d'extraire un nom de police cohérent et le recherche dans sa base de donnée des noms de polices connues. Si le nom est trouvé la police est considérée comme "forcée par l'application". Vous ne pouvez pas changer cet état.
 
Si la première étape ne donne pas de résultat, PDFToMusic applique des algorithmes spéciaux pour différencier polices textuelles et polices musicales. Les polices sont alors marquées comme "texte automatique" ou "musicale automatique". Vous pouvez, via le menu "Correction>Polices" modifier le résultat proposé par PDFToMusic, et, par exemple, changer une police textuelle en police musicale.  
 

 
Ce changement peut être limité au document ou appliqué à tous les documents.
 

 
S'il est limité au document, seul ce document sera affecté par le changement.
S'il est appliqué à tous les documents, à chaque fois que le nom de la police sera retrouvé dans un fichier PDF, son état sera forcé. Bien sur, ceci doit être utilisé à bon escient. Vous créez donc votre propre base de donnée des polices rencontrées le plus couramment.  
 
A noter que ces modifications sont mémorisées dans le document PDF et conservées d'un chargement du document à l'autre ou si vous envoyez ce document à un autre utilisateur. Dans ce dernier cas, la base de donnée des noms de polices de l'utilisateur recevant le fichier ne sera pas modifiée.
 
Une fois que les polices ont été définies comme musicales ou textuelles, elles sont traitées en conséquence par PDFToMusic.
 
Les polices musicales sont analysées optiquement, caractère par caractère, pour en extraire leur signification.
 
Pour les polices textuelles, c'est un peu différent. PDFToMusic se base en premier lieu sur les données Unicode du fichier PDF. Dans la plupart des cas, le résultat est cohérent. Cependant, certains fichiers PDF ne fournissent pas des données Unicodes correctes. On s'en rends compte rapidement : les textes affichés sont absolument différent du texte original. Vous pouvez alors demander une reconnaissance optique de ces polices textuelles. La police est alors marquée comme "Texte avec reconnaissance optique" et chaque caractère est analysé.
 
Enfin, certaines polices ne contiennent ni des caractères musicaux, ni des caractères textuels, mais des graphismes. Par exemple, des indications de jeu d'accordéon, des diagrammes d'accord guitare, des logos, etc. L'utilisateur peut dans ce cas, définir que la police est "Graphique".  Les différents caractères seront alors considérés comme des graphismes et exportés en tant que tel dans le fichier résultat.
 
- Très fréquentes dans les fichiers issus de CPDL, les brèves tracées à l'aide d'un symbole de ronde puis ajout de deux petites lignes verticales sont maintenant traitées.
Les fichiers de CPDL, d'une étonnante variété, recèlent une quantité impressionnante de particularités de notation, que nous traitons point par point. Comme par exemple, ce jour, des partitions avec les barres de mesure en pointillé. Je ne sait pas à quoi correspond cette notation peut être pour faire joli ?
 

 
Ce cas est également traité.
by Didier Guillion
 4 comments.

Dev News Monday, Oct 23rd, 2006 at 04:57pm
Projet PDFToMusic, étape 86

 
- Une version simplifiée de Virtual Singer, le chanteur virtuel a été intégrée à PDFToMusic. Les paroles des partitions sont chantées en Anglais, Finlandais, Français, Allemand, Italien, Japonais, Latin, Occitan et Espagnol. La langue étant reconnue automatiquement. L'utilisateur peut désactiver Virtual Singer de manière générale :
 

 
Ou document par document.
A cet effet, une nouvelle icône fait donc naturellement son apparition dans la barre des commandes.
 

 
Pour l'instant nous n'envisageons pas de laisser l'utilisateur paramétrer les voix, comme changer la langue ou choisir une autre voix que la voix d'homme standard.
 
- Lors de l'export par lot avec traitement de l'arborescence, une option permet de récreer la même arborescence pour les fichiers convertis. C'est particulièrement utile quand plusieurs fichiers ont le même nom dans l'arborescence source.
by Didier Guillion

Dev News Tuesday, Oct 24th, 2006 at 05:13pm
Projet PDFToMusic, étape 87

 
- La localisation et affichage des erreurs sur la partition recherche maintenant la cohérence des durées d'une mesure sur l'autre. Dans de nombreux cas cela permet de localiser des erreurs d'écriture sur la partition originale, comme par exemple :
 

 
Qui donne, une fois les résultats affichés

 
Cela est pour nous très utile bien que je ne soit pas persuadé que ce genre d'information puisse intéresser l'utilisateur. Il risque en effet de croire qu'il s'agit d'une erreur inhérente à PDFToMusic ce qui n'est absolument pas le cas. La phase de béta-test permettra de déterminer si ceci sera conservé dans la version finale.
 
- En fonction de la tessiture de la portée, quatre voix Virtual Singer différentes sont utilisées, respectivement pour basse, ténor, alto et soprano.
by Didier Guillion
 2 comments.

Dev News Wednesday, Oct 25th, 2006 at 05:05pm
Projet PDFToMusic, étape 88

 
- L'utilisateur peut choisir la voix Virtual Singer associée à chaque portée.
 

 
-Chaque erreur affichée sur le document peut être désactivée individuellement dans les préférences générales de l'application :
 

 
En effet certains PDF sont écrits de manière vraiment exotiques et peuvent générer une grande quantite d'erreurs inutiles, spécialement l'erreur "Durée de mesure incorrecte". Il faut alors pouvoir les désactiver.
 
-Sinon le principal travail en cours est l'export des différents objets de type texte et leur import dans Harmony Assistant. C'est un travail assez délicat car nous voulons retrouver le positionnement exact des objets sur la partition résultat et le MusicXML est très confu dans ce domaine...  
 
- Déjà l'étape 88. Ouch ! J'espère que nous passerons en béta avant la centième... !!!
by Didier Guillion

Dev News Thursday, Oct 26th, 2006 at 05:26pm
Projet PDFToMusic, étape 89

 
- Les ornements, effets, et autres textes associés au document sont maintenant convenablement traités et ce ne fut pas simple, le MusicXML étant un vrai casse-tête pour tout ce qui est positionnement d'objet. Par exemple, des positions doivent être définies comme "relatives" mais on ne dit pas à quoi, à la mesure ? à la portée ? à la note ? à la position courante ? Nous sommes obligés de procéder par tatonnements, en nous servant du Dolet comme référence. Bien sur, si il y a une erreur dans le Dolet, nous risquons de reproduire la même.
 
Par exemple, voici un fragment de partition PDF originale :
 

 
Après chargement du MusicXML via le Dolet :
 

 
Et le même MusicXML avec l'importeur MusicXML d' Harmony Assistant :
 

 
 
Enfin, voici un exemple de fichier PDF traité (Machefert) et de ce que l'on obtient avec PDFToMusic.
 
http://www.myriad-online.com/images/blog/sample1/sample1.htm
 
C'est loin d'être parfait, mais l'on progresse...
by Didier Guillion

Dev News Friday, Oct 27th, 2006 at 04:46pm
Projet PDFToMusic, étape 90

 
- Lors de l'interprétation d'une portée par Virtual Singer, la langue est determinée via des critères de mots-clefs présents uniquement dans certaines langues, de caractères spécifiques, etc. Bien sur ceci est faillible. L'utilisateur peut maintenant changer la langue associée à chaque portée (si celle-ci contient des textes de parole), cette information est exportée dans le fichier musicXML via le tag "xml:lang". Virtual Singer s'adapte en conséquence.
 

 
- En MusicXML la gestion des objets "tempo" est implémentée ainsi que les objets de type "nom d'accord". Ils sont pour l'instant traités comme des objets de type texte non interprétés. A terme, nous envisageons de recréer une ligne d'accord associée à la portée. Nous rencontrons pour ce dernier type d'objet, un problème préoccupant de positionnement horizontal, nous avons contacté l'équipe de Recordare.  
Voici donc la nouvelle version du fichier d'exemple de l'étape 89.
http://www.myriad-online.com/images/blog/sample2/sample.htm
 
- A partir des préférences générales, l'utilisateur peut désactiver l'utilisation dans le format MusicXML, des extensions spécifiques à Myriad.
 
- Dans les prochains jours, et afin de rapprocher la date de la première béta, nous allons laisser un peu de coté le traitement des fichiers PDF pour nous consacrer à l'interface de PDFToMusic et surtout aux modules d'import et d'export MusicXML.
by Didier Guillion

Dev News Monday, Oct 30th, 2006 at 04:55pm
Projet PDFToMusic, étape 91

 
- L'import MusicXML gère maintenant les groupes de portées (accolades et crochets) et les indications de pédale. Le gros morceau en attente est l'import des tablatures.
 
- De nouveaux objets sont exportés en MusicXML : la ligne graphique et le rectangle graphique.
Voici un exemple de leur définition en MusicXML.
 
 <graphic-line page="1" x-start="559.940" y-start="99.568" x-end="617.446" y-end="99.568" width="0.677"></graphic-line>
 
- Des algorithmes ont été appliqués aux paragraphes de textes pour en déduire leur justification (gauche, centré, droite)
 
- Il arrive parfois, et c'est toujours plaisant, que dans un travail de développement on tombe sur un "effet de bord" sympathique. Cherchant à tester mes algorithmes permettant de regrouper les mots en paragraphes, je me suis demandé ce que donnerait d'appliquer PDFToMusic sur un fichier PDF non musical. Et en fait, cela passe très bien !  
Voici donc en exclusivité mondiale une documentation PDF de Yamaha convertie en fichier .myr :
 
http://www.myriad-online.com/images/blog/sample3/sample.htm
 
Inutile de chercher à la jouer bien sur...
 
J'envisage de laisser à l'utilisateur la possibilité de traiter tout de même ce genre de document dans les préférences générales.
by Didier Guillion
 9 comments.

Dev News Tuesday, Oct 31st, 2006 at 05:02pm
Projet PDFToMusic, étape 92

 
- Au sujet du problème de positionnement des ornements, la réponse de l'équipe de Recordare est tombée. Il y a deux manières de positionner les ornements (appellés articulations en MusicXML), la méthode absolue et la méthode relative. La méthode absolue n'est pas encore reconnue par le Dolet, donc inutilisable. La méthode relative, est relative par rapport au positionnement par défaut du logiciel. Quel est le positionnement par défaut ? On ne sait pas, cela dépends du logiciel... Le traitement va être des plus ératique, en espérant que ceci se standardise dans un futur proche.
 
- Pour exemple, voici une mise à jour de la documentation Yamaha qui corrige les problèmes signalés à l'étape 91 :
 
http://www.myriad-online.com/images/blog/sample4/sample.htm
 
A noter que la police "Symbol" ne réagit pas de la même manière sur Mac et Windows, cela donne une flêche sur Mac et un carré sous Windows. Pourtant, c'est une police standard du format PDF. Etrange.
 
- Nous allons essayer de voir s'il est possible de gérer des paragraphes avec des changements de style. Apparemment le MusicXML est censé le supporter.
by Didier Guillion
 2 comments.


Full view
Reduced view
Most recent first
Oldest first
All
Didier Guillion
Olivier Guillion
Sylvie Ricard
All
Myriad Life
Dev News
Memories
Mood
To be seen
Technical
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
Feb 2015
Mar 2015
Apr 2015
May 2015
Jun 2015
Jul 2015
Aug 2015
Sep 2015
Oct 2015
Nov 2015
Dec 2015
Jan 2016
Feb 2016
Mar 2016
Apr 2016
May 2016
Jun 2016
Jul 2016
Aug 2016
Sep 2016
Oct 2016
Nov 2016
Dec 2016
Jan 2017
Feb 2017
Mar 2017
Apr 2017
May 2017
Jun 2017
Jul 2017
Aug 2017
Sep 2017
Oct 2017
Nov 2017
Dec 2017
Jan 2018
Feb 2018
Mar 2018
Apr 2018
May 2018
Jun 2018
Jul 2018
Aug 2018
Sep 2018
Oct 2018
Nov 2018
Dec 2018
Jan 2019
Feb 2019
Mar 2019
Apr 2019
May 2019
Jun 2019
Jul 2019
Aug 2019
Sep 2019
Oct 2019
Nov 2019
Dec 2019
Jan 2020
Feb 2020
Mar 2020
Apr 2020
May 2020
Jun 2020
Jul 2020
Aug 2020
Sep 2020
Oct 2020
Nov 2020
Dec 2020
Jan 2021
Feb 2021
Mar 2021
Apr 2021
May 2021
Jun 2021
Jul 2021
Aug 2021
Sep 2021
Oct 2021
Nov 2021
Dec 2021
Jan 2022
Feb 2022
Mar 2022
Apr 2022
May 2022
Jun 2022
Jul 2022
Aug 2022
Sep 2022
Oct 2022
Nov 2022
Dec 2022
Jan 2023
Feb 2023
Mar 2023
Apr 2023
May 2023
Jun 2023
Jul 2023
Aug 2023
Sep 2023
Oct 2023
Nov 2023
Dec 2023
Jan 2024
Feb 2024
Mar 2024
Mar 14th, 2024 at 06:45pm 
Comment from Olivier Guillion
@André Baeck
Mar 14th, 2024 at 05:00pm 
Article from Didier Guillion
Harmony Assistant 9.9.8  étape 197
Mar 13th, 2024 at 04:52pm 
Comment from André Baeck
Mar 13th, 2024 at 04:52pm 
Comment from André Baeck
Mar 13th, 2024 at 03:03pm 
Comment from Oliveira
Excelentes mejoras en el reproductor de MUSL
Mar 13th, 2024 at 03:03pm 
Comment from Oliveira
Excelentes mejoras en el reproductor de MUSL
Mar 13th, 2024 at 09:56am 
Comment from Olivier Guillion
Réponses :
Mar 13th, 2024 at 09:56am 
Comment from Olivier Guillion
Réponses :
Mar 12th, 2024 at 04:57pm 
Article from Didier Guillion
Harmony Assistant 9.9.7  étape 196
Mar 12th, 2024 at 12:32am 
Comment from JL Stahl
Réglage du Mixer

Top of page
Legal information Cookies Last update:  (c) Myriad