lilypond-user-fr
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Du nouveau au sujet de ly2xml?


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.

Attachment: log-parts.ly
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]