La version 1.0.4 a été publiée récemment et nous sommes déjà en train de réfléchir à la prochaine version. Des partitions très intéressantes nous ont été proposées : composées uniquement de lignes de batteries elles ne sont pas reconnues par PDFtoMusic. Nous allons travailler dans ce sens. Du coté du MusicXML, la prochaine version (2.0) est en chantier, nous avons commencés à essayer de transformer certaines de nos extensions à la norme. Déjà, il est possible de définir le numéro de page d'affichage des textes libres, mais les pages réservées (sans musique), comme par exemple une page de garde textuelle en début de la partition, ne sont pas encore fonctionnelles. La gestion des images, dans la prochaine version du MusicXML ne se fera pas comme dans les fichiers PDF ou les documents Word (ou les fichiers .myr d'ailleurs), où les images sont directement embarquées dans le document mais sous forme de lien sur un fichier indépendant, comme dans les fichiers HTML par exemple. C'est, à notre avis, une erreur de choix. Dans la plupart des cas, l'utilisateur inexpérimenté, enverra le fichier principal et oubliera les fichiers annexes. L'utilisateur plus aguerri va se retrouver pour un seul document avec plusieurs fichiers qu'il va devoir organiser lui-même (dans un sous-dossier ?) De plus, aucun format de fichier image n'est recommandé, je vois mal Harmony embarquer une librairie PNG, JPG, TIFF, etc... pour pouvoir lire les différents formats. Enfin, voilà plusieurs années que nous demandions une version compactée des fichiers MusicXML et nous avions anticipé en proposant dès Janvier un compactage simple des fichiers MusicXML (rappelons que c'est du texte et que des algorithmes efficaces existent depuis belle lurette). Las ! Là aussi, à la solution simple, la complexe et bien lourde à été choisie : le format Zip. Là aussi, je vois mal Harmony embarquer un Zippeur/Dézippeur complet... |
|
|
by Didier Guillion | | | |
| Comments
Concernant les formats des images, cela me paraît logique que MusicXML ne se prononce pas sur un format privilégié. C'est une question plutôt annexe (la plupart des partitions n'ont pas d'image), et on ne voit pas pourquoi ils opteraient pour un format plutôt qu'un autre. Autant laisser le consensus se faire tout seul. S'il ne se fait pas, cela signifie simplement qu'il y a des des logiciels qui ne sauront pas afficher certaines images produites par d'autres logiciels. Ce n'est pas si gênant que ça. De ce point de vue, c'est plutôt une bonne chose que l'image soit dans un fichier séparé, car de cette façon l'utilisateur pourra changer son format à l'aide d'un Photoshop quelconque. Si l'image était incluse dans le fichier, cela ne serait pas possible. A ce propos, comment gère-t-on les pistes sonores dans MusicXML ? Cela devrait aussi être des fichiers séparés. Pour le dézippeur, a priori cela paraît logique d'opter pour un format standard. Mais une recherche sur le Web montre que la compression du XML est un sujet "chaud", et que chacun y va de sa petite solution. Dans ce cas, effectivement, choisir un outil de compression simple aurait été préférable. Mais peut-être les concepteurs de MusicXML se sont dit que tous les utilisateurs possèdent un logiciel de compression / décompression du format zip, et donc que si le logiciel musical ne sait pas décompresser, l'utilisateur le fera séparément. |
|
|
|
|
|