Subject: Hauteurs et tags

From: Denis Bitouzé <[email-masked]>
Date: Fri, 16 Dec 2011 17:12:58 +0100

Bonjour,

dans l'exemple suivant, le do initial et le ré

  1. /ne/ sont /pas/ conjoints dans le tag a ;

  2.      sont       conjoints dans le tag b ;

Ce qui se passe dans le tab b est ce qu'on attend, mais le résultat
obtenu dans la tag a est AMHA inattendu : c'est comme si le « ' » du tag
b avait été pris en compte...

Merci d'avance pour tout éclaircissement (et solution pour obtenir ce
à quoi je m'attends :)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
music = \relative c' {
    \tag #'a  { c8 }
    \tag #'b  { c'8 }
    d e f g a b c
} 

\score {
  \keepWithTag #'a \music
}
\score {
  \keepWithTag #'b \music
}
-- 
Denis

---

From: Jean-Charles Malahieude <[email-masked]>
Date: Fri, 16 Dec 2011 19:18:23 +0100

> Merci d'avance pour tout éclaircissement (et solution pour obtenir ce

J'aimerais connaître ce que tu désires obtenir exactement.

En ce qui me concerne, le tag A ne produit rien d'inattendu :

Tu travaille en mode relatif, en fixant la première hauteur rencontrée 
relativement au do médium, une ligne supplémentaire sous la portée en 
clef de sol.
La première note est placée relativement à l'étalon, soit à moins d'une 
quinte. C'est un do ; il se place là où il faut.
La deuxième note _que LilyPond lit_ est un do qui se situe AU-DELÀ D'UNE 
QUARTE SUPÉRIEURE de la note qui précède. C'est un do au-dessus du 
précédent.
La troisième note lue est un ré à moins d'un quinte, il est juste au-dessus.

Je reconnais avoir eu quelques sauts d'octave intempestifs lorsqu'Arthur 
était en gestation ! J'ai compris que lors de la phase d'analyse des 
saisies, Lilypond pratique au fil de l'eau sans s'occuper des tags, ce 
qui peut requérir quelques ajustements, y compris modifier la /longueur/ 
du tag pour recaler les écarts.

@+
Jean-Charles

---

From: Denis Bitouzé <[email-masked]>
Date: Fri, 16 Dec 2011 21:40:54 +0100

Le vendredi 16/12/11 à 19h18,

> J'aimerais connaître ce que tu désires obtenir exactement.

Ah, désolé, mon manque de maîtrise de LilyPond m'a certainement empêché
de voir que ça ne coulait pas de source. Cf. à la fin du message.

> Tu travaille en mode relatif, en fixant la première hauteur
> rencontrée relativement au do médium, une ligne supplémentaire sous
> la portée en clef de sol.

OK.

> La première note est placée relativement à l'étalon, soit à moins
> d'une quinte. C'est un do ; il se place là où il faut.

OK.

> La deuxième note _que LilyPond lit_ est un do qui se situe AU-DELÀ
> D'UNE QUARTE SUPÉRIEURE de la note qui précède. C'est un do au-dessus
> du précédent.

C'est là que ça m'échappe : je pensais que le c'8 n'était pas lu dans
le tag a puisqu'il est tagué b :

  « Musique balisée précédée de \keepWithTag #'nom <=> Musique non
  balisée et musique balisée par nom seront incluses ; la musique
  balisée autrement est exclue. »

(d'après
http://lilypond.org/doc/v2.14/Documentation/notation/different-editions-from-one-source#using-tags).

> La troisième note lue est un ré à moins d'un quinte, il est juste

Ça, OK.

> Je reconnais avoir eu quelques sauts d'octave intempestifs
> lorsqu'Arthur était en gestation !

Ha, tu vois ! ;)

> J'ai compris que lors de la phase d'analyse des saisies, Lilypond
> pratique au fil de l'eau sans s'occuper des tags, ce qui peut
> requérir quelques ajustements, y compris modifier la /longueur/ du
> tag pour recaler les écarts.

C'est ça qui doit me manquer : la façon de stipuler la /longueur/ du
tag. Peux-tu m'en dire davantage ou m'indiquer là où c'est expliqué
dans la documentation ?

Merci en tous cas !

Je précise maintenant ce à quoi je m'attendais : je pensais que,
dans le morceau suivant, les deux premiers scores donneraient la même
chose.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
musicSansTag = \relative c' {
  c8 d e f g a b c
} 

musicAvecTag = \relative c' {
  \tag #'a  { c8 }
  \tag #'b  { c'8 }
  d e f g a b c
} 

\score {
  \musicSansTag
}
\score {
  \keepWithTag #'a \musicAvecTag
}
\score {
  \keepWithTag #'b \musicAvecTag
}
-- 
Denis

---

From: Denis Bitouzé <[email-masked]>
Date: Sat, 17 Dec 2011 08:37:50 +0100

Le vendredi 16/12/11 à 21h40,

> http://lilypond.org/doc/v2.14/Documentation/notation/different-editions-from-one-source#using-tags).

Bon, je suis finalement tombé sur ce post :

http://lilypond-french-users.1298960.n2.nabble.com/Transparence-des-tags-td5944700.html

qui montre que je ne suis pas le seul à trouver contre-intuitif le
fonctionnement des tags. Je suis d'accord avec Philhar, la
documentation devrait absolument le signaler et je propose donc de
remplacer :

  « Musique balisée précédée de \keepWithTag #'nom <=> Musique non
  balisée et musique balisée par nom sont incluses ; la musique
  balisée autrement est exclue. »

par (modifications en capitales) :

  « Musique balisée précédée de \keepWithTag #'nom <=> Musique non
  balisée et musique balisée par nom SONT GRAVÉES ; la musique
  balisée autrement N'EST PAS GRAVÉE (MAIS N'EST PAS IGNORÉE :
  PAR EXEMPLE, LES CHANGEMENTS D'OCTAVE S'Y TROUVANT SONT PRIS EN
  COMPTE !) »

Ceci étant, je ne vois pour l'instant que des inconvénients à ce que la
musique qui n'est pas gravée ne soit pas ignorée : cela présente-t-il
un intérêt qui m'aurait échappé ? Sinon, cela vaut-il le coup de faire
une demande aux développeurs de LilyPond pour modifier le
fonctionnement des tags ou pour que soit proposée une nouvelle
commande ?
-- 
Denis

---

From: "j-f.lucarelli" <[email-masked]>
Date: Sat, 17 Dec 2011 12:59:12 +0100

> Je suis d'accord avec Philhar, la
Après de nombreux déboires dans les \tags en cascade, j'ai pris la bonne résolution de démarrer chaque code "taggé" par une hauteur absolue.
Je comprends les programmeurs qui ont voulu donner une portée générale à cette instruction, mais dans neuf cas sur dix, il s'agit d'expressions musicales destinées à être imprimées ou ignorées. Il serait donc plus sain que l'expression ignorée le soit complètement, y compris dans la relativité des hauteurs.
Je souscris donc entièrement à la suggestion de Denis. Malheureusement, il y aura une multitude de codes à revoir si on change les règles.

Il serait sans doute préférable d'introduire une nouvelle instruction (encore ...) du genre \case (comme en C) qui serait gérée comme les tags, mais en ignorant le code si celui-ci n'est pas "exécuté".

Cordialement,

Jean-François
>_______________________________________________
>liste de diffusion lilypond-user-fr
>[email-masked]
>https://lists.gnu.org/mailman/listinfo/lilypond-user-fr

========================================

---

From: Denis Bitouzé <[email-masked]>
Date: Sat, 17 Dec 2011 20:15:59 +0100

Le samedi 17/12/11 à 12h59,
"j-f.lucarelli" <[email-masked]> a écrit :

> Malheureusement, il y aura une multitude de codes à revoir si on
> change les règles.

La précision de la version de l'application ne permet-elle pas qu'une
commande fournie par LilyPond soit redéfinie tout en évitant ce genre
de déboires ?
-- 
Denis

---

From: "j-f.lucarelli" <[email-masked]>
Date: Sat, 17 Dec 2011 21:16:18 +0100

== En réponse au message du 17-12-2011, 20:16:03 ==

>commande fournie par LilyPond soit redéfinie tout en évitant ce genre

Sans doute. Je n'ai jamais utilisé le programme qui modifie le code en fonction du numéro de la version. J'ignore donc quelle est sa puissance. Quoique dans ce cas précis, la conversion semble assez systématique.

Cordialement,

Jean-François