@c -*- coding: utf-8; mode: texinfo; documentlanguage: fr -*-
+
@ignore
- Translation of GIT committish: 057106293b07b74b00553fe4dc3dfac5c1f3b682
+ Translation of GIT committish: b5bcf58b17f2e5d8a76740050fe9b7212748bd7b
When revising a translation, copy the HEAD committish of the
version that you are working on. For details, see the Contributors'
Guide, node Updating translation committishes..
@end ignore
-@c \version "2.13.36"
+@c \version "2.16.0"
@c Translators: Ludovic Sardain, Jean-Charles Malahieude
-@c Translation checkers: Jean-Yves Baudais, Valentin Villenave, John Mandereau, Jean-Charles Malahieude
+@c Translation checkers: Jean-Yves Baudais, Valentin Villenave, John Mandereau
@node Suggestions pour la saisie de fichiers LilyPond
-@chapter Suggestions pour la saisie de fichiers
+@chapter Suggestions pour la saisie de fichiers LilyPond
@translationof Suggestions for writing files
Maintenant vous êtes prêt à travailler sur de plus gros fichiers
LilyPond -- des pièces entières, et plus seulement les petits
-exemples du tutoriel. Mais comment devriez-vous vous y prendre@tie{}?
+exemples du tutoriel. Mais comment devriez-vous vous y prendre ?
Tant que LilyPond parvient à comprendre vos fichiers et produit le
résultat que vous souhaitez, peu importe la manière dont le code est
@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@tie{}?
+vous souhaitez modifier vos propres fichiers dans quelques années ?
Si certains fichiers LilyPond sont compréhensibles au premier coup
d'œil, d'autres vous feront vous arracher les cheveux pendant une heure.
@item
Et si vous souhaitez mettre à jour votre fichier pour l'utiliser avec
-une version plus récente de LilyPond@tie{}? La syntaxe du
-langage d'entrée change parfois lorsque LilyPond s'améliore. La
-plupart des changements peuvent être appliqués automatiquement avec
-@code{convert-ly}, mais quelques-uns peuvent requérir une intervention
-manuelle. Vos fichiers LilyPond peuvent être structurés de manière à
-faciliter leur mise à jour.
+une version plus récente de LilyPond ? La syntaxe du langage d'entrée
+change parfois lorsque LilyPond s'améliore. La plupart des changements
+peuvent être appliqués automatiquement avec @code{convert-ly}, mais
+quelques-uns peuvent requérir une intervention manuelle. Vos fichiers
+LilyPond peuvent être structurés de manière à faciliter leur mise à
+jour.
@end itemize
@menu
@section Suggestions générales
@translationof General suggestions
-Voici quelques conseils qui peuvent vous éviter certains problèmes ou
-en résoudre d'autres.
+Voici quelques conseils qui vous permettront d'éviter, voire même
+résoudre, la plupart des problèmes de saisie.
@itemize
-@item @strong{Ajoutez le numéro de version dans chaque fichier}.
-Notez que chaque fichier modèle contient une ligne
-@code{\version@tie{}"@version{}"}. 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 on
-utilisait quelques années auparavant. L'utilitaire @command{convert-ly}
-demande que vous spécifiiez la version de LilyPond vous utilisiez alors.
-
-@item @strong{Ajoutez des contrôles}
-@rusernamed{Vérifications d'octave,d'octaviation} et
-@rusernamed{Vérification des limites et numéros de mesure,de limite ou
-numéro de mesure}. Si vous avez ajouté des contrôles de loin en loin,
-et que vous faites une erreur, vous pourrez la retrouver plus
-rapidement. @qq{De loin en loin}, qu'est-ce à dire@tie{}? 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 très complexe, peut-être
-à chaque mesure.
+@item @strong{Ajoutez toujours le numéro de version dans chaque
+fichier}, quelle que soit sa taille. Par expérience, il est très
+difficile de se rappeler quelle version de LilyPond a servi au moment de
+la création d'un fichier. Ceci s'avèrera d'autant plus utile lors d'une
+@rprogramnamed{Mise à jour avec convert-ly, mise à jour}
+(@command{convert-ly} requiert la présence d'une ligne @code{\version})
+ou si vous transmettez votre fichier à d'autres utilisateurs -- y
+compris pour demander de l'aide sur les listes de diffusion. Vous
+noterez par ailleurs que tous les fichiers modèles de LilyPond ont une
+mention @code{\version}.
@item @strong{Une mesure par ligne de texte}.
Si la musique en elle-même ou le résultat que vous désirez contient
ligne, ça ne vaut pas vraiment le coup si l'on doit corriger vos
fichiers.
+@item @strong{Ajoutez des contrôles}
+@rusernamed{Vérifications d'octave,d'octaviation} et
+@rusernamed{Vérification des limites et numéros de mesure,de limite ou
+numéro de mesure}. Si vous avez ajouté des contrôles de loin en loin,
+et que vous faites une erreur, vous pourrez la retrouver plus
+rapidement. « De loin en loin », qu'est-ce à dire ? Cela dépend
+de la complexité de la musique. Pour de la musique très simple, à
+certains endroits stratégiques. Pour de la musique très complexe ou
+avec une multiplicité de voix, peut-être à chaque mesure.
+
@item @strong{Ajoutez des commentaires}.
Utilisez soit des numéros de mesure (assez souvent), soit des références
-au contenu musical -- @qq{second thème des violons}, @qq{quatrième
-variation}, etc. Vous pouvez ne pas avoir besoin des commentaires
+au contenu musical -- « second thème des violons », « 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 n'y avez pas adjoint de commentaires.
-@item @strong{Indentez les accolades}.
-Beaucoup de problèmes viennent d'un défaut de parité entre @code{@{} et
-@code{@}}.
-
@item @strong{Mentionnez les durées}
au début de chaque section ou variable. Si vous saisissez @code{c4 d e}
au début d'une phrase, vous vous épargnerez des problèmes si, plus tard,
vous modifiez votre musique.
+@item @strong{Indentez les accolades et indications de musique en parallèle}.
+Beaucoup de problèmes viennent d'un défaut de parité entre @code{@{} et
+@code{@}} ou @code{<<} et @code{>>}. Par exemple,
+
+@example
+\new Staff @{
+ \relative g' @{
+ r4 g8 g c8 c4 d |
+ e4 r8 |
+ % Ossia section
+ <<
+ @{ f8 c c | @}
+ \new Staff @{
+ f8 f c |
+ @}
+ >>
+ r4 |
+ @}
+@}
+@end example
+
+@noindent
+est bien plus facile à appréhender que
+
+@example
+\new Staff @{ \relative g' @{ r4 g8 g c4 c8 d | e4 r8
+% Ossia section
+<< @{ f8 c c @} \new Staff @{ f8 f c @} >> r4 | @} @}
+@end example
+
+
@item @strong{Séparez les affinages de mise en forme}
-de la musique elle-même. Voyez
+de la musique elle-même, ne serait-ce qu'en positionnant les dérogations
+au sein du bloc @code{\layout} :
+
+@example
+\score @{
+ @var{@dots{}musique@dots{}}
+ \layout @{
+ \override TabStaff.Stemstencil = ##f
+ @}
+@}
+@end example
+
+Ceci n'aura par pour effet de générer un contexte supplémentaire, mais
+s'appliquera dès sa création. Voyez
@rlearning{Économie de saisie grâce aux identificateurs et fonctions} et
@rlearning{Feuilles de style}.
@itemize
-@item
+@item
n'entrez qu'un seul système de la partition originale
à la fois -- avec toujours une seule mesure par ligne de texte --,
et vérifiez chaque système lorsqu'il est terminé. Vous pouvez
utiliser les commandes @code{showLastLength} et @code{showFirstLength}
pour accélérer la compilation -- voir
-@ruser{Ignorer des passages de la partition}@tie{};
+@ruser{Ignorer des passages de la partition} ;
@item
-définissez @code{mBreak = @{\break @}} et insérez @code{\mBreak} dans le
-fichier d'entrée pour obtenir des sauts de ligne identiques à la
+définissez @code{mBreak = @{ \break @}} et insérez @code{\mBreak} dans
+le fichier d'entrée pour obtenir des sauts de ligne identiques à la
partition originale. Cela facilite 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@tie{}=@tie{}@{@tie{}@}}
-pour enlever tous ces sauts de ligne, et laisser LilyPond placer les
-sauts de ligne selon son propre algorithme@tie{};
+votre musique, vous pouvez définir @code{mBreak = @{ @}}
+pour enlever tous ces sauts de ligne, et laisser LilyPond placer les
+sauts de ligne selon son propre algorithme ;
@item
encadrez les notes d'une partie pour instrument transpositeur dans un
@example
-\transpose c @var{tonalité-naturelle} @{...@}
+\transpose c @var{tonalité-naturelle} @{@dots{}@}
@end example
(où @var{tonalité-naturelle} correspond à celle de l'instrument en
question) de telle sorte que la musique comprise dans cette variable se
@code{violon} l'est beaucoup moins.
@example
-violin = \relative c'' @{
+violon = \relative c'' @{
g4 c'8. e16
@}
-...
+@dots{}
\score @{
\new GrandStaff @{
\new Staff @{
- \violin
+ \violon
@}
@}
@}
@item @strong{Séparez les retouches} des définitions de musique.
Nous vous avons déjà invité à adopter une telle pratique, qui
par ailleurs devient vitale pour des projets d'importance. Nous
-pouvons avoir besoin de changer la définition de
-@code{fpuisp}, mais dans ce cas nous n'aurons besoin de le faire
-qu'une seule fois, et nous pourrons encore éviter de
-modifier quoi que ce soit à l'intérieur de la définition
-du @code{violon}.
+pouvons avoir besoin de changer la définition de @code{fpuisp}, mais
+dans ce cas nous n'aurons besoin de le faire qu'une seule fois, et nous
+pourrons encore éviter de modifier quoi que ce soit à l'intérieur de la
+définition du @code{violon}.
@example
fpuisp = _\markup@{
\dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
-violin = \relative c'' @{
+violon = \relative c'' @{
g4\fpuisp c'8. e16
@}
@end example
Pour ce faire, les outils les plus puissants sont le commentaire de
fin de ligne, indiqué par @code{%}, et le commentaire multilignes (ou
-bloc de commentaire), indiqué par @code{%@{ ... %@}}. Si vous ne
+bloc de commentaire), indiqué par @code{%@{ @dots{} %@}}. Si vous ne
pouvez localiser le problème, commencez par mettre en commentaire de
grandes parties de votre fichier source. Après avoir mis en
commentaire une section, essayez de compiler à nouveau. Si cela
d'un @rwebnamed{Exemples minimaux,exemple minimaliste}.
-
-
@node De la commande make et des fichiers Makefile
-@section De la commande @command{make} et des fichiers @code{Makefile}
+@section De la commande make et des fichiers Makefile
@translationof Make and Makefiles
@cindex makefiles
partition séparée pour chacun des pupitres -- ou bien si votre projet
requiert certaines commandes particulières comme @code{lilypond-book}.
Les @emph{Makefiles} varient tant en complexité qu'en flexibilité selon
-les besoin et les aptitudes de celui qui les crée. Le programme GNU Make
-est installé par défaut sur les distributions Linux et sur MacOS@tie{}X,
-et il en existe une version pour les environnements Windows.
+les besoin et les aptitudes de celui qui les crée. Le programme GNU
+Make est installé par défaut sur les distributions GNU/Linux et sur
+MacOS X, et il en existe une version pour les environnements Windows.
Consultez le @strong{GNU Make Manual} pour plus de détails sur ce dont
@code{make} est capable -- vous pourrez même en trouver des versions
françaises à l'aide des moteurs de recherche --, dans la mesure où ce
-qui suit ne donne qu'un bref apperçu de ses possibilités.
+qui suit ne donne qu'un bref aperçu de ses possibilités.
Les commandes permettant de définir les règles diffèrent selon la
-plate-forme@tie{}: si les différents Linux et MacOS@tie{}X utilisent
-@code{bash}, Windows utilise @code{cmd}. Dans le cas de MacOS@tie{}X,
+plate-forme : si les différents GNU/Linux et MacOS X utilisent
+@code{bash}, Windows utilise @code{cmd}. Dans le cas de MacOS X,
vous devrez toutefois configurer votre système de telle sorte qu'il
utilise l'interpréteur en ligne de commande. Voici quelques exemples de
-fichier @emph{Makefile}, avec une version pour Linux ou MacOS et une
+fichier @emph{Makefile}, avec une version pour GNU/Linux ou MacOS et une
pour Windows.
Pour commencer, une pièce à quatre mouvements pour orchestre et dont les
-fichiers sont répartis selon l'arborescence suivante@tie{}:
+fichiers sont répartis selon l'arborescence suivante :
@example
Symphonie/
| `-- symphonieIV.ly
|-- PDF/
|-- Pupitres/
-| |-- symphon-alto.ly
+| |-- symphonie-alto.ly
| |-- symphonie-cello.ly
| |-- symphonie-cor.ly
| |-- symphonie-hautbois.ly
@end example
Les fichiers @file{.ly} des répertoires @code{Partitions} et
-@code{Pupitres} récupèreront la notation des fichiers @file{.ily}
-contenus dans le répertoire @code{Notes}@tie{}:
+@code{Pupitres} récupéreront la notation des fichiers @file{.ily}
+contenus dans le répertoire @code{Notes} :
@example
-%%% début du fichier "symphone-cello.ly"
+%%% début du fichier "symphonie-cello.ly"
\include ../symphonieDefs.ily
\include ../Notes/cello.ily
@end example
pupitre). Il contient aussi une cible @code{archive} chargée de générer
une archive des fichiers source qui pourra être diffusée sur la toile ou
transmise par courriel. Voici ce que contiendrait ce @emph{Makefile}
-pour Linux ou MacOS@tie{}X. Ce fichier doit être enregistré sous le nom
+pour GNU/Linux ou MacOS X. Ce fichier doit être enregistré sous le nom
de @code{Makefile} à la racine du projet -- ici @code{Symphonie}.
@warning{Lorsque vous définissez une cible ou une règle sur plusieurs
# Les .pdf résultants iront dans le sous-répertoire "PDF" et les fichiers
# .midi dans le sous-répertoire "MIDI".
%.pdf %.midi: %.ly
- $(LILY_CMD) $<; \ # cette ligne commence par une tabulation
+ $(LILY_CMD) $<; \ # cette ligne commence par une tabulation
if test -f "$*.pdf"; then \
mv "$*.pdf" PDF/; \
fi; \
$(piece)-violonUn.pdf: $(piece)-violonUn.ly violonUn.ily
$(piece)-violonDeux.pdf: $(piece)-violonDeux.ly violonDeux.ily
-# Lancer `make score' pour générer l'intégrale des quatre mouvements en
-# un seul fichier.
+# Lancer `make score' pour générer l'intégrale des quatre mouvements
+# en un seul fichier.
.PHONY: score
score: $(piece).pdf
all: score parties mouvements
archive:
- tar -cvvf symphonie.tar \ # cette ligne commence par une tabulation
+ tar -cvvf symphonie.tar \ # cette ligne commence par une tabulation
--exclude=*pdf --exclude=*~ \
--exclude=*midi --exclude=*.tar \
../Symphonie/*
localiser. Pour cela, faites un clic droite sur @qq{Poste de travail},
choisissez @code{Propriétés} puis @code{Avancées}. Cliquez sur
@code{Variables d'environnement} puis, dans l'onglet
-@code{Variables@tie{}système}, mettez @code{path} en surbrillance et
+@code{Variables système}, mettez @code{path} en surbrillance et
cliquez sur @code{Modifier}. Ajoutez alors le chemin d'accès complet à
-l'exécutable de GNU Make, qui devrait ressembler à@tie{}:
+l'exécutable de GNU Make, qui devrait ressembler à :
@example
C:\Program Files\GnuWin32\bin
@command{lilypond-book} réalisé avec @LaTeX{}. Ce projet contiendra un
index, ce qui nécessitera de lancer une deuxième fois @command{latex}
pour mettre à jour les liens. Les fichiers résultants iront dans le
-répertoire @code{out} pour ce qui est des .pdf et dans le répertoire
+répertoire @code{out} pour ce qui est des pdf et dans le répertoire
@code{htmlout} pour ce qui est du html.
@example
devrez enregistrer les lignes suivantes dans un fichier
@code{construire.bat} ou @code{construire.cmd}. Ce fichier pourra être
exécuté soit en ligne de commande, soit par un double clic sur son
-icone.
+icône.
@example
lilypond-book --output=out --pdf monprojet.lytex
copy out\monprojet.pdf MonProjet.pdf
@end example
-
@seealso
Manuel d'utilisation :
@ref{Utilisation en ligne de commande},
projects / lilypond.git / blobdiff