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 |  |
|
| |
|
Aujourd'hui rien de passionnant : transfert des projets sur le MacPro et reconstruction avec XCode.
|
|
|
| by Didier Guillion | |
|
| |
|
J'ai reçu mon nouveau Mac ! 2x2.66 Ghz Dual Core Intel Xeon 2Go de RAM avec deux disques montés en RAID. C'est rapide, très rapide !
La compilation complète du projet PDFtoMusic en mode non optimisé prends 45 secondes...
Chipoter pour quelques secondes semble un peu futile, mais quand un programmeur compile soixante fois son projet dans la journée, sachant qu'il ne peut guère faire grand chose pendant ce délai, gagner une minute fait gagner une heure de travail...
Je change de Mac environ tout les trois ans, et à chaque fois je double la vitesse. Maintenant il reste à transférer trois ans de travail sur la nouvelle machine. Au passage le transfert via afp:// est complètement loufoque. Comment imaginer qu'un OS digne de ce nom oublie des fichiers ! Et c'est pourtant le cas, sans avertissement, je me retrouve avec des fichiers manquants dans mon arborescence... |
|
|
| 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 | |
| |
|
Voici les tests de vitesse sur un lot de 23 fichiers PDF complexes, effectués avec la version publique de PDFtoMusic Pro.
Windows XP Intel CoreDuo 2.66, compilé avec CodeWarrior : 7 mn 18 sec
MacPro 2x2.66 Ghz Dual Core Intel Xeon 1Go de RAM, compilé avec XCode : 8 mn 04 sec |
|
|
| by Didier Guillion | |
| |
|
Ca y est, cela se compile, et se deboggue ! Les problèmes venaient du fait que, apparemment, sur MacTel le deboggage d'une application ne peut se faire que dans un bundle (paquet) complet.
J'en ai profité pour brancher deux écrans et corriger les problèmes d'agrandissement de fenêtres soulevés par M Puff à l'étape 164. Au passage, l'ouverture d'un tiroir redimensionne maintenant la fenêtre dans les deux sens.
Quelques astuces vont également nettement améliorer la vitesse de traitement pour la prochaine version que ce soit sur Mac ou sur PC.
Nous allons maintenant faire quelques courses de vitesse entre notre PC le plus rapide et le MacPro.
(...) |
|
|
| by Didier Guillion | |
| |
|
CodeWarrior, c'est fini, salut l'ami...
En guise de test, le projet CodeWarrior de "PDFtoMusic" est transféré sur le MacPro.
Comme je le craignais, et bien que la compilation se passe bien sous CodeWarrior, impossible de débogger une application PPC sous MacTel.
CodeWarrior bloque sur "Loading Symbols".
Bonne performance tout de même, le même projet se compile 50% plus vite entre un un G4 bi pro et un MacPro, n'oublions pas que CodeWarrior tourne en émulation Roseta.
La piste XCode.
Puisque XCode est maintenant la seule plateforme de développement sur Mac, la question devient, est- il enfin utilisable ?
Un projet type, "PDFtoMusic" est transféré sur le MacPro et la compilation est tentée. Le transfert se passe beaucoup moins bien que celui du projet CodeWarrior. En fait, XCode a mémorisé de nombreux chemins sur des fichiers en absolu. Après quelques heures d'essais infructueux. Je choisis de regénérer le projet XCode depuis zéro à partir du projet CodeWarrior. Il me faut également regénérer de la même façon toutes les librairies associées. Ouch !
Enfin, j'obtiens une application qui se compile et se lance.
L'interface d'XCode est plutot agréablement réactive...
Le temps de compilation est très prometteur. En version non optimisée je passe de 74 secondes sur le G4/CodeWarrior a 27 secondes sur le MacPro/Xcode.
Et là nouveau problème, l'application se lance sous deboggueur mais perd son "focus", elle ne reçoit plus aucun événement.
Certainement une option d'XCode que je n'ai pas comprise, il reste du travail.
(...) |
|
|
| by Didier Guillion | |
| |
|
Aujourd'hui, grand jour. Philippe m'a prété un Mac Pro pour faire des tests. Je dois vérifer, avant d'en acquérir un, si mes outils de développement fonctionnent dessus et à quelle vitesse. Pour XCode je ne m'inquiète pas trop, pour CodeWarrior, un peu plus. Comme il va tourner sous Roseta, va-t-il pouvoir accéder au déboggeur GDB ? Si ce n'est pas le cas, je suis mal... Je me vois mal opter pour XCode, mais peut-être sur une machine un peu rapide est-il enfin utilisable ? Sur un G4 bi, en tout cas, c'est "pizza" toutes les trente secondes.
La machine est sur le bureau (2x2.66 GHz Dual Core Intel Xeon 1Go de RAM), connectée sur le réseau en quelques secondes, le démarrage est simplissime. La coque métal fait solide. Grande satisfaction : pour une fois Apple à pondu une machine vraiment silencieuse (pas que dans leur pub). Agréable.
Installation des outils de développement
Codewarrior s'installe et se lance sans problème. Bien sûr il crie que GDB n'est pas présent. Il faut maintenant obtempérer et installer XCode.
Mon CD original de Mac OS X 10.4, contient une version trop ancienne de XCode (antérieure aux MacTels), je ne peux donc l'utiliser, je vais donc le télécharger sur l'ADC.
Le téléchargement d'XCode sur le site Apple a été une source de gags Kafkaiens. L'image disque fait 923 Mo et prend, quand tout se passe bien, 19 minutes pour se transférer (21 heures quand la connexion est faible). Or, les as de la sécurité chez Apple on décidé de déconnecter les membres "sans activité" au bout de 15 minutes ! Au cinquième téléchargement interrompu à 15 minutes, je décide d'essayer de faire semblant d'être en activité. Alors pendant 19 minutes, je clique sur des éléments de leur site au hasard... Ca ne change rien... Echec.
Je passe sur mon G4, et j'essaie de télécharger. Cela fonctionne du premier coup. Hasard ?
L'installation se passe bien.
Passage des projets et des sources
Le transfert via le réseau Mac OS X (afp) est un enfer. Tous les trois fichiers/dossiers j'ai des erreurs de droits d'accès que je dois corriger à la main via le Finder et une fois sur deux cela ne change rien ! Facile de faire un système sécurisé quand la moindre opération comme ne serait-ce que copier un fichier ou changer son extension demande une confirmation à l'utilisateur...
Je pense avoir tout transféré, maintenant place à la compilation.
(...) |
|
|
| 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 | |
| |
|
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 | |
| |
|
- 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 | |
| |
|
- M Puff a signalé un problème intéressant : il n'est pas possible de changer à la fois la durée d'une note et le pointé associé. Ceci sera amélioré dans la prochaine version.
- M Nicoll nous a proposé une partition où le barré sur les appogiatures était considéré comme une note. Ceci sera corrigé.
- Un algorithme spécial a été implementé pour recalculer les sens des tiges des notes en accord. Ceci améliore grandement l'aspect final de nombreux fichier PDF.
- Afin d'uniformiser les changements d'échelle avec les autres logiciels, l'échelle 100% est maintenant accessible via le raccourci Commande+1. Une échelle à 200% a été implementée via Commande+2.
- Lors de l'export au format Harmony Assistant, l'indicateur "Ne pas imprimer les portées vides" n'est positionné que si au moins une portée est marquée comme cachée dans le fichier MusicXML
- La prise en compte du nom des groupes (et de leur nom abrégé) a été améliorée. |
|
|
| by Olivier Guillion |  |
|
| |
|
L'ADSL utilise votre ligne téléphonique pour vous connecter à l'Internet à haut débit. Mais cette technologie est assez sensible à la distance qui vous sépare de votre NRA (Noeud de Raccordement Abonné), le centre de FT (on doit dire Orange, maintenant ?) où aboutissent toutes les lignes du quartier.
Jusqu'à 1500 m, vous êtes au top, jusqu'à 2500 m, c'est moyen, et au-delà, les problèmes commencent. Plus de "très haut débit", et selon la qualité de la ligne (diamètre des fils, qualité des connexions, etc) cela peut virer à la catastrophe.
Ici, à Myriad, nous sommes à environ 1km de notre NRA (MIN31), ce qui nous permet d'avoir une connexion rapide et sans problème. Mais, comme vous le savez peut-être, nous allons dans peu de temps déménager ailleurs dans le quartier.
Tout paraissait bon. La nouvelle adresse était située à moins de 1500m du NRA "MIN31"(Minimes). Mais voila, les câblages de FT sont parfois étonnants, et il semblerait que certains abonnés de la rue Montaigne (et l'ancien propriétaire de la maison était dans ce cas) soient connectés à "Capitole", à plus de 2,5 km. Donc, adieu très haut débit, et bonjour aux ennuis qui se profilent, en comptant sur la loi de Murphy.
Il y a même des maisons dans la rue, avec 3 lignes, dont 2 sont sur Capitole, et une sur Minimes
Alors comment s'y prendre pour faire en sorte d'être reliés au bon ? Contacter (ou soudoyer) FT ? Ouvrir 4 lignes pour les obliger à recâbler, et en résilier 2 ? Acheter un garage bien placé, y faire poser le téléphone, et mettre une liaison WIFI ?
Si quelqu'un a une solution, des contacts ou une idée géniale, nous sommes preneurs. Notre usage d'Internet étant plutôt du genre "intensif", c'est une question vitale ...
Note : pour connaître le NRA et la distance, pour ceux qui ne savent pas, il y a http://www.degrouptest.com. Avec les pages blanches ou jaunes, on fait des miracles.  |
|
|
| by Olivier 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 | |
|
| |
|
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 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 | |
| |
|
- 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 | |
|
| |
|
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 | |
|
| |
|
- 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 | |
|
| |
|
- 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 | |
|
| |
|
- 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 | |
| |
|
- 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 | |
|
| |
|
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 | |
|
| |
|
|
