Re: traduction de "working"

[Jean-Yves Baudais]

Bonjour,

  Puisqu'à une époque j'avais des remarques sur un fichier, je m'y suis 
mis moi aussi. Que du détail. Par contre la façon de procéder n'est 
peut-être pas terrible, si une autre personne part du même fichier mais 
postes ses modifications après moi, qui va *re*-faire le boulot ?

--Jyb

%% diff working.itely.new workin.itely
%% iff (GNU diffutils) 2.8.1
%% working.itely.new 20/01/2007
%% working.itely : pièce jointe au courriel de "Jean-Charles 
%%                 <address@hidden>"  sur lilypond-user-fr
%%                 le 24/01/2007 Ã  19h10

14c14
< problèmes courants.  Si vous avez une expérience en 
---
> problèmes courants.  Si vous avez une expérience dans la
35,36c35,36
< résultat que vous souhaitez, peu importe la manière dont le code
< est organisé. Néanmoins, quelques critères doîvent être pris
---
> résultat que vous souhaitez, pei importe la manière dont vous le code
> est organisé. Néanmoins, quelques autres critères doîvent être pris en
51c51
< s'améliore. La plupart des modifications peuvent être faites
---
> s'améliore. La plupart des modification peuvent être faites
53c53
< peuvent demander une intervention manuelle. Les fichiers LilyPond
---
> peuvent demander une intervention manuelle. Les fichier LilyPond
66c66
< Voici quelques conseils qui peuvent vous éviter certains problèmes ou en 
résoudre d'autres :
---
> Voici quelques conseils qui peuvent vous éviter certains problèmes ou en 
> résoudre d'autres:
77c77
< retrouver plus rapidement. À quelle fréquence faut-il en ajouter ? 
---
> retrouver plus rapidement. À quelle fréquence faut-il en ajouter? 
216,217c216,217
< (aussi connus sous le nom de variables, macros, ou commandes
< définies par l'utilisateur) pour des modifications :
---
> (aussi connus sous le nom de variables, macros, ou commande
> (définie par l'utilisateur)) pour des modifications :
326c326
< résultat que nous désirons, mais nous pourrions aussi vouloir les utiliser 
dans une autre pièce. Nous pourrions simplement les copier et les coller au 
début de chaque fichier, mais c'est fastidieux.
---
> résultat que nous désirons, mais nous pourrions aussi vouloir les utiliser 
> dans une autre piece. Nous pourrions simplement les copier et coller au 
> début de chaque fichier, mais c'est fastidieux.
456c456
< musique est destinée à produire un fichier pdf affiché sur
---
> musique est déstinée à produire un fichier pdf affiché sur
561c561
< rendre les fichiers plus faciles à lire et à écrire,
---
> rendre les fichiers plus faciles à lire et écrire,
598c598
< commentaires (indiqué par @address@hidden ... address@hidden). Si vous
---
> commentaires (indiqués par @address@hidden ... address@hidden). Si vous
601c601
< Après avoir mis en commentaire une section, essayez
---
> Après avoir mis en commentaires une section, essayez
604c604
< ne fonctionne pas, continuez à mettre en commentaire
---
> ne fonctionne pas, continuez à mettre en commentaires
626c626
< Si ce n'est pas le cas, placez en commentaire toute la
---
> Si ce n'est pas le cas, placez en commentaires toute la

@c -*- coding: utf-8; mode: texinfo; documentlanguage: fr -*-
@c This file is part of lilypond.tely
@ignore
    Translation of GIT committish: 64f0d86a7c0987b311bfdfdfeddfa063e1f2d6e7

    When revising a translation, copy the HEAD committish of the
    version that you are working on.  See TRANSLATION for details.
@end ignore

@node Working on LilyPond projects
@chapter Working on LilyPond projects

Cette section explique comment résoudre ou éviter certains
problèmes courants.  Si vous avez une expérience en 
programmation, beaucoup de ces astuces peuvent vous paraître
évidentes.  Cependant, il est quand même conseillé de lire
ce chapitre.

@menu 
* Suggestions for writing LilyPond files::
* Saving typing with identifiers and functions::
* Style sheets::
* Updating old files::
* Troubleshooting (taking it all apart)::
@end menu 
@node Suggestions for writing LilyPond files
@section Suggestions for writing LilyPond files

Maintenant vous êtes prêts à travailler avec de plus gros fichiers
LilyPond -- des pièces entières, et plus seulement les petits
exemples du tutoriel. Mais comment allez-vous vous y prendre pour
commencer ?

Tant que LilyPond parvient à comprendre vos fichiers et produit le
résultat que vous souhaitez, peu importe la manière dont le code
est organisé. Néanmoins, quelques critères doîvent être pris
en compte lorsque l'on écrit un fichier LilyPond.

@itemize @bullet
@item Si vous faites une erreur, la structure même du fichier LilyPond
peut permettre de la trouver plus ou moins facilement.

@item Et si vous souhaitez partager vos fichiers avec quelqu'un
d'autre, ou si vous souhaitez modifier vos propres fichiers dans
quelques années ? Certains fichiers LilyPond sont compréhensibles
au premier coup d'oeil. D'autres peuvent devenir source de migraine.

@item Et si vous souhaitez mettre à jour votre fichier pour
l'utiliser avec une version plus récente de LilyPond ? La syntaxe
du langage d'entrée change quelques fois lorsque LilyPond
s'améliore. La plupart des modifications peuvent être faites
automatiquement avec @code{convert-ly}, mais quelques-unes
peuvent demander une intervention manuelle. Les fichiers LilyPond
peuvent être structurés de manière à être plus faciles à mettre
à jour.
@end itemize

@menu 
* General suggestions::
* Typesetting existing music::
* Large projects::
@end menu 
@node General suggestions
@subsection General suggestions

Voici quelques conseils qui peuvent vous éviter certains problèmes ou en 
résoudre d'autres :

@itemize @bullet
@item @strong{ajoutez les numéros de version dans chaque fichier}. 
Notez que chaque fichier modèle contient un ligne @code{\version
"2.9.13"}.  Nous vous conseillons fortement d'inclure cette ligne,
même pour de petits fichiers. Par expérience, il est très difficile de se 
rappeler quelle version de LilyPond vous utilisiez quelques années auparavant. 
 L'utilitaire @code{convert-ly} demande que vous spécifiiez quelle version de 
LilyPond vous avez utilisé.

@item @strong{ajoutez des contrôles}: @ref{Bar check} et 
@ref{Octave check}.  Si vous avez ajouté des contrôles
régulièrement, et que vous faites une erreur, vous pourrez la
retrouver plus rapidement. À quelle fréquence faut-il en ajouter ? 
Cela dépend de la complexité de la musique. Pour de la musique
très simple, peut-être une ou deux fois. Pour de la musique plus
complexe, peut-être à chaque mesure.

@item @strong{Une mesure par ligne de texte}. S'il y a quelque 
chose de compliqué, soit dans la musique en elle-même, soit dans
le résultat que vous désirez, il est souvent bon de n'écrire
qu'une seule mesure par ligne. La place économisée en tassant
huit mesures par ligne n'a que peu de valeur si vous devez
corriger vos fichiers.

@item @strong{Commentez vos fichiers}. Utilisez soit des
numéros de mesure (assez souvent), soit des références au contenu
musical (@q{second thème des violons,} @q{quatrième variation,}
etc.). Vous pouvez ne pas avoir besoin des commentaires lorsque
vous écrivez une pièce pour la première fois, mais si vous
souhaitez y revenir deux ou trois ans plus tard pour changer
quelque chose, ou si vous donnez le fichier source à un ami, ce
sera beaucoup plus difficile de déterminer vos intentions ou 
la manière dont votre fichier est structuré si vous ne l'avez
pas commenté.

@item @strong{Indentez vos crochets}. Beaucoup de problèmes
viennent d'un défaut de parité entre @address@hidden et @address@hidden

@item @strong{Séparez les modifications} des définitions de
musique.  Voyez @ref{Saving typing with identifiers and
functions} et @ref{Style sheets}.

@end itemize


@node Typesetting existing music
@subsection Typesetting existing music

Si vous saisissez de la musique depuis une partition existante
(c'est-à -dire d'une musique déjà écrite),

@itemize @bullet

@item N'entrez qu'un seul système de la partition originale
à la fois (mais toujours une seule mesure par ligne de
texte), et vérifiez chaque système lorsqu'il est terminé.
Vous pouvez utiliser la commande @code{showLastLength}
pour accélérer la compilation -- voir
@ref{Skipping corrected music}.

@item Définissez @code{mBreak = @{\break @}} et inserez
@code{\mBreak} dans le fichier d'entrée à chaque fois que la
partition originale change de système. Cela rend plus facile
la comparaison entre la partition originale, et la partition
de LilyPond. Lorsque vous avez fini de relire votre musique,
vous pouvez définir @code{mBreak = @{ @}} pour enlever tous
les sauts de ligne, et laisser LilyPond changer de système
quand il le souhaite.

@end itemize


@node Large projects
@subsection Large projects

Lorsque l'on travaille sur un gros projet, il devient vital
d'avoir une structure claire des fichiers LilyPond.

@itemize @bullet

@item @strong{utilisez un identificateur pour chaque voix},
avec un minimum de structure dans la définition.  La
structure de la section @code{\score} est la plus 
susceptible de changer, alors que la définition du 
@code{violon} ne l'est que très peu.

@example
violin = \relative c'' @{
g4 c'8. e16
@}
...
\score @{
  \new GrandStaff @{
    \new Staff @{
      \violin
    @}
  @}
@}
@end example

@item @strong{séparez les modifications} des définitions de
musique.  Ce conseil a été vu dans @ref{General suggestions},
mais pour les gros projets c'est absolument vital. Nous
pouvons avoir besoin de changer la définition de
@code{fthenp}, mais dans ce cas nous n'aurons besoin de le faire
qu'une seule fois, et nous pourrons toujours éviter de
modifier quoi que ce soit à l'intérieur de la définition
du @code{violon}.

@example
fthenp = address@hidden
  \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
violin = \relative c'' @{
g4\fthenp c'8. e16
@}
@end example

@end itemize


@node Saving typing with identifiers and functions
@section Saving typing with identifiers and functions

@cindex variables
@cindex identifiers

Jusqu'Ã  maintenant, vous avez vu ce type de code :

@lilypond[quote,verbatim,ragged-right]
hornNotes = \relative c'' { c4 b dis c }
\score {
  {
    \hornNotes
  }
}
@end lilypond

Vous comprendrez combien cela peut être utile pour écrire de la musique 
minimaliste :

@lilypond[quote,verbatim,ragged-right]
fragA = \relative c'' { a4 a8. b16 }
fragB = \relative c'' { a8. gis16 ees4 }
violin = \new Staff { \fragA \fragA \fragB \fragA }
\score {
  {
    \violin
  }
}
@end lilypond

Cependant, vous pouvez aussi utiliser ces identificateurs
(aussi connus sous le nom de variables, macros, ou commandes
définies par l'utilisateur) pour des modifications :

@lilypond[quote,verbatim,ragged-right]
dolce = \markup{ \italic \bold dolce }
padText = { \once \override TextScript #'padding = #5.0 }
fthenp=_\markup{ \dynamic f \italic \small { 2nd } \hspace #0.1 \dynamic p }
violin = \relative c'' {
  \repeat volta 2 {
    c4._\dolce b8 a8 g a b |
    \padText
    c4.^"hi there!" d8 e' f g d |
    c,4.\fthenp b8 c4 c-. |
  }
}
\score {
  {
    \violin
  }
\layout{ragged-right=##t}
}
@end lilypond

Ces identificateurs sont évidemment utiles pour économiser
de la frappe. Mais ils peuvent l'être même si
vous ne les utilisez qu'une seule fois -- ils réduisent
la complexité. Regardons l'exemple précédent sans aucun
identificateur. C'est beaucoup plus laborieux à lire,
et particulièrement la dernière ligne.

@example
violin = \relative c'' @{
  \repeat volta 2 @{
    address@hidden \italic \bold dolce @} b8 a8 g a b |
    \once \override TextScript #'padding = #5.0
    c4.^"hi there!" d8 e' f g d |
    c,address@hidden \dynamic f \italic \small @{ 2nd @}
      \hspace #0.1 \dynamic p @} b8 c4 c-. |
  @}
@}
@end example

Jusqu'ici nous avons vu des substitutions statiques --
quand LilyPond rencontre @code{\padText}, il le remplace
par le contenu que nous lui avons défini (c'est-à -dire
le contenu à droite de @code{padText=}).

LilyPond peut gérer également des substitutions
non-statiques (vous pouvez les voir comme des fonctions).

@lilypond[quote,verbatim,ragged-right]
padText =
#(define-music-function (parser location padding) (number?)
  #{
    \once \override TextScript #'padding = #$padding
  #})

\relative c''' {
  c4^"piu mosso" b a b
  \padText #1.8
  c4^"piu mosso" d e f
  \padText #2.6
  c4^"piu mosso" fis a g
}
@end lilypond

Utiliser les identificateurs est aussi un bon moyen de réduire
le travail si la syntaxe de LilyPond change (voir @ref{Updating
old files}). Si vous avez une seule définition (comme
@code{\dolce}) pour tous vos fichiers (voir @ref{Style sheets}),
et que la syntaxe change, alors vous n'aurez qu'à mettre à jour
votre seule définition @code{\dolce}, au lieu de devoir
modifier chaque fichier @code{.ly}.

@node Style sheets
@section Style sheets

La sortie que produit LilyPond peut être largement modifiée ;
voir @ref{Tweaking output} pour plus de détails. Mais que faire
si vous avez beaucoup de fichiers auxquels vous souhaitez
appliquer vos modifications ? Ou si vous souhaitez simplement
séparer les modifications de la musique sur laquelle vous
travaillez ?  Rien de plus facile...

Regardons un exemple. Ne vous inquiétez pas si vous ne
comprenez pas les parties avec tous les #(). Celles-ci
sont expliquées dans @ref{Advanced tweaks with Scheme}.

@lilypond[quote,verbatim,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . 
-inf.0)
  \mark \markup { \bold $markp }
#})

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Il y a quelques problèmes de chevauchements ; nous allons arranger
cela en utilisant les techniques de @ref{Moving objects}. On peut
aussi aussi faire quelque chose pour les définitions
de @code{mpdolce} et @code{tempoMark}. Elles produisent le
résultat que nous désirons, mais nous pourrions aussi vouloir les utiliser 
dans une autre pièce. Nous pourrions simplement les copier et les coller au 
début de chaque fichier, mais c'est fastidieux.
De plus, cela laisse les définitions dans nos fichiers de
musique, et je trouve personnellement tous les #() assez laids.
Cachons-les dans un autre fichier :

@example
%%% save this to a file called "definitions.ly"
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
address@hidden
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . 
-inf.0)
  \mark \markup @{ \bold $markp @}
address@hidden)
@end example

Maintenant, modifions notre musique (enregistrez ce fichier
sous @file{"music.ly"}).

@c  We have to do this awkward example/lilypond-non-verbatim
@c  because we can't do the \include stuff in the manual.

@example
\include "definitions.ly"

\relative c'' @{
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line(#:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . 
-inf.0)
  \mark \markup { \bold $markp }
#})

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

C'est mieux, mais ajoutons encore quelques modifications.
Le glissando est difficile à voir, c'est pourquoi nous allons
le rendre plus épais et plus proche des têtes de notes.
Déplaçons l'indication métronomique au-dessus de la clef,
au lieu de la laisser au-dessus de la première note.
Et pour finir, mon professeur de composition déteste les
chiffrages de mesure en "C", nous allons donc le transformer
en "4/4".

Ne changez pas cependant le fichier @file{music.ly}.
Remplacez le fichier @file{definitions.ly} par ceci :

@example
%%%  definitions.ly
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
address@hidden
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . 
-inf.0)
  \mark \markup @{ \bold $markp @}
address@hidden)

address@hidden
  \context @{ \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  @}
  \context @{ \Staff
    \override TimeSignature #'style = #'numbered
  @}
  \context @{ \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  @}
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . 
-inf.0)
  \mark \markup { \bold $markp }
#})

\layout{
  \context { \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  }
  \context { \Staff
    \override TimeSignature #'style = #'numbered
  }
  \context { \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  }
}

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

C'est déjà mieux ! Mais supposons maintenant que
je veuille publier cette piece. Mon professeur de composition
n'aime pas les chiffrages de mesure en "C", mais moi je les
aime bien.  Copions l'actuel @file{definitions.ly} dans le
fichier @file{web-publish.ly}, et modifions-le. Puisque la
musique est destinée à produire un fichier pdf affiché sur
écran, nous allons aussi augmenter la taille générale de
la sortie.

@example
%%%  definitions.ly
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
address@hidden
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . 
-inf.0)
  \mark \markup @{ \bold $markp @}
address@hidden)

#(set-global-staff-size 23)
address@hidden
  \context @{ \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  @}
  \context @{ \Staff
  @}
  \context @{ \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  @}
@}
@end example

@lilypond[quote,ragged-right]
mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
  #:line( #:dynamic "mp" #:text #:italic "dolce" )))
tempoMark = #(define-music-function (parser location markp) (string?)
#{
  \once \override Score . RehearsalMark #'self-alignment-X = #left
  \once \override Score . RehearsalMark #'extra-spacing-width = #'(+inf.0 . 
-inf.0)
  \mark \markup { \bold $markp }
#})

#(set-global-staff-size 23)
\layout{
  \context { \Score
    \override MetronomeMark #'extra-offset = #'(-9 . 0)
    \override MetronomeMark #'padding = #'3
  }
  \context { \Voice
    \override Glissando #'thickness = #3
    \override Glissando #'gap = #0.1
  }
}

\relative c'' {
  \tempo 4=50
  a4.\mpdolce d8 cis4--\glissando a | b4 bes a2
  \once \override Score.RehearsalMark #'padding = #2.0
  \tempoMark "Poco piu mosso"
  cis4.\< d8 e4 fis | g8(\! fis)-. e( d)-. cis2
}
@end lilypond

Il ne nous reste plus qu'Ã  remplacer
@code{\include "definitions.ly"} par
@code{\include "web-publish.ly"} dans notre fichier de musique.

Il est possible, bien sûr, de rendre cela encore plus pratique. 
Nous pourrions créer un fichier @file{definitions.ly} qui
ne contiendrait que les définitions de @code{mpdolce} et de
@code{tempoMark}, un fichier @file{web-publish.ly} qui ne
contiendrait que la section @code{layout} décrite ci-dessus
et un fichier @file{university.ly} qui ne contiendrait
que les modifications pour produire la sortie que mon
professeur préfère. Le début du fichier @file{music.ly}
ressemblerait alors à cela :

@example
\include "definitions.ly"

%%%  Only uncomment one of these two lines!
\include "web-publish.ly"
%\include "university.ly"
@end example

Cette approche peut être utile même si vous ne produisez
qu'un seul jeu de partitions. J'utilise une demi-douzaine
de fichiers @q{style sheet} pour mes projets. Je
commence chaque fichier musical par
@code{\include "../global.ly"} qui contient :

@example
%%%   global.ly
\version "2.9.13"
#(ly:set-option 'point-and-click #f)
\include "../init/init-defs.ly"
\include "../init/init-layout.ly"
\include "../init/init-headers.ly"
\include "../init/init-paper.ly"
@end example

@node Updating old files
@section Updating old files

La syntaxe de LilyPond change de temps en temps. Cette syntaxe
(le langage d'entrée) est modifiée pour accompagner les
améliorations du logiciel. Ces changements sont parfois destinés à 
rendre les fichiers plus faciles à lire et à écrire,
et parfois sont là pour intégrer de nouvelles fonctions.

LilyPond est fourni avec un utilitaire qui facilite la
mise-Ã -jour : @code{convert-ly}. Pour savoir comment utiliser
ce programme, voir @ref{Updating files with convert-ly}.

Malheureusement, @code{convert-ly} ne peut pas réaliser tous
les changements. Il s'occupe de simples changements qui ne
requièrent qu'un rechercher-remplacer (comme @code{raggedright}
qui devient @code{ragged-right}), les autres étant trop
compliqués à effectuer. Les changements de syntaxe qui ne
sont pas gérés par @code{convert-ly} sont énumérés dans
@ref{Updating files with convert-ly}.

Par exemple, dans les versions 2.4 et antérieures de LilyPond,
les accents et les lettres non-anglaises étaient entrées en
utilisant LaTeX -- par exemple, @samp{No\"el}.  À partir de la
version 2.6, le caratère @samp{ë} doit être entré directement
dans le fichier LilyPond comme caractère UTF-8.  
@code{convert-ly} ne peut pas changer tous les caractères
LaTeX en caractères UTF-8 ; vous devez mettre-à -jour vos vieux
fichiers LilyPond manuellement.



@node Troubleshooting (taking it all apart)
@section Troubleshooting (taking it all apart)

Tôt ou tard, vous écrirez un fichier que LilyPond ne peut
pas compiler. Les messages que LilyPond affiche peuvent
vous aider à trouver l'erreur, mais dans beaucoup de cas
vous aurez besoin de faire quelques recherches pour
déterminer la source du problème.

Les outils les plus puissants pour cet usage sont la ligne
de commentaires (indiquée par @code{%}), et le bloc de
commentaires (indiqué par @address@hidden ... address@hidden). Si vous
ne pouvez localiser le problème, commencez par mettre en
commentaires de grandes parties de votre fichier d'entrée.
Après avoir mis en commentaire une section, essayez
de compiler à nouveau. Si cela fonctionne, c'est que le
problème se situe dans cette partie du fichier. Si cela
ne fonctionne pas, continuez à mettre en commentaire
d'autres sections, jusqu'Ã  ce que vous ayez quelque chose
qui compile.

Dans un cas extrême, vous pourriez arriver à ceci :

@example
\score @{
  <<
    % \melody
    % \harmony
    % \bass
  >>
  address@hidden@}
@}
@end example

@noindent
(c'est-Ã -dire un fichier sans aucune musique)

Si cela arrive, ne vous découragez pas. Décommentez un peu,
la partie de basse par exemple, et voyez si ça fonctionne.
Si ce n'est pas le cas, placez en commentaire toute la
partie de basse, mais laissez décommenté @code{\bass} dans
le bloc @code{\score}.

@example
bass = \relative c' @{
address@hidden
  c4 c c c
  d d d d
address@hidden
@}
@end example

Maintenant commencez à décommenter petit à petit en partant de votre 
définition de @code{bass} jusqu'à ce que
vous localisiez la ligne qui pose problème.