Ce Workshop, parrainé par neoScores, a permis à Michael Good, à l’origine du standard, de présenter les dernières nouveautés de son dialecte XML dédié aux partitions musicales.
Table des matières
Nouvelles applications supportant MusicXML
Après avoir rappelé les fondamentaux sur MusicXML (voir Tutoriel MusicXML), Michael Good a commencé par faire l’état des lieux des dernières applications supportant le langage.
En termes de logiciels de composition, NoteWorthy composer a fait son apparition.
Comme logiciels capables de sauver des partitions au format MusicXML à partir de leur représentation interne, il a cité LogicPro, NotateMe et Cadencii.
Les nouveaux readers quant à eux sont Avid Scorch, Frescobaldi (front-end de Lilypond), et JellyNote (en bêta).
Il a aussi évoqué une expérimentation nommée « Quantified Artist » récemment présentée au salon SXSW d’Austin. Un clarinettiste équipé de capteurs biométriques a interprété une pièce de musique chambre. On a pu voir en temps réel comment son corps réagissait aux différentes compressions des poumons. Le suivi de la partition s’affichait sur le même écran, à partir d’une partition stockée dans le système en MusicXML.
MusicXML et fontes musicales
La problématique est la suivante : Pour un même fichier MusicXML, le rendu, la restitution de la partition sous forme graphique peut varier selon les différents logiciels utilisés.
En effet, on ne dispose pas aujourd’hui pas de standardisation de la façon dont ces différents symboles doivent apparaître.
Il existe aujourd’hui un certain nombre de fontes musicales. La première a été Sonata d’Adobe (1985) avec 176 glyphes. Cette fonte est devenue un standard de fait pour Petrucci (Finale) et Opus (Sibelius).
Il existe également une fonte de 220 symboles Unicode.
Le manque de standard fait que le partage des partitions entre différentes applications est difficile.
SMuFL (Standard Music Font Layout) http://www.smufl.org/, mis au point chez Steinberg par Daniel Spreadbury a pour ambition de standardiser ces fontes.
Une fonte compatible avec SMuFL contient des méta-données exprimées en JSON, qui permettent de restituer le dessin d’un des glyphes défini dans SMuFL.
SMuFL propose à ce jour 2554 glyphes propres. Plus les 220 glyphes d’Unicode.
SMuFL propose aussi une recommandation pour les ligatures.
Steinberg dispose aujourd’hui d’une première fonte nommée Bravura, qui est disponible en implémentations OpenType, SVG et WOFF (Web Open Font Format). Cette fonte permet d’afficher les glyphes préconisés par SMuFL, et quelques autres.
SMuFL en est à la version 0.8 et la version 1.0 est attendue pour mi-2014.
Après la v1.0, les graphiques et les noms des glyphes ne devraient plus changer.
SMuFL est supporté par LilyPond via openLilyLib et sera bientôt dans MuseScore 2.0
La fonte Bravura est déjà intégrée dans des produits comme RisingSoftware.
D’autres fontes sont en cours, y compris une fonte Jazz.
Intégration de MusicXML 4.0 et de SMuFL 1.0
MusicXML doit-il s’intégrer avec SMuFL 1.0 et supporter ainsi des milliers de glyphes ?
Il a été discuté de certaines difficultés comme le fait que certains glyphes pourraient/devraient être légèrement différents selon le contexte d’emploi.
Michael Good a également voulu savoir si on devait inclure dans MusicXML des glyphes qui ne correspondent à aucun élément déjà représentés dans MusicXML.
Enfin, des remarques ont été faites pour signaler que le dessin restitué par les fontes devait bien prendre en compte les possibilités de l’affichage réel.
MusicXML et MMA/AMEI
Ces deux organisations internationales, la MIDI Manufacturers Association (MMA) et l’ Association of Musical Electronics Industry (AMEI) sont leaders dans l’intéropérabilité musicale entre les différentes générations d’équipements.
L’AMEI pense que MusicXML a un bon avenir commercial, et s’intéresse également aux eBooks et aux travaux du W3C.
Mais il y a d’autres standards en cours : L’ISO a un standard de e-score mais il est non utilisé. De même pour l’IEEE.
MMA et l’AMEI seraient les seules organisations de standards, susceptibles d’intégrer MusicXML quand il sera mûr, comme cela a été le cas pour l’adoption du PDF par l’ISO.
Michael Good s’est donc interrogé pour savoir si ces organisations seraient adaptées pour héberger peut-être ce futur standard.
A suivre, donc …