|
From: | Jean Abou Samra |
Subject: | Re: Du nouveau au sujet de ly2xml? |
Date: | Sun, 16 May 2021 20:35:00 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
Le 16/05/2021 à 17:39, Jacques Menu a écrit :
Jean, je te laisse préciser ce que tu m’as dit récemment quant à l'obtention, à partir de la description en Scheme de la musique dans Lily, des informations nécessaires pour la création de code MusicXML ou autre.
En simplifiant un peu, on peut considérer que la compilation d'un
fichier dans la sortie graphique (pas MIDI) se fait en trois
phases principales :
1. Analyse syntaxique et traitement de l'entrée par des fonctions musicales.
2. Traduction par des graveurs en un ensemble d'objets graphiques.
3. Calcul des sauts de ligne, positionnement et dessin des
objets.
Jusqu'ici, les tentatives (restées modestes) d'implémentation d'un export MusicXML sont restées cantonnées à la phase 1.
C'est une approche fort limitée. En effet, les objets musicaux sont très proches de la saisie de l'utilisateur, et ne contiennent aucune information ni sur la temporalité de la musique, ni sur le positionnement, par exemple la direction des hampes, ou bien la configuration des barres de ligature.
Il faudrait donc commencer dans la phase 2, en introduisant :
- un nouveau type de définitions de sortie, en complément de \layout { } et \midi { }, nommé par exemple \xml { },
- un nouveau genre de traducteurs, en plus des graveurs (engravers) et des interprètes (performers), appelé, disons, exportateur (exporter).
Les exportateurs devraient être liés aux graveurs, car ils s'intéressent au placement. Les graveurs sont construits selon un système où chaque étape temporelle comporte deux phases :
- l'écoute de la musique, et la création d'objets graphiques en réaction,
- l'observation des objets créés par d'autres graveurs.
Il faudrait que les exportateurs s'insèrent dans ce système, en créant, pour leur part, un type différent d'objets (nodes ?), servant spécifiquement à la sortie MusicXML. De plus, ils devront observer à la fois les grobs et les nodes.
Mais ce n'est pas tout. Le positionnement n'est pas connu lors de
la traduction, qui doit seulement servir à mettre les nodes en
place. Pour finir, j'imagine que les nodes pourront être munis de
fonctions de rappel (callbacks) de la même manière que les grobs,
pour accéder aux ligatures, sauts de page, etc., et remplir ainsi
leur jeu de propriétés avant écriture du MusicXML.
Est-ce que c'est le type d'informations que tu attendais ? Je ne
suis pas sûr d'avoir bien compris la question…
En tous cas, inutile de dire que cela représente un travail faisable, mais important.
Amicalement,
Jean
PS : En pièce jointe, un graveur simple qui montre comment on
peut accéder à l'information musicale. Il rend compte
rudimentairement du flux musical sur la console.
log-parts.ly
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |