Représentation de la musique

Le format de saisie idéal pour un système évolué de formatage consiste en la description abstraite du contenu. Dans le cas qui nous occupe, il s’agit tout bonnement de la musique. Cela n’est pas sans poser un énorme problème : comment définir ce qu’est la musique ? Pour résoudre ce problème, nous l’avons inversé. Au lieu de définir ce qu’est la musique, notre programme sert de définition : nous avons écrit un programme capable de produire des partitions, et avons ajusté son format de saisie pour être aussi léger que possible. Lorsque le format ne peut plus être simplifié, nous avons par définition atteint le contenu même. Autrement dit, notre programme utilise la définition formelle d’un document musical.

La syntaxe est également celle de l’interface utilisateur de LilyPond, puisqu’elle peut être facilement tapée au clavier :

{
  c'4 d'8
}

sont un do médium noire et un ré croche juste au-dessus.

[image of music]

À petite échelle, une telle syntaxe est pratique. À plus grande échelle, une structuration est nécessaire. Sans cela, comment saisir des pièces aussi complexes qu’un opéra ou une symphonie ? La structure est construite selon le même concept que les expressions musicales : c’est en combinant de petits fragments qu’une musique plus complexe peut être représentée. Par exemple :

f'4

[image of music]

Quand des notes sont combinées simultanément, il suffit de les insérer entre << et >> :

<<c4 d4 e4>>

[image of music]

Insérées dans une paire d’accolades { … }, ces expressions sont intégrées dans une séquence :

{ f4 <<c4 d4 e4>> }

[image of music]

Ceci constitue une nouvelle expression, qui peut être à son tour combinée avec une autre expression simultanée (en l’occurrence une blanche) à l’aide de <<, \\ et >> :

<< g2 \\ { f4 <<c4 d4 e4>> } >>

[image of music]

De telles structures récursives peuvent être définies formellement et de manière ordonnée avec une grammaire libre de tout contexte. Le code d’analyse de la saisie est également généré depuis cette grammaire. Autrement dit, la définition de la syntaxe de LilyPond est claire et sans ambiguïté.

Ce sont la syntaxe et l’interface qui concernent les utilisateurs. Elles sont sujettes à discussion, puisque relatives aux goûts de chacun. Bien que ces discussions soient intéressantes, elles ne sont pas productives. À l’échelle de LilyPond, l’importance du format de saisie est minime : inventer une syntaxe claire est bien plus aisé qu’écrire un code de mise en page décent. Ceci est d’ailleurs illustré par le nombre de lignes de code de ces composants respectifs : l’analyse du texte de saisie et sa représentation pèsent moins de 10 % du code.

Dans la conception des structures utilisées par LilyPond, nous avons pris certaines options divergentes des autres logiciels. Considérons la nature par essence hiérarchique de la notation musicale :

[image of music]

Nous y voyons des hauteurs regroupées en accords appartenant à des mesures elles-mêmes rattachées à des portées. On pourrait représenter cela par un système de boîtes imbriquées :

nestedboxes

Cette structure est cependant réductrice car reposant sur des postulats extrêmement restrictifs. Cela devient plus évident dès lors que la musique se complique :

[image of music]

Ici, les portées débutent et s’arrêtent n’importe où, les voix passent d’une portée à l’autre, et parfois même occupent deux portées. Nombre de logiciels auront d’énormes difficultés à reproduire cet exemple, pour la bonne et simple raison qu’ils se basent sur le modèle hiérarchique de boîtes imbriquées. LilyPond, quant à lui, tend à préserver la dichotomie entre le format de saisie et une structure aussi flexible que possible.


Essai sur la gravure musicale automatisée v2.25.22 (development-branch).