Aujourd'hui, nous proposons, conformément à notre planning, la première version publique de PDFtoMusic. La gestation a duré 9 mois, ce qui semble un bon chiffre. En tout cas, l'un des plus gros chantier de notre histoire, un peu après la première version d'Harmony Assistant qui avait pris plus d'un an. Bien sur cette version est encore perfectible, ce n'est que la version 1.0, mais l'application est solide et traite déjà de manière plus que satisfaisante une grande quantité de fichiers PDF musicaux. Je pense que cette version va évoluer très rapidement. Ce projet défriche des zones encores vierges et il y a encore plein de nouvelles découvertes à faire. Pourquoi ne pas imaginer un convertisseur de PDF vers Word pour récupérer les documents textes ? A moins que cela n'existe déjà.
Mais, en premier lieu, nous voulons remercier grandement tous les membres de l'équipe de béta test qui ont montrés une grande patience et nous ont, dans de nombreux cas, appris des techniques de notation que nous ignorions totalement (par exemple les altérations "anciennes" au dessus de la note qui ont été un vrai casse-tête et autres Objets Musicaux Non Identifiés) .
La très prochaine étape sera une nouvelle version d'Harmony Assistant qui gérera de manière infiniment meilleure l'export et l'import MusicXML et pourra ainsi communiquer de manière des plus efficace avec PDFtoMusic Pro.
|
|
|
| by Didier Guillion |  |
|
| |
|
- La journée s'est passée à référencer PDFtoMusic sur l'Internet et c'est toujours un peu long, heureusement les fichiers PAD sont maintenant de plus en plus reconnus.
- Les rapports d'erreur sur les modules d'importation d'Harmony Assistant sont en cours de traitement. Là aussi, cela demande beaucoup de temps. L'importeur Encore devrait mieux fonctionner.
- Comme expliqué dans l'étape 146 de ce carnet de route, nous avons implémenté un système de compression des fichiers MusicXML pour faciliter leur échange et leur utilisation via le Myriad Music Plug-in (le format .xmz). Cela faisait plusieurs mois que j' en exprimait la nécessité de plus en plus imminente à l'équipe de Recordare. Il y a quelques jours, ils ont ouvert une discussion sur leur mailing-list. Apparemment, ils ne se tourneraient pas vers une solution légère mais plutôt vers une version "luxe". Au lieu de simplement utiliser les algorithmes PKZip de compression pour encoder un fichier, ce serait le format Zip, multi-fichiers, répertoire, mot de passe, et tout le toutim. Bon. J'espère que les personnes qui ont poussé dans ce sens l'utiliserons rééllement...
C'est un peu comme si vous aviez un robinet qui fuyait dans votre salle de bain, le plombier vous propose de la refaire entièrement, et quand vous demandez "quand" il vous dit, de toute façon je ne suis pas libre avant 2010...
|
|
|
| by Didier Guillion | |
|
| |
|
- M Puff, nouveau dans ce projet (bienvenue à lui) nous a envoyé d'abondants et pertinents rapports ce week-end, ceci a engendré de nombreuses modifications en vue de la prochaine version publique. Associés aux rapports de MM Good, Machefert, Faivre et autres utilisateurs, voici ce que cela donne :
- Amélioration : après édition du mode expert, possibilité de recalculer tous les documents ouverts.
- Amélioration : lorsque l'on défini un nouveau type de tuplet il se rajoute dans la liste des valeurs de tuplet.
- Amélioration : les fichiers .myr sont maintenant compactés.
- Amélioration : Chapitre "Comment créer des PDF sous Mac OS 9" dans le manuel.
- Amélioration de la recherche des numéros de mesure
- Correction de problèmes divers dans les préférences générales
- Correction de problème pouvant survenir lors de l'édition de documents non vectoriels
- Correction de boucle infinie lors du choix d'un tuplet utilisateur
- Correction : choix des pages à exporter pour les formats autres que le MusicXML
- Correction : Les barres doubles de fin de mesure étaient parfois mal reconnues
La documentation a été mise à jour sur le Net.
|
|
|
| by Didier Guillion | |
| |
|
- M Puff traque les erreurs dans la documentation Anglaise. Nous avons des demandes pour une version en Allemand de PDFtoMusic, nous nous y lancerons dès que le manuel sera vraiment totalement finalisé.
- Voici les modifications apportées à PDFtoMusic aujourd'hui :
Amélioration de la reconnaissance des métriques
Amélioration de la reconnaissance des paragraphes pour les textes libres
Mise à jour des bases de données pour l'OCR des polices.
Correction : Taille des nuances
Correction : Détermination du type de fichier selon l'extension lors de l'export.
Correction : Périphérique de sortie associé à l'instrument lors de la génération des .myr
Correction : Export MusicXML de la "slash notation"
- Enfin, une astuce. Pour l'instant PDFtoMusic ne gère pas les documents PDF avec rotation, comme dans cet exemple fourni par un utilisateur, M Tubb.
Mais une manip assez simple permet de le traiter tout de même : chargez le dans un visualiseur de PDF, appliquez la rotation et "imprimez le" comme un nouveau fichier PDF. Il sera traité sans problème par PDFtoMusic.
|
|
|
| by Didier Guillion | |
|
| |
|
- Sur suggestion de M Puff, dans l'export par lot, il est maintenant possible de définir les corrections au mode de calcul qui seront appliquées à l'ensemble des fichiers traités.
- Lors de l'édition des paramètres "expert", le nom des rubriques dont au moins un élément a changé par rapport aux valeurs de référence s'affichent d'une couleur particulière. Pour chaque valeur modifiée, la différence à la valeur de référence s'affiche également.
Ceci permet de localiser rapidement les paramètres modifiés.
 |
|
|
| by Didier Guillion | |
|
| |
|
La nouvelle version de PDFtoMusic, v1.0.1, est disponible. Pas mal de corrections de problèmes, mais aussi les améliorations décrites dans ce carnet de route depuis la semaine dernière.
Nous avons pas mal réflechi à la manière d'annoncer qu'un document PDF ne pouvait être traité car, apparemment, il y avait pas mal de confusions. Nous espérons que la nouvelle présentation de ce cas sera plus claire.
M Faivre nous a soumit un diagramme à afficher dans le manuel pour expliquer les interconnections entre les formats de fichier et les logiciels :
Merci à lui, car ce n'est vraiment pas évident ! Qu'en pensez vous ?
Dans cette version, nous avons essayé de toucher au minimum au "moteur" interne de la reconnaissance, c'est surtout des améliorations ergonomiques qui ont été appliquées.
Si aucun problème n'est rencontré avec cette version, nous allons pouvoir essayer d'améliorer certains algorithmes. Par exemple M Baret (aka Groromrom) nous a signalé à maintes reprises des noms d'accord non reconnus. Ceci est du au fait que PDFtoMusic ne concatène les textes que si les caractéristiques de la police (nom, taille, casse) sont identiques. Or, certains fichiers notent les accord comme "Cm7" avec un "C" d'une taille supérieure au "m7".
Nous gardons a l'esprit d'améliorer le système de recherche de PDF musicaux sur l'Internet, déjà présent dans "Internet>Rechercher une partition", qui se contente d'envoyer une requète à Google. Nous envisageons de construire un automate qui balayerait les pages sur l'Internet, extrairait les PDF, déterminerait s'il s'agit de "vrais" PDF et les indexeraient dans une base de donnée sur notre serveur.
Ainsi, une recherche de partition donnerait toujours un PDF valide et exploitable, sélectionnable dans une liste avec peut-être une petite image montrant la première page. Nous savons comment faire, il nous faudrait juste un peu de temps pour l'implémenter. |
|
|
| by Didier Guillion | |
|
| |
|
- Nous travaillons sur la prochaine version de PDFtoMusic. L'algorithme de concaténation de chaines pour reformer les noms des accords, décrit à l'étape précédente a été implémenté. Il "récupère" pas mal d'erreurs. Au passage le symbole "degré" n'était pas traité, c'est maintenant corrigé.
Il apparait que certains polices (comme la JazzChord) utilisent une façon un peu exotique de représenter les symboles. Par exemple pour noter exemple "-7" elles n'utilisent pas le "-" suivit du "7" mais un seul caractère qui contient "-7". Il n'y a aucune correspondance avec l'Unicode et la seule façon de pouvoir traiter cela serait de faire un module de reconnaissance spécifique à chaque police. A étudier.
- Nous reprenons les documents complexes fournis par les utilisateurs et qui étaient restés en attente car nécessitant des modifications de bas niveau et les traitons un par un. Chacun recevra une réponse... dès que nous en aurons une !
- Enfin, M Faivre nous propose une nouvelle version de son diagramme :
|
|
|
| by Didier Guillion | |
|
| |
|
- Un cas très intéressant proposé par M Miconnet : le mélange dans une même partie de notation en barres et de notation conventionnelle.
- M Good nous à soumis quelques problèmes qui ont été corrigés :
Reconnaissance des tenuti
Lié dans coulés
Reconnaissance silence de brève
Affichage, édition, exportation des tempi
- Enfin merci de vos cogitations sur le schéma d'explication. Je pense que la démarche de Sylvain sur le forum est bonne : proposer le schéma quand quelqu'un pose la question et voir si cette personne comprend. |
|
|
| by Didier Guillion | |
| |
|
Aujourd'hui pas mal d'ajustements et de corrections de problèmes mineurs sur PDFtoMusic et Harmony Assistant.
Dans PDFtoMusic un nouveau paramétrage du mode expert fait son apparition : épaisseur maximale des accroches.
Dans Harmony Assistant, sur requète justifiée de Sylvain, possibilité de définir le texte des objets textes associés aux notes dans la boite de changement de l'aspect général.
Sur PDFtoMusic nous continuons a réfléchir sur la possibilité de traiter les tuplets sous entendus. Nous recherchons un algorithme efficace et je pense que nous progressons.
Très bientôt nous allons mettre en chantier la reconnaissance des partitions sous forme d'image. Cela va être un gros chantier. Je prévois une sortie pour Septembre...
|
|
|
| by Didier Guillion | |
|
| |
|
Un problème assez casse tête de notes accrochées avec double tige à été résolu. Une jolie palette de problèmes mineurs a été corrigée, une prochaine sous version devrait être disponible en début de semaine prochaine.
Nous commençons a réfléchir (enfin surtout Olivier) au traitement d'images matricielles (bitmap).
M Peter Deutsh (un des initiateurs du projet GhostScript) nous a envoyé un gentil email. Il avait démarré en 2003 un projet similaire a PDFtoMusic, écrit en Python, appellé Musix, qu'il n'a jamais pu finaliser. Dommage pour lui. Un entretien intéressant à propos de GhostScript est disponible ici :
http://devlinux.org/deutsch-interview.html |
|
|
| by Didier Guillion | |
|
| |
|
- M Puff nous a signalé des problèmes de manipulation de fenêtres sur les Macintosh avec plus d'un écran. Je vais essayer de me faire prêter une machine pour pouvoir corriger cela : pour l'instant mon Mac ne supporte qu'un écran.
En attendant, la gestion du mode "plein écran" tient maintenant compte du fait que le tiroir soit ouvert ou non.
- Quelques ajustements mineurs ont été fait : La concaténation des nuances vérifie la logique du résultat ce qui empèche par exemple de fusionner "mf" et "sfz".
Les textes encadrés pouvaient perturber les indicateurs de passage, ceci a été corrigé.
- Enfin M Miconnet nous a soumis un fichier intéressant où les lignes additionnelles sont presque aussi épaisse que les accroches :
Ceci a été ajusté pour la prochaine version.
|
|
|
| by Didier Guillion | |
| |
|
Aujourd'hui, correction de problèmes mineurs. La version 1.0.2 est en cours de validation sur nos fichier PDF de référence (cela prends en général une bonne douzaine d' heures). Si tout se passe bien, la version publique devrait être disponible très bientôt. Vraisemblablement une nouvelle version d'Harmony et du Plug-In devrait être proposée simultanément. |
|
|
| by Didier Guillion | |
| |
|
La nouvelle version de PDFtoMusic a été validée et postée sur le site. Le petit mot du jour n'a pas eu le temps de naitre... |
|
|
| by Didier Guillion | |
| |
|
Nous avons analysé les tests d'hier montrant que le MacPro est plus lent que le PC. Le pourcentage d'occupation des processeurs sur PC est de 50% contre seulement 25% pour le MacPro : un seul des quatre coeurs est utilisé en même temps. Donc en fait, sauf si l'application est conçue pour le multi-tâche, avoir plusieurs coeurs ou processeurs ne l'accélèrera pas, car de toute façon elle n'utilisera qu'un coeur. C'est uniquement la fréquence du processeur qui peut faire gagner et bien sur, l'optimisation du code.
Je dirait qu'à première vue, le compilateur GCC utilisé par XCode est beaucoup plus à l'aise avec la technologie des processeurs Intel qu'avec celle de Motorola. Quant à CodeWarrior (produit par MetroWerks qui était une filiale de Motorola) il se défend bien sur tous les tableaux.
Nous continuons à optimiser la vitesse de traitement, sur Mac mais aussi sur PC.
Le lot de fichier de fichier PDF de référence a été converti en .myr en 5mn 15 sec sur MacPro (la version publique donne 8mn 04 sec) et 5 mn 20 sur PC.
L'on voit que c'est surtout le coté Mac qui à gagné (près de 35%). Nous avons activé certains modes de calcul des nombres à virgule et cela a été efficace. |
|
|
| by Didier Guillion | |
| |
|
Un nouvel algorithme permet de rabouter les différentes composantes du nom des accords lorsque celles ci ne sont pas alignées verticalement, comme dans cet exemple de M Machefert :
Des problèmes de clavier sur MacTel ont été corrigés, il sera possible d'interrompre un calcul par appui sur la touche d'échappement.
Le transfert des projets vers le MacPro se poursuit. Comme décrit dans ce carnet de route, le transfert via afp d'arborescences complêtes "oublie" des fichiers. Mais apparemment, ce n'est pas le cas si l'on "zippe" le dossier et extrait l'archive sur le MacPro... |
|
|
| by Didier Guillion | |
|
| |
|
|
|
Sep 22nd, 2023 at 04:52pm
Article from Didier Guillion
Harmony Assistant 9.9.7 étape 143
Sep 20th, 2023 at 06:01pm
Article from Olivier Guillion
Harmony Assistant 9.9.7 étape 142
Sep 19th, 2023 at 04:57pm
Article from Didier Guillion
PDFtoMusic
Sep 18th, 2023 at 06:40pm
Article from Olivier Guillion
Harmony Assistant 9.9.7 étape 141
Sep 15th, 2023 at 05:01pm
Article from Didier Guillion
Harmony Assistant 9.9.7 étape 140
Sep 15th, 2023 at 05:01pm
Article from Didier Guillion
Harmony Assistant 9.9.7 étape 140
Sep 14th, 2023 at 06:42pm
Article from Olivier Guillion
Harmony Assistant 9.9.7 étape 139
Sep 13th, 2023 at 04:59pm
Article from Didier Guillion
Harmony Assistant 9.9.7 étape 138
Sep 12th, 2023 at 06:03pm
Article from Olivier Guillion
Harmony Assistant 9.9.7 étape 137
Sep 11th, 2023 at 05:05pm
Article from Didier Guillion
Harmony Assistant 9.9.7 étape 136
|
|
|
|
