]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/fr/usage/suggestions.itely
Imported Upstream version 2.19.45
[lilypond.git] / Documentation / fr / usage / suggestions.itely
index 864b06a4d736a89a84afaa576455c46d319395a6..885929d4c7ad55f96961e71a8e5bbc6626f001fb 100644 (file)
@@ -1,14 +1,14 @@
 @c -*- coding: utf-8; mode: texinfo; documentlanguage: fr -*-
 
 @ignore
-   Translation of GIT committish: bd751630011a6fbfcf069ec1fc41a8eaed8a6b87
+   Translation of GIT committish: 88a5dbc589b0d0434f8e640467b5ab57d14dc461
 
    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..
+   Guide, node Updating translation committishes..
 @end ignore
 
-@c \version "2.16.0"
+@c \version "2.19.21"
 
 @c Translators: Ludovic Sardain, Jean-Charles Malahieude
 @c Translation checkers: Jean-Yves Baudais, Valentin Villenave, John Mandereau
@@ -60,27 +60,20 @@ jour.
 @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 "@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 ?  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
@@ -89,27 +82,77 @@ mesure par ligne. Économiser de la place en tassant huit mesures par
 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}.
+@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{@}}.
+@code{@}} ou @code{<<} et @code{>>}.  Par exemple,
+
+@example
+\new Staff @{
+  \relative @{
+    r4 g'8 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 @{ r4 g'8 g c4 c8 d | e4 r8
+% Ossia section
+<< @{ f8 c c @} \new Staff @{ f8 f c @} >> r4 | @} @}
+@end example
 
-@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{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}.
 
@@ -125,7 +168,7 @@ c'est-à-dire de la musique déjà écrite,
 
 @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
@@ -148,6 +191,8 @@ encadrez les notes d'une partie pour instrument transpositeur dans un
 @example
 \transpose c @var{tonalité-naturelle} @{@dots{}@}
 @end example
+
+@noindent
 (où @var{tonalité-naturelle} correspond à celle de l'instrument en
 question) de telle sorte que la musique comprise dans cette variable se
 retrouve en ut.  Vous pourrez toujours transposer à l'inverse si besoin
@@ -167,8 +212,8 @@ sib pour une trompette en si bémol, ou lab pour une clarinette en la bémol.
 @section Projets d'envergure
 @translationof Large projects
 
-Lorsque l'on travaille sur un gros projet, il devient vital
-de structurer clairement ses fichiers LilyPond.
+Lorsque l'on travaille sur un gros projet, il devient vital de
+structurer clairement ses fichiers LilyPond.
 
 @itemize @bullet
 
@@ -179,8 +224,8 @@ dans une nouvelle version de LilyPond, alors que la définition du
 @code{violon} l'est beaucoup moins.
 
 @example
-violon = \relative c'' @{
-g4 c'8. e16
+violon = \relative @{
+g'4 c'8. e16
 @}
 @dots{}
 \score @{
@@ -192,7 +237,7 @@ g4 c'8. e16
 @}
 @end example
 
-@item @strong{Séparez les retouches} des définitions de musique.
+@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
@@ -203,8 +248,8 @@ définition du @code{violon}.
 @example
 fpuisp = _\markup@{
  \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
-violon = \relative c'' @{
-g4\fpuisp c'8. e16
+violon = \relative @{
+g'4\fpuisp c'8. e16
 @}
 @end example
 
@@ -252,20 +297,20 @@ le cas, placez en commentaire toute la partie de basse, mais laissez
 @code{\basse} décommenté dans le bloc @code{\score}.
 
 @example
-basse = \relative c' @{
+basse = \relative @{
 %@{
-  c4 c c c
+  c'4 c c c
   d d d d
 %@}
 @}
 @end example
 
-Maintenant commencez à décommenter petit à petit le partie de
+Maintenant commencez à décommenter petit à petit la partie de
 @code{basse} jusqu'à ce que vous localisiez la ligne qui pose
 problème.
 
 Une autre technique de débogage très utile est la construction
-d'un @rwebnamed{Exemples minimaux,exemple minimaliste}.
+d'un @rwebnamed{Exemples minimalistes,exemple minimaliste}.
 
 
 @node De la commande make et des fichiers Makefile
@@ -325,8 +370,8 @@ Symphonie/
 |   |-- figures.ily
 |   |-- hautbois.ily
 |   |-- trioCordes.ily
-|   |-- violonOne.ily
-|   `-- violonTwo.ily
+|   |-- violonUn.ily
+|   `-- violonDeux.ily
 |-- Partitions/
 |   |-- symphonie.ly
 |   |-- symphonieI.ly
@@ -464,7 +509,7 @@ Les choses se compliquent sous Windows.  Une fois GNU Make pour Windows
 téléchargé et installé, il vous faudra correctement définir le chemin
 d'accès au programme @emph{Make} -- dans les variables d'environnement
 du système --  afin que l'interpréteur de commandes DOS puisse le
-localiser.  Pour cela, faites un clic droite sur @qq{Poste de travail},
+localiser.  Pour cela, faites un clic droite sur « Poste de travail »,
 choisissez @code{Propriétés} puis @code{Avancées}.  Cliquez sur
 @code{Variables d'environnement} puis, dans l'onglet
 @code{Variables système}, mettez @code{path} en surbrillance et
@@ -491,7 +536,8 @@ LILY_CMD = lilypond -ddelete-intermediate-files \
                     -dno-point-and-click \
                     -djob-count=$(NUMBER_OF_PROCESSORS)
 
-#get the 8.3 name of CURDIR (workaround for spaces in PATH)
+#Détermination du nom de CURDIR sous sa forme 8.3
+#(solution pour les espaces dans le PATH)
 workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
           do @@echo %%~sb)