Nous avons réussi à créer un projet PackageMaker permettant d'installer Harmony Assistant. C'est nettement moins instable que les anciennes version mais reste tout de même très rigide. On a laissé tomber.
Nos anciens installateurs ont été repris afin de devenir Universal Binary, ce ne fut pas une mise affaire, mais cela à l'air opérationnel maintenant.
Et en tache de fond nous continuons à réfléchir au portage d'Acam sous UNIX. |
|
|
| by Didier Guillion |  |
| |
|
Le passage de Mac OS X en 64 bits a des conséquences inattendues, comme une ligne de dominos qui tombe.
Safari, sur Snow Leopard, est compilé en 64 bits. Il ne permet donc plus de faire tourner les plug-ins compilés en 32 bits (je pense que les programmeurs d'Apple ne se sont pas non plus trop foulés sur le coup).
Nous allons donc devoir recompiler le Myriad plug-in en 64 bits, ce qui serait simple si Apple avait bien voulu porter la librairie de compatibilité Mac OS 9, appelée "Carbon", en 64 bits.
Sans cette librairie, impossible d'utiliser directement les fonctions système Mac dont nous avons assuré la compatibilité avec la version PC depuis 15 ans. Il faudrait donc, pour pouvoir utiliser nos fichiers "source" compatibles PC/Mac sur le Mac, se réécrire une librairie qui servirait de couche d'interface avec le système (elle est appelée ACAM sur Windows).
Donc nous nous sommes dit: si nous devons écrire une librairie sur les deux systèmes, donc si nos fichiers "source" ne peuvent être écrit nativement pour utiliser ni le système Mac OS, ni Windows, pourquoi alors ne pas écrire notre système propriétaire?
Voila comment cela fonctionnerait: nos programmes utiliseraient un jeu de fonctions, identique sur Mac et sur PC, mais n'étant ni les fonctions système Mac, ni PC.
Pour porter nos programmes sur une plateforme (Mac OS, Windows, Linux, Chrome OS ou n'importe quoi d'autre), il nous suffirait d'écrire la "petite" couche qui traduit ce jeu de fonctions en fonctions système natives.
Mettre au point cette couche, depuis ses caractéristiques sur papier jusqu'au code, représenterait un gros travail, certainement plusieurs mois, mais nous assurerait un système de travail pérenne pour au moins la prochaine décennie.
On en vient donc à Linux. Nos applications deviendraient ainsi encore plus portables. Envisager un portage sur un nouveau système reviendrait à ne réécrire que le goulot d'étranglement (bottleneck) logiciel de liaison avec les fonctions système, la totalité des fichiers source de l'application elle-même restant strictement inchangés.
C'était déjà à peu près le cas avec ACAM, développé pour Windows uniquement. Mais petit à petit, au fil des améliorations, ACAM et Windows se sont imbriqués. Le réécrire pour un autre système deviendrait un casse-tête. La mise à plat générale du projet, et le nouveau départ sur des bases plus solides, permettrait de clarifier la tâche.
Nous avons donc -re-commencé à évaluer le développement sur Linux, en installant quelques outils et en procédant à quelques tests.
Ceux-ci ne sont pas encore terminés à l'heure où j'écris, donc nous partagerons nos impressions dans un prochain billet.
Bon week-end à tous ! |
|
|
| by Olivier Guillion |  |
|
| |
|
En parallèle de nos questionnement sur la portabilité de nos applications, l'évolution des systèmes d'exploitation et nos orientations en matière de système de développement pour la décennie à venir, nous continuons à corriger les problèmes, crashs et irrégularités que nous trouvons sur Harmony/Melody.
Aujourd'hui :
- Correction d'un crash possible dans les calculs de Virtual Singer
- Crash possible lors de la détermination de la meilleure portée parole d'un document (par exemple lors d'un import MIDI karaoke)
- Crash lors de l'effacement du tout premier caractère d'une ligne de paroles
- Erreurs et crashs lors des opérations de recherche/Remplacement dans les fenêtres de source MyrScript
- Crash lors de l'accès à la gestion de l'espace utilisateur en l'absence de connectivité internet. |
|
|
| by Olivier Guillion | |
| |
|
Nouvelle surprise désagréable, les applications 64 bits, comme Safari, ne peuvent invoquer (pour une raison que je ne peux expliquer) les modules 32 bits. Comme par exemple le Myriad Music Plug-In. Bon. Donc il va falloir compiler le plug-in en bicéphale, 32 bits et 64 bits.
Ah ! Ah ! Ce serait trop simple et sans compter sur la perversité d'Apple ...
La framework Carbon (librairie en gros) que nous utilisons, lui n'est pas disponible en 64 bits ! Et ne le sera probablement jamais. Pourtant Steve je croyais que c'était juste une case à cocher lors de la compilation ?
Donc, deux solutions : on réécrit tout en utilisant Quartz 2D et consort. Mais 4 mois de développement pour une application gratuite, c'est difficilement envisageable, surtout qu'une fois de plus Apple peut changer de technologie sans prévenir dans le futur.
Soit on porte Acam sur Mac OS X.
Là, cela devient plus intéressant, une refonte d'Acam pourrait nous motiver pour faire un portage Linux dans la foulée, si seulement on pouvait trouver un environnement de développement satisfaisant sur ce système.
Ce qui nous gonfle un peu, c'est que tous ces changements, c'est juste beaucoup de sueur pour pouvoir juste rester sur place.
|
|
|
| by Didier Guillion | |
|
| |
|
Alors que, sur Macintosh, la mise au point du nouvel installateur se poursuit, nous corrigeons dans Harmony Assistant des problèmes mis en évidence par le nouveau compilateur, notamment dans MyrScript :
- Divers crashs possibles lors de la consultation du manuel MyrScript
- MyrScript: correction du paramètre de retour de Score.NewView(...)
- MyrScript: le nom de fichier envoyé à Score.MusicExport peut maintenant être stylé. Le style est alors éliminé.
- MyrScript: la méthode Score.AbortRecording() libère la partition si cette dernière est vide. La documentation et l'exemple associé ont été corrigés.
- Une irrégularité dans les liens depuis le sommaire des exemples exécutables de la documentation MyrScript a été corrigée.
- Divers dépassements possibles de tableaux (buffer overflow) ont été corrigés. Chacun d'eux pouvait produire un crash.
|
|
|
| by Olivier Guillion | |
| |
|
C'est en trainant les pieds que nous avons pris notre courage à deux mains et tenté l'installation de Mac OS X 10.6 sur notre machine de développement. Le tout en croisant les doigts.
Bien entendu, une copie de sécurité de tous nos fichiers avait été faite au préalable.
Déjà petite frayeur au lancement de l'installateur, il ne reconnait pas notre disque dur.
Redémarrage direct depuis le CD et la cela fonctionne. 45 mn d'installation tout de même.
Pas de mauvaise surprise, cela démarre, si ce n'est que le CD acheté il y a trois jours est en 10.6.0, il nous faut dans la foulée mettre à jour en 10.6.2.
Par contre, la volonté d'Apple d'abandonner le PPC via l'émulation Roseta est évidente, l'installation de ce kit de quelques Mo (qui fait tourner les applications PPC sur MacTel) est optionnelle et il faut se balader dans les options pour l'activer lors de l'installation.
Déjà pour nous c'est un problème : tous nos logiciels ont été adaptés et compilés pour Intel (et cela n' a pas été une mince affaire) sauf notre programme d'installation. Après tout, on installe, et on jette l'archive non ?
Ce qui veut dire que sur une installation standard de Mac OS X, l'utilisateur ne pourra pas installer nos logiciels.
Une solution serait de refaire la procédure d'installation via PackageMaker, la procédure "officielle" d'Apple que nous utilisons déjà pour le Myriad Music Plug-In et le Plug-in QuickLook. Mais sur de gros projets, nos essais avaient aboutis à la conclusion que c'était une jolie bouse bien plantogène.
Enfin, nous allons essayer une fois de plus ...
Sinon, au niveau réactivité de ce "nouveau" système, je n'ai pas constaté de différence. |
|
|
| by Didier Guillion | |
|
| |
|
Maintenant que tous les projets d'usage courant ont été recompilés avec Visual C++, nous avons entamé une opération de test général et de débogage sur Harmony Assistant.
Les tests sont pour vérifier que la nouvelle version du programme est pleinement fonctionnelle. Il est à peu près impossible de tester toutes les fonctionnalités d'Harmony, mais nous avons essayé de nous focaliser sur ce qui aurait le plus de risques de mal fonctionner, c'est-à-dire tous les imports de fichiers, les entrées/sorties audio et MIDI, certains scripts de calcul massif (sur les pistes numériques), les éditions complexes (copiers/collers), la gestion des portées fuisionnées ou des vues, etc.
Les fonctions de contrôle lors de l'exécution offertes par Visual C++ nous permettent par la même occasion de débusquer des problèmes potentiels.
Ainsi, nous avons pu corriger:
- un problème dans l'import de certains fichiers Finale
- une mauvaise mise en forme des notes après une saisie MIDI en temps réel
- un crash possible à la fermeture du menu contextuel des portées multi-voix
- un crash dans Melody Player
En parallèle, nous continuons le cours normal du développement, avec une correction sur le script d'import Noteworthy, et une nouvelle valeur, nouvelle valeur GlobalBarSetting.IsInvisible, ajoutée à MyrScript.
Bon week-end ! |
|
|
| by Olivier Guillion | |
| |
|
Certains ornements ne tenaient pas compte de l'échelle des symboles de la portée, cela a été corrigé.
Le redimensionnement des palettes est terminé en ce qui concerne la programmation.
Nous entamons la refonte des graphismes des icônes.
On nous a signalé des problèmes sur Mac OS X 10.6, nous l'avons donc commandé pour l'essayer.
Nous ne sommes pas très chauds car l'installation de 10.5 avait été épouvantable. Nous avions le CD de la première version et subi deux plantages graves à l'installation. Enfin, après une manip douloureuse nous avions réussi à prendre la main quelques secondes pour faire une mise à jour immédiate en 10.5.1.
Résultat, notre CD de 10.5 est inutilisable et si 10.6 ne fonctionne pas il nous sera impossible de revenir en arrière... |
|
|
| by Didier Guillion | |
| |
|
Le zoom sur les palettes est pratiquement fini. Il reste à tout revérifier une dernière fois et redessiner les icônes les plus importantes en grand format.
Un fichier PDF utilisant une police de caractères que nous ne connaissions pas nous a été envoyée. Cette police, appelée "Reprise", imite un tracé à la main à l'instar de "Jazz" ou "Inkpen". Elle est fournie avec la dernière version d'un logiciel d'édition concurrent. Nous avons donc recalculé nos filtres afin que PDFtoMusic la traite correctement. Cette nouvelle version sera livrée avec la prochaine version beta de PDFtoMusic/Pro
Des tests précis de vitesse d'exécution ont été menés, afin de s'assurer que le nouveau compilateur était aussi efficace que l'ancien. On note un ralentissement de seulement 1 à 2%, ce qui peut être considéré comme négligeable.
En version Windows, Melody et Harmony sont livrés avec une petite application, appelée MyrPref, à laquelle nous avions ajouté une fonction particulière pour Vista, lorsqu'elle était lancée avec la touche majuscules appuyée.
Sur Windows 7, il n'est pas possible de double-cliquer sur une application avec la touche majuscules enfoncée, aussi avons-nous modifié MyrPref pour lui faire demander en clair l'action à effectuer.
A ce sujet, saluons encore une fois le génie des gens de chez Microsoft.
Chaque version de Windows, même si elle possède un nom, est numérotée de manière interne sous la forme x.yy.
Par exemple, Windows 95 porte le numéro 4.00 et Windows 98, 4.10.
Là, version majeure. Windows 2000 prend le numéro 5.0 et Windows XP 5.1.
Puis Vista sort et à droit au numéro 6.00
Là Microsoft se dit que le nom de la version de Windows pourrait tout simplement être son numéro.
Et naturellement, Windows 7, qui marque une avancée majeure, correspond donc à la version... 6.1 ! 
|
|
|
| by Olivier Guillion | |
|
| |
|
L'implémentation du changement de taille des palettes se poursuit. Un Majuscule+click sur le titre de la palette suivi d'un mouvement haut et bas de la souris adaptera le facteur d'échelle. Commande+Majuscule+click rétablira une échelle de 100 %.
Au passage, afficher les palettes en plus grand a révélé de nombreux petits problèmes de positionnement des icônes qui ont été corrigés dans la foulée.
Bien évidemment, de nombreux graphismes sont très moches une fois agrandis. Nous allons re-dessiner les plus importants. |
|
|
| by Didier Guillion | |
|
| |
|
Pour une raison qui nous a toujours semblé mystérieuse, on nous demande régulièrement de pouvoir agrandir les icônes des palettes.
C'est vrai que les écrans deviennent de plus en plus grand, mais justement, c'est pour pouvoir y caser plus de choses, non ?
Bon, bref, nous avons donc commencé à implémenter la possibilité de changer la taille des palettes et ce de manière indépendante à chaque palette.
Cela va demander de re-dessiner pas mal d'icônes et de reprendre les palettes une à une pour qu'elles acceptent ce facteur d'échelle à l'affichage.
|
|
|
| by Didier Guillion | |
|
| |
|
Aujourd'hui et pour finir la semaine nous avons amélioré les scripts d'importation Finale et Encore.
De petits problèmes ont été corrigés dans Harmony et PDFtoMusic.
Nous avons jeté un oeil sur le nouveau langage de programmation Open Source, lancé par Google, le Go.
La syntaxe semble simple et proche de ce que nous avons l'habitude de manipuler. C'est en fait assez ressemblant au C et rappelle le Lua par certains aspects. Mais, d'un autre coté, ce que nous recherchons dans un langage, c'est avant tout un environnement de développement convivial. Le meilleur des langages ne sera rien s'il n'est pas entouré d'un bon éditeur de texte, d'un gestionnaire de projet, d'un deboggeur efficace, d'outils d'analyse de la mémoire et des performances.
Pour l'instant, le Go ne semble pas répondre à cette demande, mais connaissant la vitesse à laquelle Google est capable de progresser cela peut évoluer très vite. Nous restons donc très attentif...
|
|
|
| by Didier Guillion | |
| |
|
Nos principaux projets (Harmony, Melody, PDFtoMusic, Myriad Plug-in, Melody Player...) sont maintenant totalement fonctionnels avec le nouveau compilateur.
Les tests de vitesse effectués, tant au niveau de la vitesse de compilation que de la vitesse d'exécution de l'application générée, sont à vue de nez concluants, ça va suffisamment vite.
Nous y avons pour l'instant un peu perdu en ergonomie de travail, mais nous continuons à chercher les fonctionnalités manquantes dans les coins. Par exemple, impossible de trouver dans Visual C/C++:
- Une recherche multi-fichiers qui présente tous les résultats d'un coup et qui permette d'y naviguer rapidement
- Une comparaison de deux fichiers "source", permettant de voir rapidement ce qui a bougé dans un module depuis la dernière sauvegarde. Si cela n'existe pas dans Visual, on doit pouvoir s'en tirer avec un programme indépendant, si ce dernier existe.
- Lors du débogage, un moyen simple de visualiser un tableau d'éléments sur lequel on possède un pointeur. Nous avons pu trouver une fonction non documentée de Visual qui le permet, mais ce n'est ni très pratique, ni sécurisant, une fonction non documentée pouvant être abandonnée dans une prochaine version.
- Possibilité de démarrer un projet avec, dans tous les panneaux de réglage, les options par défaut que nous aurons choisies. Ca, ce soit être possible, nous continuons à chercher.
- Le moyen d'utiliser l'option qui produit des calculs rapides sur les nombres à virgule (/Fp:fast). L'option existe mais nos tentatives pour l'utiliser se sont soldées jusque-là au mieux par un blocage infini de l'éditeur de lien, au pire par un crash de Visual C. Pourtant, ce serait bien de voir si elle accélère les calculs (Virtual Singer, tracés graphiques, calculs de PDFtoMusic, etc)
Donc, dans l'ensemble, tout va bien, mais on continue à polir les détails. Nous allons utiliser cette application 8h par jour, autant la rendre la plus confortable possible pour notre usage. |
|
|
| by Olivier Guillion | |
|
| |
|
La recompilation de PDFtoMusic / PDFtoMusic Pro sous Visual C/C++ a été assez fastidieuse, car PDFtoMusic, plus que tout autre de nos logiciels, utilise de petits bouts de nos applications et les mixe ensemble, en mélangeant du C pur et du C++.
Par exemple, la lecture audio des partitions provient de modules d'Harmony Assistant (langage C), leur affichage est un tracé des commandes PDF (langage C++), l'affichage des bulles d'aide est repris sur celui des didacticiels vidéo (C), etc.
Au final, tout cela a finit par vouloir tourner ensemble. Mis à part quelques fonctionnalités non diffusées au public, nous permettant de déboguer le programme, tout tourne correctement.
En parallèle, nous avons continué à corriger les problèmes signalés:
Harmony Assistant : Correction d'un problème d'extraction de nom de police de caractère dans le script d'import Finale pour le format ETF 1998.
PDFtoMusic : meilleure gestion des barres de mesure doubles
PDFtoMusic : gestion des numéros de mesure forcés |
|
|
| by Olivier Guillion | |
| |
|
Correction de l'exportation du caractère "<" dans les paroles en MusicXML.
Correction de l'interface en Néerlandais de Melody Player |
|
|
| by Didier Guillion | |
| |
|
Nous avons traité les retours de la version beta de PDFtoMusic et avons corrigé quelques problèmes signalés.
Nous avons également entamé la recompilation sur le nouveau compilateur de PDFtoMusic / PDFtoMusic Pro, deuxième gros programme après Harmony.
Etant donné que nous n'avons pas trouvé moyen de récupérer les fichiers "projets" de l'ancien compilateur, qui contiennent la liste des modules à compiler et leurs options, nous n'avons pas eu d'autre choix que d'aller récupérer un à un les 259 modules qui composent PDFtoMusic et les ranger dans l'arborescence recréée à l'identique.
Un travail passionnant et créatif s'il en est, qui rappelle un peu Charlot dans "les temps modernes".
Les prochaines versions beta, compilées avec Visual C, vont être extrèmement importantes. Nous nous sommes en effet rendu compte que les petites incompatibilités pouvaient générer des effets quasi indétectables lors d'un test rapide mais très gênants dans le cadre d'une utilisation plus sérieuse.
Par exemple, lors de l'import des fichiers au format ABC, certaines altérations de l'armure à la clé n'étaient pas bien prises en compte, remplaçant des notes non altérées par des bécarres. La musique jouait donc tout simplement faux.
Cela a été corrigé, mais laisse à penser que le Poltergeist peut frapper n'importe où, et que des tests intensifs seront nécessaires pour débusquer ce type de problème. |
|
|
| by Olivier Guillion | |
|
| |
|
Nous avons reçu plusieurs rapport sur la béta en cours de PDFtoMusic PRO. Nous avons passé une partie de la journée à les analyser et à déterminer si cela nécessitait une modification de l'application ou simplement un paramétrage particulier du mode expert.
Sinon, le portage sous Microsoft C avance petit à petit... C'est fou le nombre de projets que l'on peut accumuler au fil des années.
Un utilitaire que nous utilisons tous les jours et qui permet de "prototyper" automatiquement nos fichiers C a été écrit en 1986. C'est notre plus vieil utilitaire "maison".
|
|
|
| by Didier Guillion | |
| |
|
Nous avons eu à résoudre aujourd'hui un problème intéressant:
Pour la reconnaissance des caractères musicaux, PDFtoMusic utilise un fichier, que nous appelons filtre, qui permet de déterminer, par comparaison avec des dessins prédéfinis, à quoi ressemble le plus un caractère musical.
Par exemple, une série de clé de sols, de clés de fa, de têtes de notes, etc, appelés symboles modèles, sont traités par un programme, qui construit le filtre. Ensuite, lorsqu'un symbole musical est trouvé dans une partition, il est comparé à ces symboles modèles et on en déduit de quoi il s'agit.
Parfois, il y a une erreur flagrante (par exemple, un # que le programme croit être une tête de note) qui nuit à la reconnaissance d'un ou plusieurs PDF. Dans ces cas-là, il faut isoler cette nouvelle version du #, l'ajouter à la liste des symboles # modèles, puis recalculer une nouvelle version du filtre et la diffuser.
Mais, en faisant cela, qui nous dit que le nouveau filtre ne génèrera pas des erreurs sur des fichiers qui étaient jusque-là bien reconnus, et que des têtes de notes ne seront pas maintenant improprement prises pourt des #?
Afin de minimiser ce risque, nous avons donc mis en place une nouvelle procédure. Lors de l'utilisation courante d'une version du filtre sur nos ordinateurs, nous constituons une base de données de tous les symboles musicaux traités, accompagné du résultat de la reconnaissance par le filtre. Nous balayons tous les fichiers PDFs que nous possédons afin d'obtenir une base la plus complète possible.
Lorsque nous recalculons une nouvelle version du filtre, nous vérifions que le résultat de la reconnaissance de chacun de ces symboles n'a pas été modifiée. Lorsqu'elle l'est, nous affichons l'ancien résultat et le nouveau. S'il y a dégradation, nous ajoutons le symbole problématique à la liste des symboles modèles et recalculons à nouveau le filtre, jusqu'à ce qu'il n'y ait plus d'erreur.
Ceci devrait grandement diminuer les risques de déterioration des résultats de PDFtoMusic suite à une mise à jour. |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui nous nous sommes consacrés à PDFtoMusic.
Meilleure prise en compte dans l'OCR des caractères musicaux aux jambages fins
Correction de la reconnaissances des # et des appogiatures sur certains fichiers
PDFtoMusic/Harmony Assistant: une petite fuite de mémoire lors de l'affichage des boîtes d'alertes a été colmatée.
PDFtoMusic / Harmony Assistant, import XML : lorsqu'un ornement était inséré sur un accord, l'accord était joué arpégé. Ceci a été corrigé.
Ceci a abouti à la génération d'une béta pour la version PRO qui a été annoncée sur le Forum.
|
|
|
| by Didier Guillion | |
| |
|
Petit à petit, nous continuons la recompilation de tous nos projets. Après Harmony Assistant et Melody Assistant (incluant Virtual Singer), c'est maintenant le tour de Melody Player.
Les deux Assistants et le Player ainsi que le plug-in sont à 90% constitués des mêmes modules. Simplement, un bon paquet, tous ceux qui se rapportent à l'édition de la partition, sont désactivés dans le player et le plug-in, et remplacés par la gestion de l'interface propre à ces deux programmes. Il apparaît que le nouveau compilateur est beaucoup plus sourcilleux en matière de "dépendances" de chaque module, et a trouvé plus de 2000 endroits où il considère (à tort) qu'il pourrait y avoir un problème.
Nous sommes donc condamnés à modifier les fichiers source afin qu'il les avale sans crier. Allez, plus que 200 ! 
En parallèle, sur Macintosh nous continuons à corriger et améliorer le programme :
Le tag "URL" dans les textes libres a été étendu aux objets libres de type texte. Comme $L avait déjà une signification dans ce cas, il est devenu $W.
Dans Melody Player, il est maintenant possible de changer la langue de l'interface directement depuis l'application.
Nous continuons à travailler sur la version Néerlandaise du Melody Player. |
|
|
| by Olivier Guillion | |
| |
|
|
