@c -*- coding: utf-8; mode: texinfo; documentlanguage: fr -*-
@ignore
- Translation of GIT committish: 44c3a53cb34d08a57838ae56c407216277e4c3f0
+ Translation of GIT committish: e2f786e15c2f1c7e71518c5e2d134bc31fd587f8
When revising a translation, copy the HEAD committish of the
version that you are working on. For details, see the Contributors'
@lisp
guile> (define mypair (cons 123 "hello there")
-... )
+@dots{} )
guile> (car mypair)
123
guile> (cdr mypair)
@noindent
-Note : @code{cdr} se prononce @qq{couldeur}, comme l'indiquent Sussman et
+Note : @code{cdr} se prononce @qq{couldeur}, comme l'indiquent Sussman et
Abelson -- voir
@uref{http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#footnote_Temp_133}.
@code{define} :
@example
-(define (nom-fonction argument1 argument2 ... argumentn)
+(define (nom-fonction argument1 argument2@dots{} argumentn)
expression-scheme-qui-donnera-une-valeur-en-retour)
@end example
@lisp
guile> (let ((x 2) (y 3) (z 4)) (display (+ x y)) (display (- z 4))
-... (+ (* x y) (/ z x)))
+@dots{} (+ (* x y) (/ z x)))
508
@end lisp
@example
(cond (expression-test-1 expression-résultat-séquence-1)
(expression-test-2 expression-résultat-séquence-2)
- ...
+ @dots{}
(expression-test-n expression-résultat-séquence-n))
@end example
guile> (define a 6)
guile> (define b 8)
guile> (cond ((< a b) "a est plus petit que b")
-... ((= a b) "a égale b")
-... ((> a b) "a est plus grand que b"))
+@dots{} ((= a b) "a égale b")
+@dots{} ((> a b) "a est plus grand que b"))
"a est plus petit que b"
@end lisp
phrases. LilyPond dispose d'un analyseur lexical (appelé @emph{lexer})
qui sait identifier les jetons -- nombres, chaînes, éléments Scheme,
hauteurs etc. -- ainsi que d'un analyseur syntaxique (appelé
-@emph{parser}) -- voir
+@emph{parser}) -- voir
@rcontribnamed{LilyPond grammar, Grammaire de LilyPond}. Dès lors
que le programme sait quelle règle grammaticale particulière doit
s'appliquer, il exécute les consignes qui lui sont associées.
est convertie, en interne, en une définition Scheme :
@example
-(define traLaLa @var{valeur Scheme de `@code{... }'})
+(define traLaLa @var{valeur Scheme de `@code{@dots{}}'})
@end example
Cela signifie que variables LilyPond et variables Scheme peuvent tout à
aussi bien pu écrire
@example
-...
+@dots{}
$(make-sequential-music (list newLa))
@end example
dernière partie de notre fonction pourrait s'écrire ainsi :
@example
-...
+@dots{}
@{ #@@newLa @}
@end example
#(define (nopc)
(ly:set-option 'point-and-click #f))
-...
+@dots{}
#(nopc)
@{ c'4 @}
@end example
Par défaut, LilyPond affichera ces messages sur la console, parmi toutes
les autres informations. Vous pouvez, afin de les isoler et de garder
-le résultat des commandes @code{\display@{TRUC@}}, rediriger la sortie
-vers un fichier :
+le résultat des commandes @code{\display@{TRUC@}}, spécifier un
+port optionnel à utiliser pour la sortie :
@example
-lilypond file.ly >display.txt
+@{
+ \displayMusic #(open-output-file "display.txt") @{ c'4\f @}
+@}
@end example
-Un peu de Scheme combiné à notre code LilyPond, et les seules
-informations qui nous intéressent se retrouveront directement dans un
-fichier indépendant :
+Ceci aura pour effet d'écraser tout fichier précédemment généré.
+Lorsque plusieurs expressions doivent être retranscrites, il suffit de
+faire appel à une variable pour le port puis de la réutiliser :
@example
@{
- #(with-output-to-file "display.txt"
- (lambda () #@{ \displayMusic @{ c'4\f @} #@}))
+ port = #(open-output-file "display.txt")
+ \displayMusic \port @{ c'4\f @}
+ \displayMusic \port @{ d'4 @}
+ #(close-output-port port)
@}
@end example
+La documentation de Guile fournit une description détaillée des ports.
+Clôturer un port n'est requis que si vous désirez consulter le fichier
+avant que LilyPond n'ait fini, ce dont nous ne nous sommes pas préoccupé
+dans le premier exemple.
+
L'information sera encore plus lisible après un peu de mise en forme :
@example
'pitch (ly:make-pitch 0 0 0))))
@end example
-Une séquence musicale @code{@{ ... @}} se voit attribuer le nom de
+Une séquence musicale @code{@{ @dots{} @}} se voit attribuer le nom de
@code{SequentialMusic}, et les expressions qu'elle contient sont
enregistrées en tant que liste dans sa propriété @code{'elements}. Une
note est représentée par un objet @code{NoteEvent} -- contenant les
-- de telle sorte que les deux notes constituent la séquence -- puis
d'ajouter un @code{SlurEvent} à la propriété @code{'articulations} de
chacune d'elles, et enfin réaliser un @code{SequentialMusic} de ces deux
-@code{EventChords}. En tenant compte du fait que, dans le cadre d'un
-ajout, une propriété non définie est lue @code{'()} (une liste vide),
-aucune vérification n'est requise avant d'introduire un nouvel élément
-en tête de la propriété @code{articulations}.
+éléments @code{NoteEvent}. En tenant compte du fait que, dans le cadre
+d'un ajout, une propriété non définie est lue @code{'()} (une liste
+vide), aucune vérification n'est requise avant d'introduire un nouvel
+élément en tête de la propriété @code{articulations}.
@example
doubleSlur = #(define-music-function (parser location note) (ly:music?)
doigté, individuellement à l'une des notes d'un accord, ce qui est
impossible dans le cadre d'une simple fusion de musique indépendante.
-Un @code{$variable} au milieu de la notation @code{#@{...#@}} se
+Un @code{$variable} au milieu de la notation @code{#@{ @dots{} #@}} se
comporte exactement comme un banal @code{\variable} en notation LilyPond
traditionnelle. Nous savons déjà que
excellente pratique que l'on retrouve dans de nombreux autres langages.
@example
-"Ajoute un accent..."
+"Ajoute un accent@dots{}"
@end example
@noindent
projects / lilypond.git / blobdiff