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 | |
| |
|
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 | |
| |
|
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 | |
| |
|
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 | |
|
| |
|
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 | |
| |
|
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 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 | |
| |
|
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 | |
| |
|
|
