A.20 Glossaire technique

Ce glossaire regroupe les termes techniques et concepts utilisés en interne par LilyPond. Ils apparaissent aussi bien dans les manuels, que sur les listes de diffusion et dans le code source.

alist (liste associative) ¶

Une liste associative – alist pour association list – est une paire Scheme qui associe une valeur à une clé : (clé . valeur). Le fichier scm/lily.scm contient par exemple une alist type-p-name-alist qui associe certains types de prédicat (par ex. ly:music?) à des noms (par ex. « music ») de telle sorte qu’une erreur lors d’un contrôle de typage puisse être rapportée en console avec mention du type de prédicat attendu.

callback (rappel) ¶

Un rappel, callback en anglais, est une routine, fonction ou méthode qui est passée en argument à une autre fonction. Cette dernière peut alors faire usage de cette fonction de rappel comme de n’importe quelle autre fonction, alors qu’elle ne la connaît pas par avance. Cette façon de procéder permet à des couches logicielles de bas niveau d’appeler des fonctions définies à des niveaux plus élevés. LilyPond utilise abondamment les callbacks afin que le code Scheme saisi par l’utilisateur puisse contrôler les actions de bas niveau.

closure (clôture) ¶

En Scheme, une clôture (en anglais closure) est créée lorsqu’une fonction, généralement une expression lambda, est passée en tant que variable. La clôture comporte, en plus du code de la fonction, des références à des variables libres dans l’environnement lexical – variables utilisées dans l’expression mais définies ailleurs. Lorsque la fonction est par la suite appliquée aux différents arguments, les références aux variables libres, capturées par la clôture, permettent d’obtenir la valeur de ces variables libres qui sera utilisée lors des calculs. L’une des propriétés intéressantes des clôtures est la rétention de la valeur de variables internes tout au long des différentes invocations, leur état étant alors persistant.

glyphe ¶

Un glyphe est une représentation graphique particulière d’un caractère typographique ou d’une combinaison de deux caractères formant une ligature. Un jeu de glyphes aux mêmes style et allure constitue une fonte ; un jeu de fontes comprenant plusieurs styles et tailles constitue un type de caractère.

Voir aussi : Fontes, Caractères spéciaux.

grob (objet graphique) ¶

Dans LilyPond, les objets représentants les différents éléments de notation, comme les têtes de note, hampes, liaisons, doigtés, clefs etc. sont appelés « objets de rendu » ou objet graphique – en anglais GRaphical OBjects couramment abrégé en grob. Ils sont représentés par des instances de la classe grob.

Voir aussi : Objets et interfaces, Propriétés des objets de rendu.
Conventions de nommage.
grob-interface, All layout objects.

inaltérable ¶

Un objet est dit inaltérable – immutable en anglais – dès lors que son état ne peut être modifié après sa création ; les objets altérables, à l’inverse, peuvent être modifiés après création.

Pour LilyPond, une propriété est inaltérable ou commune lorsqu’elle définit les style ou le comportement par défaut d’objets graphiques ; une telle propriété est partagée par un certain nombre de grobs. En apparente contradiction avec ce que leur nom laisse accroire, de telles propriétés peuvent être adaptées par \override et \revert.

Voir plus avant pour les objets altérables.

interface ¶

Les actions et propriétés communes à plusieurs objets graphiques sont regroupées dans un objet appelé grob-interface, ou interface pour faire court.

Voir aussi : Interfaces de rendu.
Objets et interfaces, Propriétés listées par interface.
Graphical Object Interfaces.

lexer (analyseur lexical) ¶

Un lexer est un programme chargé de convertir une séquence de caractères en une séquence de jetons. Cette opération s’appelle analyse lexicale. L’analyseur lexical de LilyPond convertit le flot d’information contenu dans un fichier .ly en flot de jetons qui pourront être traités lors de l’étape suivant, l’analyse grammaticale abordée plus avant. L’analyseur lexical de LilyPond repose sur le programme flex ; les règles lexicales sont regroupées dans le fichier lily/lexer.ll. Ce fichier, partie intégrante des sources, n’est pas distribué avec les programmes binaires de LilyPond.

altérable ¶

Un objet est dit altérable – mutable en anglais – lorsque son état est sujet à modification après sa création, à l’inverse des objets inaltérables dont l’état est figé dès leur création.

Les propriétés altérables contiennent, pour LilyPond, des valeurs spécifiques à un objet graphique. En particulier, les listes d’autres objets ou résultats de calculs sont enregistrés sous dorme de propriétés altérables.

Voir ci-dessus pour les objets inaltérables.

output-def (définition de sortie) ¶

Une instance de la classe Output-def contient les méthodes et structures des données associées à un bloc de sortie. Ces instances sont créées par les blocs \midi, \layout et \paper.

parser (analyseur syntaxique) ¶

Un analyseur syntaxique – parser en anglais – est un programme qui analyse la séquence de jetons produite par l’analyseur lexical pour en déterminer la structure grammaticale. Les jetons sont, pour ce faire, regroupés progressivement en tronçons plus importants, selon des règles grammaticales. Lorsque la séquence de jetons est valide, le produit final est une arborescence de jetons ayant à sa base le symbole grammatical de début. Dès lors que cette étape n’est pas concluante, le fichier est déclaré invalide ; un message approprié est alors émis. Les différents regroupements syntaxiques ainsi que les règles de construction des regroupements relatifs à la grammaire de LilyPond sont définis dans le fichier lily/parser.yy. Ce fichier est utilisé par le générateur de parser bison lors de la construction du programme. Partie intégrante des sources, il n’est pas distribué avec les programmes binaires de LilyPond.

variable de l’analyseur grammatical ¶

Il s’agit de variables définies directement en Scheme. Dans la mesure où leur champ sémantique peut porter à confusion, il est fortement déconseillé de les utiliser tels quels.

La modification des valeurs de l’une de ces variables dans un fichier .ly est effective de manière globale. Les valeurs modifiées, sauf à être explicitement remises à leur état d’origine, affectent tous les blocs \score rencontrés, y compris s’ils proviennent d’autres fichiers ajoutés par une commande \include. Ceci peut avoir des conséquences inattendues et les erreurs qui pourraient en découler difficiles à localiser dans le cadre d’un projet d’envergure.

LilyPond utilise, entre autres, les variables suivantes :

• afterGraceFraction
• musicQuotes
• output-count
• output-suffix
• partCombineListener
• pitchnames
• toplevel-bookparts
• toplevel-scores
• showLastLength
• showFirstLength

prob (objet de propriété) ¶

Les objets de propriété – probs pour PRoperty OBjects – sont des instances de la classe Prob, une classe de base simple pour les objets qui disposent de de listes associatives de propriétés altérables et inaltérables ainsi que les méthodes pour les manipuler. Les classes Music et Stream_event dérivent d’un prob. Les instances de la classe prob se créent aussi pour garder trace du contenu des systèmes une fois formatés et des blocs de titrage lors de la phase de mise en forme des pages.

smob (objet Scheme) ¶

Les objets Scheme – Smobs pour ScheMe OBjects – font partie du mécanisme utilisé par l’interpréteur Guile pour exporter en code Scheme les objets C ou C++. Dans LilyPond, les smobs sont créés, grâce à des macros, à partir d’objets C++. On peut distinguer deux types d’objets smob : des smobs simples destinés aux objets inaltérables comme les nombres par exemples, et des smobs complexes utilisés pour des objets possédant une identité. De plus amples informations sont disponibles dans les sources de LilyPond, au sein du fichier lily/includes/smob.hh.

spanner (bandeau) ¶

Les bandeaux (spanners) constituent une classe d’objets graphiques qui ne sont pas fixés horizontalement, mais s’étendent entre deux points. On peut citer à titre d’exemple les ligatures, les liaisons quel que soit leur type, les soufflets, et même les lignes de la portée. Contrairement aux objets ponctuels (contraire des bandeaux), qui peuvent apparaître au plus deux fois à l’occasion d’un saut, comme la duplication d’une clef en fin de ligne et au début de la suivante, les bandeaux sont sectionnés en autant de tronçons que de besoin selon leur point de départ et leur terminaison, comme un crescendo qui s’étend sur trois systèmes ou les lignes de portée qui s’étendent tout au long de la partition.

Techniquement, les bandeaux se définissent comme des objets graphiques disposant de la spanner-interface ; du côté C++ de LilyPond, ils constituent des instances de la sous-classe Spanner de grob. Leurs extrémités gauche et droite peuvent se récupérer ou définir respectivement à l’aide de ly:spanner-bound et ly:spanner-set-bound!. Leurs extrémités sont toujours des objets ponctuels. Le parent X d’un bandeau n’a que peu de sens en termes de musique, mais il se détermine habituellement par son extrémité gauche.

Voir aussi : Extenseurs et prolongateurs.
All layout objects, spanner-interface.

stencil ¶

Une instance de la classe Stencil comporte l’information nécessaire à l’impression d’un objet typographique. Il s’agit d’un smob simple qui contient un espace de confinement qui définit l’envergure verticale et horizontale de l’objet ainsi qu’une expression Scheme qui imprimera l’objet après évaluation. Les stencils peuvent se combiner et adopter une forme plus complexe définie par une arborescence d’expressions Scheme des stencils qui la composent.

La propriété stencil, qui permet de connecter un grob à son stencil, est définie par l’interface grob-interface.

Voir aussi grob-interface.