Re: Du nouveau au sujet de ly2xml?

[Jacques Menu]

Bonsoir Jean,

Désolé pour les lecteurs qui vont trouver ce message rébarbatif…

Comme je te l’avais dit, j’avais demandé, lors de ma présentation à Salzburg, s’il existait dans le flot de tâches exécutées par LilyPond un endroit où se raccrocher pour aborder ça. Personne ne semblait avoir de réponse à ce moment-là. Je suis heureux que tu nous en apportes, tu as bien compris ce que je demandais.

Quitte à faire du gros boulot, il serait effectivement de loin plus porteur de travailler à un export de Lily vers d’autres représentations des partitions que de créer un outil pour fusionner des fichiers MusicXML.

Comme je ne connais pas, tant s’en faut, le détail de ce que fait Lily, et que ça serait contre-productif que je m’y investisse, je pourrais colloborer avec quelqu’un qui aurait cette connaissance. Tu me sembles donc être le volontaire tout désigné!

L’approche consisterait à créer une description LPSR (LilyPond Score Representation) de la partition par un exporteur. Il faudrait voir ce qui devrait être écrit en Scheme et en C++ respectivement. 

C’est ce LPSR que xml2ly construit pour ensuite produire le code LilyPond à partir de ça, voir l’architecture à la page 2 de https://github.com/jacques-menu/musicformats/blob/dev/doc/musicformatsArchitecture/musicformatsArchitecture.pdf .

Pour illustrer comment la partition est décrite dans LPSR, je joins l’exemple d’une partition minimale, mais avec quand même différents aspects présents :

Il y a le source MusicXML et le log de sa conversion en LilyPond par la commande :

xml2ly -auto-output-file-name  basic/MinimalScore.xml -display-lpsr

Les numéros de lignes sont ceux des éléments dans le fichier MusicXML.

On voit dans le log les deux composants de la description LPSR : le premier est la musique (composant MSR), et le second tout à la fin ce qu’il faut en plus pour structurer la partition comme on le fait en LilyPond :

  Book blocks

  

    BookBlock

    

      BookBlockElements

        ScoreBlock

        

          ParallelMusicBLock, 1 part group

            

            PartGroupBlock for partGroup "PartGroup_1 ('0', partGroupName "Implicit")", partGroupSymbolNone, 1 element

            

              PartBlock for part Part_POne (partID "P1"), 1 element

                partName                     = ""

                partAbbreviation             = ""

                partBlockInstrumentName      = ""

                partBlockShortInstrumentName = ""

                

                StaffBlock for staff "Part_POne_Staff_One" (staffRegular), 1 element

                  (StaffBlockInstrumentName       = "")

                  (StaffBlockShortInstrumentName  = "")

                  

                  UseVoiceCommand "Part_POne_Staff_One_Voice_One", 0 stanza

          

          Layout

            layoutGlobalStaffSize : 20

          

          MidiTempo

            midiTempoDuration  = 4

            midiTempoPerSecond = 90

Je suis en train de documenter progressivement comment tout cela est fait.

Donc pour résumer : si on peut créer cette description LPSR depuis LilyPond par un exporteur, on a directement la conversion en MusicXML, Guido et braille. MIDI n’est pas encore disponible, mais j’ai déjà avancé dans cette direction.

Les nodes que tu proposes correspondraient à des msrElement de mon côté.

Par exemple, pour créer dans le composant MSR de la description LPSR une note avec un pp, comme :

a'8 \pp

on écrirait le code C++ ci-dessous, ou son équivalent en Scheme :

      // create the note

      S_msrNote

        note1 =

          msrNote::createRegularNote (

            __LINE__,

            measure1number,

            msrQuarterTonesPitchKind::kQTP_A_Natural,

            msrOctaveKind::kOctave4,

            rational (1, 8), // soundingWholeNotes

            rational (1, 8), // displayWholeNotes

            0);              // dotsNumber

      // append the dynamics to the note

      note1->

        appendDynamicsToNote (

          msrDynamics::create (

            __LINE__,

            msrDynamicsKind::kDynamicsPP,

            msrPlacementKind::kPlacementBelow));

N’hésite pas si tu as des questions!

JM

MinimalScore.xml
Description: XML document

MinimalScore.ly
Description: Binary data

MinimalScore.log
Description: Binary data

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>