“L'obsession du papier encré”

Qu'est-ce qui se cache derrière LilyPond ?

LilyPond n'est pas le seul à faire de la notation musicale : il existe de nombreux programmes qui impriment de la musique, et la majorité des éditions récentes est générée par ordinateur. Cependant, n'importe quel musicien classique vous fera remarquer que les partitions d'aujourd'hui ne sont pas aussi jolies que les anciennes.

Qu'est-ce qui différencie le travail de l'homme de celui de la machine, à quoi cela tient-il ? Comment pouvons-nous améliorer cette situation ? Cet essai aborde les problèmes relatifs aux programmes de notation musicale et notre approche pour les résoudre.

Table des matières

Introduction : ce qui cloche dans la notation musicale informatisée ;
Ce qui ne va pas avec les logiciels, ou pourquoi Finale n'est pas la panacée en terme d'informatique musicale ;
Comment ne pas concevoir un logiciel, ou : modéliser la notation musicale ;
Diviser pour mieux régner, un modèle pour la notation automatisée ;
Impressionnant, mais que se passe-t-il en théorie ? Une approche pratique pour maîtriser la notation ;
Graver la musique, ou l'art d'imprimer des partitions ;
Implémentation de la typographie : les hackers s'attaquent aux problèmes de la gravure ;
Une architecture de programme flexible nous permet d'écrire un logiciel de gravure ;
Nombres de beauté : comment LilyPond participe au concours Miss Monde ;
Évaluation des performances : peut-on se contenter d'une architecture flexible ?
Fonctionnalités typographiques propres à LilyPond ;
Format source : comment saisir la musique ;
Conclusion.

Cet essai est aussi disponible en une seule page.

Qu'est ce qui cloche dans la notation musicale informatisée ?

Nous aimons qualifier LilyPond de « système de gravure automatisée ». Il mettra joliment en forme la notation musicale sans que l'utilisateur n'ait besoin d'être un expert en typographie.

LilyPond n'est pas le seul à réaliser de la notation musicale : il existe de nombreux programmes qui impriment de la musique, et de nos jours la majorité de la musique nouvellement imprimée sort d'un ordinateur. Malheureusement, ceci a une conséquence : n'importe quel musicien jouant de la musique classique vous dira que les nouvelles partitions ne sont pas aussi belles que les anciennes – disons, celles d'avant 1970 – celles d'aujourd'hui ont un aspect terne et mécanique. Elles sont vraiment désagréables à lire.

Pour illustrer ces propos, considérons les exemples suivants. Toutes deux sont des éditions de la 1^ère Suite pour violoncelle de J.S. Bach. Celle de gauche offre une très jolie édition de 1950 gravée à la main, alors qu'à droite se trouve un produit typique de l'informatique contemporaine. Arrêtez-vous quelques secondes sur chacune de ces pages pour bien vous imprégner de leur aspect. Laquelle préférez-vous, et pourquoi ?

L'image de gauche est jolie : ses lignes sont fluides et il y a du mouvement. C'est de la musique, et c'est vivant. Passons maintenant à l'image de droite, qui nous offre la même musique écrite par Bach, assurément pleine de vie et de fluidité... Néanmoins, la partition n'en laisse rien transparaître : elle a l'air rigide et mécanique. Afin de mieux comprendre de quoi il retourne, examinons de plus près un extrait de ces deux pièces :

fait à la main

fait par ordinateur

L'emplacement des barres de mesure est assez révélateur. Dans la nouvelle édition, les deux barres de mesure sont exactement alignées horizontalement. Il en va de même pour les notes. Si l'on revient à l'intégralité de la page, il est évident que presque toutes les barres de mesure sont alignées horizontalement, tout comme la plupart des notes. L'ensemble paraît espacé comme si tout était placé sur un quadrillage, provoquant cette impression mécanique.

Ce n'est pas la seule erreur de cet exemple et, de plus, cette pièce n'est pas la seule à comporter des erreurs typographiques. Malheureusement, presque toute la musique imprimée de nos jours est truffée de grossières fautes de typographie.

Les musiciens sont normalement plus concentrés sur la manière dont ils jouent la musique que sur son apparence, aussi ces pinailleries sur des détails de typographie peuvent paraître académiques. Ce n'est pas justifié. Cette pièce-ci a un rythme monotone. Si toutes les lignes se ressemblent, elles finissent par former un labyrinthe. Si le musicien la quitte des yeux ou se déconcentre un instant, il ne saura plus où il en est dans la page.

En général, c'est une caractéristique commune de la typographie. La présentation devrait être soignée, non seulement pour l'amour de l'art, mais plus spécialement parce qu'elle vient en aide au lecteur dans sa tâche. Pour du matériel d'interprétation tel que les partitions de musique, ceci est doublement important : les musiciens sont limités dans leur attention. Au moins leur attention se porte sur la lecture, au plus ils peuvent se concentrer sur l'exécution. En d'autres termes, une meilleure typographie se traduit par une meilleure interprétation.

Suite : Ce qui ne va pas avec les logiciels, ou pourquoi Finale n'est pas la panacée en termes de logiciel de musique.

Ce qui ne va pas dans les logiciels de notation musicale

Les ordinateurs ont rendu l'impression de la musique accessible au grand public, mais sont plutôt médiocres pour ce qui est de la typographie. Selon toute vraisemblance, les programmeurs ont fait un travail bâclé pour les logiciels de notation. Pour illustrer ceci, nous avons demandé à un utilisateur amateur de saisir un morceau de musique avec l'un des plus populaires programmes « professionnels » de notation vendus aujourd'hui, Finale 2003. Les réglages par défaut ont été utilisés. La musique est extraite de la Sarabande de la 2^ème Suite pour violoncelle de J.S. Bach.

(Finale est une marque déposée par MakeMusic! Inc.)

Cet exemple surpasse de loin ce que nous avons déjà vu en matière d'erreurs de mise en forme : en fait, des erreurs conséquentes sont présentes à chaque mesure. Ces erreurs sont de tout acabit : une faute monumentale est l ' e s p a c e m e n t d é m e s u r é de la dernière ligne. Une autre, moins importante, est le bémol de la mesure 13 recouvert par la note qui le précède. Voici un agrandissement de cette mesure :

Les erreurs se retrouvent jusque dans les plus infimes détails : ci-dessous un agrandissement du lien de cette mesure. Bien entendu les règles de bonne typographie voudraient que ce lien ne déborde pas de la hampe, et les cannelures mettent en évidence la maîtrise (ou son absence) des principes de la technologie PostScript par les programmeurs de Coda Music Technology.

Bien sûr, on peut réfuter que Finale dispose d'une interface graphique, qu'il vous permet de déplacer les éléments pour corriger des erreurs ou d'utiliser des greffons (plug-in) qui s'en chargeront. C'est certainement vrai : en fait, un bon graveur professionnel qui utilise Finale passera en réalité la plupart de son temps à corriger les fautes produites par Finale. Mais seriez-vous prêt à corriger des erreurs flagrantes à longueur de temps ? Pour ce qui est de la ligne à l'espacement démesuré, c'est faisable, mais imaginons qu'il faille corriger chaque partie de lien qui déborde d'une hampe... manuellement ?

Il y a une autre raison, moins évidente, pour laquelle corriger à la main n'est pas une si bonne idée. Revenons à cette mesure 13. Le bémol mal placé saute aux yeux, mais avez-vous remarqué quelque chose à propos de la barre de reprise ? Ses lignes sont trop espacées. Avez-vous vu que le demi-soupir est bien trop bas, et que la hampe de la dernière croche est trop longue ?

À moins d'être un expert, les fautes de typographie vous empoisonnent la vie sans vous sauter aux yeux. Nombre d'entre elles ne seront pas corrigées et subsiteront dans l'édition définitive.

Cet exemple peut sembler quelque peu exagéré, mais en réalité ce n'est pas le cas. Tous les grands producteurs de logiciel de notation prétendent se conformer aux standards de la gravure, mais aucun d'eux n'en maîtrise correctement les bases, et tous font des erreurs flagrantes. Pour juger du résultat de votre logiciel préféré, procurez-vous une partition convenable éditée par une bonne vieille maison, copiez-en une page, puis comparez-les :

Qu'en est-il de l'aspect général de la page ? La plupart du temps, les partitions informatisées ont un espacement plus large, de telle sorte qu'elles tiennent sur plus de pages et par voie de conséquence plus de tournes.
Qu'en est-il de l'espacement ? Est-ce aussi vivant et fluide que la partition gravée à la main ? En cas de doute, il suffit de mesurer à la règle.
Posons chacun des exemplaires sur un pupitre à un mètre, comme pour jouer en concert. Les deux sont-il parfaitement lisibles ? Pratiquement toutes les partitions informatisées ont l'air pâle : les lignes sont trop fines et les symboles trop clairs. C'est ce qui les rend difficiles à lire de loin. Si le doute persiste, il suffit de regarder à la loupe.

Suite : Comment ne pas concevoir un logiciel, ou : modéliser la notation musicale.

Les pièges de la conception d'un logiciel d'édition musicale

Ce serait formidable si les logiciels d'édition ne nécessitaient pas de mettre les mains dans le cambouis pour produire un résultat acceptable. Notre but avec LilyPond était de mettre au point un tel système : un programme qui produise une belle partition – "gravure" – automatiquement.

À première vue, la notation musicale est organisée de façon complètement hiérarchique. Considérez l'exemple suivant, avec deux portées contenant deux mesures :

Le développement logiciel ne consisterait-t-il pas à découvrir des hiérarchies et à modéliser le monde réel sous forme d'arbres ? Dans l'esprit d'un programmeur naïf, l'extrait musical ci-dessus peut aisément se représenter par un ensemble de boîtes imbriquées :

Il est facile de suivre ce modèle en écrivant un logiciel. Le stockage en mémoire des données est évident, et leur écriture sur le disque est triviale. Dans un fichier XML, ce pourrait être quelque chose comme

  <score>
    <staff>
      <measure id="1">
         <chord length="1/2">
          <pitch name="c">
         </chord>
         <chord>

        ....
      </measure>
    </staff>
  </score>

En résumé, ce modèle est évident, simple et clair. Beaucoup de logiciels sont fondés dessus. Malheureusement, il est également insuffisant. La représentation hiérarchique fonctionne pour beaucoup de partitions simples, mais elle est limitée pour une utilisation poussée. Regardez l'exemple suivant :

Ici, plusieurs suppositions du modèle hiérarchique sont mises à mal : les portées débutent et s'arrêtent n'importe où, les voix passent d'une portée à l'autre, et parfois occupent même deux portées.

La notation musicale est vraiment différente de la musique elle-même. La notation est un langage visuel complexe, qui permet de coder des concepts musicaux souvent beaucoup plus simples. Par conséquent, les logiciels devraient refléter cette séparation.

Suite : Diviser pour mieux régner, un modèle pour la notation automatisée.

Diviser pour mieux régner

Dans la mesure où on distingue le contenu et la forme d'une partition, il nous faut adopter ce principe dans la conception même du logiciel. Par conséquent, le projet peut se schématiser ainsi :

	←	`{ c'4 d'8 }`
1. forme	2. traduction	3. contenu

En réalité, nous surmontons le problème en le décomposant en problèmes plus simples :

Typographie : où positionner les symboles
Notation : quels symboles produire
Représentation : comment coder la musique

Enfin, à chaque fois que l'on décompose un problème, il en surgit un nouveau :

Architecture : recoller les morceaux.

Suite : Impressionnant, mais que se passe-t-il en théorie ? Une approche pratique pour maîtriser la notation.

Notation musicale

La notation musicale couvre cinq siècles de musique, allant de la simple monodie à de gigantesques contrepoints orchestraux. Comment intégrer un tel monstre aux si nombreux visages ? Notre solution est de clairement distinguer la notation – quels symboles utiliser – de la gravure – où les placer. Pour appréhender la notation, nous l'avons disséquée en éléments simples (et programmables) : chaque type de symbole est géré par un module différent. Tous ces modules coopèrent par le biais de l'architecture de LilyPond. Ils sont entièrement configurables et indépendants, chacun pouvant être développé et amélioré séparément.

Le module le plus basique crée les têtes de notes :

Ce module crée des objets graphiques à partir d'éléments musicaux. Par référence aux graveurs (engravers en anglais), professionels qui mettent en forme graphiquement les idées musicales, ce module s'appelle Note_head_engraver.
Le module Staff_symbol_engraver génère les objets représentant les lignes de portée :
Le module Clef_engraver fournit à Note_head_engraver la hauteur à laquelle doit être placée chaque tête de note :
Les hampes et leurs crochets sont gérés par le module Stem_engraver :

Ce module est appelé dès qu'une tête de note est utilisée. Pour chaque note rencontrée – ou groupe de notes pour les accords –, un objet hampe est créé et attaché à la tête de note.
Liens, liaisons et accents sont gérés par des graveurs différents. De même que le Stem_engraver, ils créent des objets et les attachent aux hampes, têtes de notes, etc. :
Les altérations, barres de mesures, chiffrages de mesure et armures possèdent chacun un graveur dédié :

Le module Accidental_engraver est le plus complexe : il doit prendre en compte l'armure, les hauteurs de notes, les liaisons de prolongation et les barres de mesures, afin de décider quand imprimer une altération.

Notation polyphonique

Le principe décrit plus haut fonctionne très bien pour de la musique monophonique, mais qu'en est-il de la polyphonie ? Dans ce cas, plusieurs voix peuvent partager la même portée :

Ici, la portée et les altérations sont partagées mais les hampes, liaisons, liens, etc. dépendent de chaque voix. De plus, les graveurs doivent être regroupés. Les graveurs de têtes de notes, hampes, liaisons, etc. sont donc inclus dans un groupe appelé « Voice context » (contexte de voix), alors que l'armure, les altérations, les barres de mesures, etc. sont placées dans un groupe « Staff context » (contexte de portée). Dans le cas d'une polyphonie, un contexte de portée contient plusieurs contextes de voix. De même, plusieurs contextes de portée peuvent être assemblés dans un contexte de partition (« score context ») :

Suite : L'art de la gravure : comment gravaient-ils la musique manuellement ?

Gravure musicale

Lorsque le symbole à imprimer est défini, il reste à décider où il sera placé pour obtenir un résultat agréable. Cet art est celui de la gravure musicale. Ce terme vient du procédé traditionnel de l'impression musicale. Il y a encore quelques décennies, les partitions étaient faites en taillant et ciselant la musique dans des plaques de zinc ou d'étain, en inverse, comme dans un miroir. Ces plaques étaient encrées et les reliefs créés par les poinçons et les découpes retenaient l'encre. La partition était alors réalisée en pressant le papier contre la plaque. Découpes et poinçons étaient entièrement faits à la main. Dans la mesure où les corrections étaient presque irréalisables, la gravure devait être correcte dès le premier essai. Cela demande évidemment une très grande habileté.

La gravure musicale est un métier d'artisan, appris sur le tas. Un graveur ne devenait un maître accompli qu'après une dizaine d'années de pratique.
La plupart des connaissances se transmet de maître à élève, par la pratique. De ce fait, peu de choses ont été écrites sur les règles d'une gravure de qualité.
Enfin, la gravure est une question de choix de dimensions et de noirceur des partitions. La qualité du résultat final doit être jugée visuellement. Il est quasiment impossible de la formaliser avec des règles strictes.

Suite : Encrer les écrans ? Les programmeurs s'attaquent aux problèmes de la gravure.

Implémenter la typographie

Comment nous en sortir avec le traitement typographique ? La solution au problème de la « notation musicale » implique le traitement de nombreux objets représentant les têtes de notes, portées, hampes, etc.

Si dix ans sont nécessaires pour devenir un maître graveur, comment les simples programmeurs que nous sommes pourraient-ils intégrer leur métier ?

La réponse est simple : nous ne le pouvons pas ! La typographie relevant d'un jugement humain, les personnes ne peuvent être remplacées. Beaucoup de tâches pénibles peuvent cependant être automatisées : si LilyPond parvenait à gérer la plupart des situations usuelles correctement, ce serait un grand pas en avant pour l'édition informatisée. Les cas particuliers peuvent être traités manuellement. Au fil du temps, le logiciel pourra être révisé afin d'automatiser de plus en plus d'actions, de sorte que les ajustements manuels seront de moins en moins nécessaires.

Comment avons-nous construit un tel système ? Nous avons tout d'abord écrit le programme en C++. Cela signifie que nous, développeurs, avons figé ses fonctionnalités dans le code. Cela est vite apparu insatisfaisant :

Si certains éléments doivent être traités manuellement, les utilisateurs doivent se servir du moteur de formatage. Par conséquent, les règles et paramètres ne peuvent être fixés lors de la compilation, mais doivent être accessibles lors de l'exécution.
Graver est une affaire de jugement visuel, donc une affaire de goût. Nous savons que les utilisateurs peuvent ne pas être d'accord avec nous. Ils faut donc qu'il aient accès aux définitions des styles typographiques.
Enfin, nous redéfinissons continuellement les règles de formatage, et avons donc besoin d'une approche souple des règles. Le C++ implique une méthode de groupement des règles qui ne correspond pas au fonctionnement de la notation musicale.

Une architecture flexible est évidemment nécessaire. Celle-ci doit prendre en compte les règles de formatage, le style typographique et les décisions de formatage individuelles.

Suite : Architecture de programme flexible, votre alliée pour régler, triturer, et développer les règles de formatage.

Une architecture de programme flexible

Vous souvenez-vous du problème de la notation musicale ? Sa solution nous apporte un ensemble d'objets. L'architecture du programme est basée sur ces objets. À chacun de ces objets sont associées des variables :

La mise en page dépend des variables. Par exemple, la variable direction, définie pour de nombreux objets, encode le choix entre haut et bas (ou gauche et droite). L'image qui suit présente deux accords, accentués et arpégés. Pour le premier accord, la direction de chaque objet est vers le bas (ou la gauche). Les objets sont dirigés vers le haut (ou la droite) pour le second.

Le processus de mise en forme d'une partition consiste à lire et écrire des variables d'objets.
Certaines variables ont une valeur prédéfinie. Par exemple, l'épaisseur de nombreuses lignes – caractéristiques d'un style typographique – est préétablie. La changer entraîne un changement du style typographique.
Les valeurs prédéfinies de certaines variables font aussi partie des règles de formatage. Chaque objet possède des variables contenant des procédures. Ces procédures réalisent le formatage prédéfini, dont l'apparence peut être changée en remplaçant ces procédures par d'autres. Dans l'exemple suivant, la règle permettant à l'objet « tête de note » de dessiner son symbole est modifiée au cours de l'extrait musical :

Suite : Nombres de beauté : comment LilyPond participe au concours Miss Monde.

Ces nombres qui nous entourent

Quels sont en réalité nos critères de fomatage ?

Considérant l'image suivate, laquelle de ces trois configurations devrions-nous choisir pour formater la liaison ?

Seuls quelques livres traitent de l'art de graver la musique. Ils ne contiennent malheureusement que des généralités et quelques exemples. La lecture de telles règles est certes instructive, mais est très loin de nous conduire à un algorithme prêt à être implémenté dans un programme. Dans la pratique, suivre les instructions de ces traités aboutirait à des algorithmes qui figent bon nombre d'exceptions. Répertorier tous ces cas de figure demanderait un travail considérable, qui finalement ne les couvrirait pas tous.

Règles de formatages définies par l'exemple.
Image tirée de l'ouvrage de Ted Ross « The Art of Music Engraving »

Nous avons développé une méthode bien plus simple et robuste pour parvenir au meilleur formatage possible : le choix du moindre mal. Le principe est celui d'un concours de beauté : à chaque configuration est attribuée une note de laideur. Nous optons alors pour la configuration la moins laide.

Si l'on considère le cas de figure précédent, la liaison est finement rattachée aux notes de début et de fin, et a une ligne bien galbée. Elle frôle cependant l'une des notes, tout en restant bien loin des autres. Nous lui attribuons donc une note de "variance" – variance des distances verticales entre liaison et notes – de 15,39.

La liaison ci-dessus reste à une distance uniforme des notes, mais il faut tenir compte du fait qu'elle n'est pas rattachée aux première et dernières notes. Ceci nous fait 1,71 points pour le début de la liaison et 9,37 pour la terminaison – qui est beaucoup plus éloignée de la dernière note. Par ailleurs, la liaison monte alors que la mélodie descend, ce qui entraîne une pénalité de 2 points.

Enfin, dans cette configuration, seule la terminaison de la liaison reste éloignée de la dernière note , ce qui donne 10,04 points de laideur.

Au vu des résultats, nous remarquons que la troisième option est la moins laide, ou plutôt la version la plus satisfaisante. C'est pourquoi nous la sélectionnons.

Cette manière de procéder est générique, et nous y avons recours dans bon nombre de situations, comme pour

déterminer la pente d'un lien de croches
,
formater des accords liés
,
formater des accords avec des valeurs pointées,
les sauts de ligne,
les sauts de page.

Cette technique est consommatrice de temps de calcul, dans la mesure où elle examine de nombreuses possibilités ; néanmoins, le jeu en vaut la chandelle, puisque le résultat final est bien meilleur et nous rend les choses plus faciles.

Suite : L'homme est la mesure de toute chose : peut-on se contenter d'une architecture flexible ?

Évaluation des performances

Une bonne mise en page nécessite une architecture souple. Ce n'est malheureusement pas suffisant. Seule une comparaison attentive avec du matériel imprimé peut permettre un résultat satisfaisant. Nous avons suggéré dans l'introduction de comparer éditions informatisées et gravures à la main. C'est exactement cette technique que nous avons employée pour perfectionner LilyPond. D'une certaine façon, il s'agit d'une technique d'évaluation des performances : les performances du programme, en terme de qualité, s'établissent par rapport à une quantité connue.

Voici des extraits comparés d'une même pièce. En haut l'édition de référence (Bärenreiter BA 320), en bas ce que LilyPond 1.4 a généré :

Bärenreiter (cliquez pour agrandir)

LilyPond 1.4

La sortie LilyPond est certes lisible, et acceptable pour beaucoup de gens. Cependant, une comparaison minutieuse avec une édition gravée à la main révèle de nombreuses erreurs de formatage :

De nombreux symboles étaient déséquilibrés. Le trille en particulier était trop grand.
Les hampes et liens de croches étaient défectueux : les hampes étaient trop longues, et les liens auraient dû être inclinés de façon à couvrir les lignes de portée. Les liens étaient également trop fins.
L'espacement était irrégulier : certaines mesures étaient trop serrées, d'autres trop espacées.

(Et des notes manquent dans la version de LilyPond.)

En ajustant les algorithmes, paramètres et polices concernés, nous avons pu améliorer le résultat. L'extrait ci-dessous a été généré par LilyPond 1.8. Sans être un clone de l'édition de référence, cette sortie est proche d'une qualité de publication.

LilyPond 1.8

Bärenreiter

Un autre exemple d'évaluation des performances est celui de notre projet pour les versions 2.1, une mélodie de Schubert.

Suite : Fonctionnalités sympathiques, des casses-têtes typographiques que nous avons résolus.

Création de polices

L'aspect traditionnel des sorties de LilyPond est très largement dû à la densité des pages produites. Des lignes de portée épaisses, et une police qui leur correspond donnent plus de poids à l'aspect général. Ceci est très clair dans les exemples suivants :


Henle (2000)	Bärenreiter (1950)	LilyPond (2003)

Un autre aspect typique de la gravure à la main est l'aspect général des symboles. Ils n'ont quasiment jamais d'angle tranchant. Ceci s'explique par la fragilité des poinçons, qui s'émoussent rapidement lors du martellement et de la ciselure. L'aspect arrondi des symboles musicaux est également présent dans tous les éléments de notre police « Feta ».

Espacement

L'un des problèmes que pose la pièce de Bach vue précédemment nous a amené à travailler sur le moteur d'espacement. L'une de ses caractéristique réside dans l'espacement visuel, montré dans cet exemple :

Seules des noires sont utilisées ici : elles sont jouées de manière égale. L'espacement devrait le refléter. Malheureusement nos yeux nous trompent : non seulement la distance entre les têtes de notes est prise en compte, mais celle entre les hampes consécutives aussi. Ainsi, dans un enchaînement hampe vers le haut puis hampe vers le bas, les notes doivent être davantage éloignées, et inversement. L'espacement dépend également du positionnement vertical des notes. Le fragment du haut est imprimé avec cette correction, au contraire de celui du bas. Dans ce dernier, les combinaisons de notes avec hampe vers le haut / hampe vers le bas forment des blocs.

Lignes supplémentaires

Les lignes supplémentaires présentent des difficultés typographiques. Des surcharges avec d'autres signes – d'autres lignes ou des altérations – sont vite arrivées. Les autres logiciels évitent ces collisions en espaçant davantage les lignes, ce qui occupe plus de place, ou en raccourcissant les lignes supplémentaires, au détriment de la lisibilité.


Henle (2000)	Bärenreiter (1950)	LilyPond (2004)

Les graveurs traditionnels ajustent la taille d'une ligne supplémentaire en tenant compte des symboles se trouvant à proximité. LilyPond agit de la même manière. Les lignes supplémentaires sont écourtées afin d'éviter les collisions avec les lignes proches, et sont d'autant plus réduites en présence d'une altération.

Suite : Utilise la Source, Luke, ou : ce que LilyPond traite en entrée.

Format de saisie

Comme nous l'avons dit plus tôt, le format idéal pour un système de gravure musicale est le contenu : la musique elle-même. Cela pose 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.

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 noire et un ré croche, comme dans cet exemple :

À 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 :

Combinez ceci simultanément avec deux autres notes, en les insérant entre << et >> :

  <<c4 d4 e4>>

Cette expression est intégrée dans une séquence, insérée entre accolades :

   { <<c4 d4 e4>> f4  }

L'exemple ci-dessus est une autre expression, qui est ci-dessous combinée avec une expression simultanée (en l'occurence une blanche) :

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

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 facile 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.

Analyse et représentation	Total
6000 lignes en C++	61500 lignes en C++

Suite : Pour finir, la conclusion.

Conclusion

Nous vous avons montré ce que devrait être la gravure musicale, et comment nous avons construit notre logiciel pour imiter cette apparence. Nous nous sommes énormément investis dans cette construction. En guise de récompense pour ce long travail, vous pouvez à votre tour utiliser le programme pour imprimer votre musique.

Pour compléter la lecture de cet essai, ne manquez pas de consulter les publications et articles, et tout particulièrement le comparatif d'Andrew Hawryluk entre Finale et LilyPond.

Retour à l'index.


Bärenreiter (BA 320, (c) 1950)	Henle (nr. 666 (c) 2000)