Aujourd'hui nous avons travaillé notamment sur la manière de gérer des vues en MyrScript, le langage de programmation intégré à Harmony Assistant.
Il fallait permettre de gérer tous les paramètres des vues, et d'altérer le contenu de chacune des vues, sans que les programmes déjà écrits en MyrScript ne nécessitent d'être repris.
Nous avons donc opté pour une solution relativement simple, mais qui ne permet pas de travailler extrèmement facilement sur plusieurs vues simultanément : la gestion d'une "vue courante", qui conditionne toutes les opérations effectuées ensuite sur les paramètres auxquels on accède.
Par exemple, pour faire apparaître la première portée du conducteur dans la première vue partielle, il faudra écrire quelque chose comme:
-- L'index 1 correspond à la vue générale
-- et l'index 2 à la premiere vue partielle
vue=score.Views[2]
-- Fixe la vue courante
score.SetCurrentView(vue)
-- A partir d'ici on travaille sur la vue n°2 (1e vue partielle)
score.FirstStaff.IsPrinted=true
-- La 1e portée est maintenant visible dans cette vue
Le système a l'air de bien fonctionner, et d'être relativement simple d'emploi.
Seule contrainte, lorsqu'on veut recopier un certain nombre de paramètres d'une vue sur une autre, il vaut mieux fixer la 1e vue comme vue courante, copier tous les paramètres désirés dans des variables locales, puis fixer la 2e vue comme vue courante et recopier les variables locales dans la 2e vue, plutôt que de passer d'une vue à l'autre à chaque paramètre.
Il ne reste plus qu'à mettre en place la création, suppression et déplacement de vue, et MyrScript devrait alors être complet sur ce point. |
|
|
| by Olivier Guillion |  |
|
| |
|
Plusieurs améliorations ont été finalisées ou entamées.
- La possibilité de couper les barres d'accroche sous les crochets de tuplets a été finalisée, laissant toute latitude dans les découpes possibles :
- Les appoggiatures en accord ont été mises en place. C'est encore à l'état de prototype, mais ces appoggiatures peuvent d'ores et déjà être affichées et jouées :
- Il nous avait été demandé, lorsqu'on copie/colle un groupe de note et que l'option d'accroche automatique est désactivée, que les barres d'accroche restent identiques à ce qu'elles étaient à l'origine, sans modification. Cela est malheureusement impossible, car les tiges de notes marquées "automatique" vont se recalculer en fonction de la position des notes collées sur la nouvelle portée. Et si certaines tiges changent de sens, les groupes de notes accrochées vont créer un résultat très étrange.
Alors, nous avons mis en place ceci:
les accroches ne sont recalculées que si la portée sur laquelle on colle n'est pas de même type que celle depuis laquelle on a copié les notes.
Ainsi, si on copie et on colle sur une portée en clé de sol, les accroches resteront identiques. Par contre, si on copie depuis une portée en clé de sol et qu'on colle sur une portée en clé de fa, les accroches risquent de se recalculer. |
|
|
| by Olivier Guillion | |
|
| |
|
Après avoir examiné les alternatives aux pilotes Twain sur Macintosh, nous avons fait de même sur Windows.
D'après ce que nous avons compris, c'est plus compliqué mais pas nécessairement mieux.
Au tout début, chaque constructeur de scanner fournissait le logiciel d'acquisition spécifique. Puis très rapidement, tout le monde s'est mis à la norme TWAIN.
Ensuite, à partir de Windows 98, Microsoft a introduit StillImage, une architecture de pilote permettant de gérer scanners, appareils photos, et tout autre périphérique permettant de produire une image fixe. Ces pilotes sont censés permettre un plus grand contrôle de l'interface graphique du pilote (boites de saisie, de configuration du scanner) dans un format normalisé. Et surtout, un pilote StillImage peut lancer l'application qui traite son acquisition d'image, alors que pour le TWAIN, c'est à l'application de demander au scanner.
Par exemple, c'est grâce à StillImage que lorsque vous appuyez un bouton sur votre scanner, cela peut lancer l'application d'acquisition correspondante.
TWAIN est donc considéré comme "obsolète" par Microsoft, mais il est demandé aux développeurs de pilotes de conserver la compatibilité.
Donc, les pilotes compatibles StillImage sont censés offrir également un accès compatible TWAIN. Et c'est apparemment le cas.
De toute façons, StillImage n'est disponible que sur Windows 98, ME, XP et probablement Vista, et absent de 95, NT et 2000. Mais d'autres sources le donnent disponible pour 95, 98 et 2000.
Puis, histoire de simplifier tout cela, Microsoft, avec Windows Millenium (donc deux ans après StillImage) a sorti le "standard" WIA (Windows Image Acquisition), qui semble être une surcouche à StillImage.
Là aussi, un pilote WIA est censé assurer une compatibilité TWAIN.
WIA serait disponible sur Windows ME et XP, probablement Vista, et absent de 95,98, 2000 et NT.
Donc, en conclusion, tous ces nouveaux types de pilotes, même s'ils pourraient faciliter l'acquisition d'images, ne sont pas disponibles sur tout les systèmes, et tous les constructeurs ne les ont peut-être pas adoptés.
Donc, plutôt que d'écrire, dans ScanToMusic, un module d'acquisition TWAIN, un autre pour StillImage et un autre pour WIA, avec un test de présence de chacune de ces technologies, il est apparemment plus facile et plus sage de s'en tenir au TWAIN, même s'il peut apparaître un peu spartiate.
Les trois technologies ayant un noyau commun, le TWAIN, on est donc à peu près assuré de respecter une compatibilité maximale en utilisant celui-ci. |
|
|
| by Olivier Guillion | |
| |
|
Nous avons commencé à regarder comment gérer le pilotage des scanners directement depuis le logiciel.
L'expérience OMeR nous avait montré que l'utilisation des accès aux pilotes à la norme TWAIN faisait souvent apparaître des problèmes de compatibilité.
Les pilotes, souvent assez mal écrits, ne suivent quasiment jamais les spécifications complètes de la norme. Ils sont testés par les constructeurs sur les logiciels ténor du marché de l'infographie, et apparemment débuggés spécifiquement sur ceux-ci.
Cela veut dire en gros que si votre logiciel n'accède pas exactement aux mêmes fonctions du pilote du scanner, ou pas dans le même ordre que Photoshop, vous prenez le risque de rencontrer quelques problèmes sympas, qui ne surviendront par exemple qu'avec la version 3.94 du pilote du scanner Agfanon SuperFine 1293 S. 
Sur Mac OS X, le principe annoncé du système est de s'affranchir au maximum des accès direct au périphériques et d'offrir au développeurs des interfaces de haut niveau permettant de piloter les périphériques, par exemple, les scanners.
Nous avons donc téléchargé le kit "Image Capture", présenté comme un sur-ensemble au TWAIN. Cela semblait alléchant, documentations, exemples en Carbon et Cocoa d'acquisition depuis un scanner, tout le toutim. Le kit gère lui-même l'interface d'acquisition et obtenir une image est des plus simple pour le développeur : un simple appel à ICAImportImage et Mac OS X gère les paramètres d'acquisition, la prévisualisation, le choix de la source.
Magnifique ! En théorie... Car les applications d'exemple fournies ne fonctionnent pas et datent de 2005.
Une recherche sur l'Internet montre que les problèmes sont évidents et signalés par tous les développeurs. Sans aucun correctif d'Apple. Il faut dire que le développement d'IPod et d'IPhone a du les épuiser, les pôôvres.
Donc sur Mac OS X nous en resterons aux accès basiques au TWAIN, faute de mieux. |
|
|
| by Olivier Guillion | |
| |
|
Le développement de ScanToMusic a repris. Une réorganisation complète des fichiers "source" de l'application a été entamée, afin de classer les différentes fonctions par thème.
Cela devient obligatoire lorsqu'un projet grossit, afin de nous permettre de trouver rapidement l'endroit où chercher telle ou telle fonction lorsque nous avons besoin de l'améliorer ou de la débugger.
Pour donner une idée, un projet comme Harmony Assistant est consitué de près de 700 fichiers source, et PDFtoMusic d'environ 250.
Dans ScanToMusic, nous allons essayer de réutiliser au maximum le temps déjà investi dans PDFtoMusic. Toute la partie d'analyse de "haut niveau" de ce dernier, qui, à partir des commandes graphiques trouvées dans un PDF, reconstitue une partition éditable, va resservir.
Le problème se résume donc ainsi : à partir d'une page scannée, recréer une collection de commandes graphiques (basiquement, tracé de ligne, affichage de caractère et affichage d'image) qui aurait pu être utilisée pour créer la page. En fait, "vectoriser" l'image scannée, mais de manière logique compte tenu des règles d'écriture musicale.
Cela réduit le problème à sa portion congrue, mais ne le résout pas pour autant. Il faut maintenant attaquer les divers modules de détection/reconnaissance qui manquent, et améliorer ceux qui ont été déjà écrits. |
|
|
| by Olivier Guillion | |
|
| |
|
Nous avons travaillé sur des améliorations de la mise en page. Certains changements que nous avons apportés pourront changer la taille des mesures, donc modifier la disposition sur le papier de documents créés avec les versions précédente.
- Les tailles du couple de mesures affectées à un signe de répétition des deux mesures précédentes ont été réglées de manière à obtenir deux mesures de égales. Ceci peut changer la taille d'une ligne de mesures, donc générer des retours à la ligne là où il n'y en avait pas auparavant.
- Lorsque des altérations étaient écrites entre parenthèses, la taille des symboles de parenthèses n'était pas prise en compte dans les calculs permettant d'éviter le chevauchement des symboles. C'est maintenant chose faite, mais cela peut entraîner un changement dans la mise en page de ces mesures.
- Enfin, le paramétrage du mode gravure lors d'un export MYR depuis PDFtoMusic / PDFtoMusic Pro a été corrigé. Les fichier .myr qui seront exportés avec la nouvelle version, une chargés dans Harmony Assistant, se retrouveront en mode gravure, avec les paramètres par défaut. Donc avec la prochaine version de PDFtoMusic, si vous exportez un fichier que vous aviez déjà traité auparavant, son aspect graphique sous Harmony Assistant sera différent.
|
|
|
| by Olivier Guillion | |
|
| |
|
On nous a fait remarquer que la police de caractères utilisée pour montrer les résultats de la reconnaissance n'était pas celle du document original.
En effet, le résultat de la reconnaissance est destiné à montrer le texte qui a été déterminé par l'analyse, et nous avions considéré que l'afficher en police "Times" était suffisant.
Mais, pour l'export XML ou Harmony, le programme choisit une police "standard" qui est supposée être proche de la police originale, encapsulée dans le document PDF. Donc, utiliser cette information dans l'affichage des résultats de la reconnaissance était possible, et permettait d'obtenir un meilleur aspect.
A partir d'un PDF qui contient ceci :
la version actuelle montre ceci :
alors que la prochaine version montrera cela :
ce qui "colle" beaucoup plus à l'aspect original. |
|
|
| by Olivier Guillion | |
|
| |
|
|
