lilypond-user-fr
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: traduction de "working"

From: Jean-Charles
Subject: Re: traduction de "working"
Date: Wed, 24 Jan 2007 19:10:30 +0100
User-agent: Thunderbird 1.5.0.9 (X11/20070111) 
Le 23.01.2007 16:52, Ludovic Sardain disait :

Bonjour à tous,
je viens de finir le premier jet de la traudction du fichier "working.itely". 

Je vous la livre en pièce jointe pour relecture. Veuillez s'il vous
plaît faire vos corrections directement sur le fichier et le renvoyer,
ou encore mieux, donner le résultat de la commande diff -u
ancienfichier fichiercorrigé

à bientôt

Ludovic



2007/1/24, Valentin Villenave <address@hidden>:


Bien vu, je l'avais laissée passer. Ci-joint un nouveau fichier


Flûte....

Jean-Charles, je viens de voir sur ton diff que tu as ajouté quelques
corrections (excellentes au demeurant) de ton crû au fichier que
j'avais envoyé. Du coup, ne tiens pas compte du fichier que je viens
de renvoyer (qui est fondé sur mon ancienne version, et de ce fait
n'intègre pas tes corrections) ; tu peux garder ton fichier, et juste
y ajouter le petit paragraphe que j'ai retraduit (en le modifiant si
tu le souhaites).
Pour éviter toute fausse route, ou mauvaise manipulation, voici un différentiel par rapport à l'original de Ludovic et ma dernière version, à utiliser selon votre préférence. 

Bonne soirée, je retourne à mon « Ave maris stella » des vêpres.

Jean-Charles

@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 dans la
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, pei importe la manière dont vous le code
est organisé. Néanmoins, quelques autres critères doîvent être pris en
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 modification peuvent être faites
automatiquement avec @code{convert-ly}, mais quelques-unes
peuvent demander une intervention manuelle. Les fichier 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 commande
(définie 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 piece. Nous pourrions simplement les copier et 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 déstiné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és 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 commentaires 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 commentaires
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 commentaires 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.


--- working.itely       2007-01-24 18:52:32.000000000 +0100
+++ working.itely.new   2007-01-24 18:49:38.000000000 +0100
@@ -28,28 +28,27 @@
 
 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 devriez-vous commencer à faire
-cela?
+exemples du tutoriel. Mais comment allez-vous vous y prendre pour
+commencer ?
 
-Tant que LilyPond peut comprendre vos fichiers et produire la
-sortie que vous souhaitez, l'organisation du code n'a pas
-d'importance.  Cependant, il y a quelques considérations à prendre
+Tant que LilyPond parvient à comprendre vos fichiers et produit le
+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
 en compte lorsque l'on écrit un fichier LilyPond.
 
 @itemize @bullet
address@hidden Si vous faites une erreur, la structure du fichier LilyPond
address@hidden Si vous faites une erreur, la structure même du fichier LilyPond
 peut permettre de la trouver plus ou moins facilement.
 
address@hidden Et si vous souhaites partager vos fichiers avec quelqu'un
address@hidden 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 vous donner un mal de
-crâne pendant une heure.
+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
+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 modification peuvent être faites
+s'améliore. La plupart des modification peuvent être faites
 automatiquement avec @code{convert-ly}, mais quelques-unes
 peuvent demander une intervention manuelle. Les fichier LilyPond
 peuvent être structurés de manière à être plus faciles à mettre
@@ -64,46 +63,42 @@
 @node General suggestions
 @subsection General suggestions
 
-Voici quelques conseils qui peuvent vous éviter ou résoudre des
-problèmes:
+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é.
+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.  A quelle fréquence faut-il en ajouter? 
-Cela dépends de la complexité de la musique.  Pour de la musique
+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.
 
address@hidden @strong{Une mesure par ligne de texte}.  S'il y a quelque 
address@hidden @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
+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.
 
address@hidden @strong{Commentez vos fichiers}.  Utilisez soit des
address@hidden @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
+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 années plus tard pour changer
+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é.
 
address@hidden @strong{Indentez vos crochets}.  Beaucoup de problèmes
-viennent de la différence de nombre de @address@hidden et de @address@hidden
address@hidden @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
@@ -121,7 +116,7 @@
 @itemize @bullet
 
 @item N'entrez qu'un seul système de la partition originale
-à la fois (mais toujours qu'une seule mesure par ligne de
+à 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
@@ -129,12 +124,12 @@
 
 @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
+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
-lorsque qu'il juge que c'est le mieux.
+quand il le souhaite.
 
 @end itemize
 
@@ -147,7 +142,7 @@
 
 @itemize @bullet
 
address@hidden @strong{utilisez un identifieur pour chaque voix},
address@hidden @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 
@@ -169,10 +164,10 @@
 
 @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
+mais pour les gros projets c'est absolument vital. Nous
 pouvons avoir besoin de changer la définition de
address@hidden, but alors nous n'avons besoin de le faire
-qu'une seule fois, et nous pouvons toujours éviter de
address@hidden, 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}.
 
@@ -193,7 +188,7 @@
 @cindex variables
 @cindex identifiers
 
-Jusqu'à maintenant, vous avez vu ce type de code:
+Jusqu'à maintenant, vous avez vu ce type de code :
 
 @lilypond[quote,verbatim,ragged-right]
 hornNotes = \relative c'' { c4 b dis c }
@@ -204,8 +199,7 @@
 }
 @end lilypond
 
-Vous pouvez même réaliser que cela peut être utile en musique
-minimaliste:
+Vous comprendrez combien cela peut être utile pour écrire de la musique 
minimaliste :
 
 @lilypond[quote,verbatim,ragged-right]
 fragA = \relative c'' { a4 a8. b16 }
@@ -218,9 +212,9 @@
 }
 @end lilypond
 
-Cependant, vous pouvez aussi utiliser ces identifieurs
+Cependant, vous pouvez aussi utiliser ces identificateurs
 (aussi connus sous le nom de variables, macros, ou commande
-(définie par l'utilisateur)) pour des modifications:
+(définie par l'utilisateur)) pour des modifications :
 
 @lilypond[quote,verbatim,ragged-right]
 dolce = \markup{ \italic \bold dolce }
@@ -242,11 +236,11 @@
 }
 @end lilypond
 
-Ces identifieurs sont évidemment utiles pour économiser
+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
-identifieur. C'est beaucoup plus laborieux à lire,
+identificateur. C'est beaucoup plus laborieux à lire,
 et particulièrement la dernière ligne.
 
 @example
@@ -285,10 +279,10 @@
 }
 @end lilypond
 
-Utiliser les identifieurs est aussi un bon moyen de réduire
+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
address@hidden) pour tous vos fichiers (voir @ref{Style sheets}),
address@hidden) 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}.
@@ -296,12 +290,12 @@
 @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
+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
+appliquer vos modifications ? Ou si vous souhaitez simplement
 séparer les modifications de la musique sur laquelle vous
-travailler?  C'est assez facile à réaliser.
+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
@@ -325,16 +319,14 @@
 }
 @end lilypond
 
-Il y a quelques problèmes de chevauchements; nous allons les
-fixez en utilisant les techniques de @ref{Moving objects}.
-Nous allons aussi faire quelquechose pour les définitions
-de @code{mpdolce} et @code{tempoMark}.  Elles produisent le
-résultat que nous désirons, mais nous voudrions les utiliser
-dans une autre piece.  Nous pourrions simplement les copier et
-coller au début de chauqe fichier, mais c'est fastidieux.
+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 piece. Nous pourrions simplement les copier et 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:
+Cachons-les dans un autre fichier :
 
 @example
 %%% save this to a file called "definitions.ly"
@@ -386,16 +378,16 @@
 @end lilypond
 
 C'est mieux, mais ajoutons encore quelques modifications.
-Le glissando est difficile à voir, alors nous allons
+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 le laisser au-dessus de la première note.
-Et finallement, mon professeur de composition déteste les
+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} avec ceci:
+Remplacez le fichier @file{definitions.ly} par ceci :
 
 @example
 %%%  definitions.ly
@@ -456,11 +448,11 @@
 }
 @end lilypond
 
-Le résultat est meilleur! Mais supposons maintenant que
-je veuille publier cette piece.  Mon professeur de composition
+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
+fichier @file{web-publish.ly}, et modifions-le. Puisque la
 musique est déstinée à produire un fichier pdf affiché sur
 écran, nous allons aussi augmenter la taille générale de
 la sortie.
@@ -523,18 +515,18 @@
 @end lilypond
 
 Il ne nous reste plus qu'à remplacer
address@hidden "definitions.ly"} avec
address@hidden "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. 
+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,
+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:
+professeur préfère. Le début du fichier @file{music.ly}
+ressemblerait alors à cela :
 
 @example
 \include "definitions.ly"
@@ -565,29 +557,29 @@
 
 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.  Quelques fois ces changements sont
-fait pour rendre les fichiers plus facile à lire et écrire,
-et d'autres fois pour intégrer de nouvelles fonctions.
+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
+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
+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
+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}.  A partir de la
+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
+LaTeX en caractères UTF-8 ; vous devez mettre-à-jour vos vieux
 fichiers LilyPond manuellement.
 
 
@@ -596,19 +588,19 @@
 @section Troubleshooting (taking it all apart)
 
 Tôt ou tard, vous écrirez un fichier que LilyPond ne peut
-pas compiler.  Les messages que LilyPond donnent peuvent
+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és par @address@hidden ... address@hidden).  Si vous
-ignorez où le problème se situe, commencez par mettre en
+commentaires (indiqués 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 commentaires une section, essayez
 de compiler à nouveau. Si cela fonctionne, c'est que le
-problème se situe dans cette partie du fichier.  Si cela
+problème se situe dans cette partie du fichier. Si cela
 ne fonctionne pas, continuez à mettre en commentaires
 d'autres sections, jusqu'à ce que vous ayez quelque chose
 qui compile.
@@ -629,7 +621,7 @@
 @noindent
 (c'est-à-dire un fichier sans aucune musique)
 
-Si cela arrive, ne laissez pas tomber. Décommentez un peu,
+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 commentaires toute la
 partie de basse, mais laissez décommenté @code{\bass} dans
@@ -644,7 +636,6 @@
 @}
 @end example
 
-Maintenant commencez à décommenter petit à petit de plus
-en plus de la définition de @code{bass} jusqu'à ce que
+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.
reply via email to
[Prev in Thread] Current Thread [Next in Thread]