Hauteurs et tags

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 :slight_smile:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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

Le 16/12/2011 17:12, Denis Bitouzé disait :

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 :slight_smile:

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

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.

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.

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
LilyPond Notation Reference: 3.3.2 Different editions from one source).

La troisième note lue est un ré à moins d'un quinte, il est juste
au-dessus.

Ça, OK.

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

Ha, tu vois ! :wink:

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
}

···

Le vendredi 16/12/11 à 19h18, Jean-Charles Malahieude <****@****> a écrit :
--
Denis

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 ?

···

Le vendredi 16/12/11 à 21h40, Denis Bitouzé <****@****> a écrit :

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
LilyPond Notation Reference: 3.3.2 Different editions from one source).

--
Denis

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

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
lilypond-user-fr@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user-fr

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

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 ?

···

Le samedi 17/12/11 à 12h59, "j-f.lucarelli" <****@****> a écrit :

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

--
Denis

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

···

Le samedi 17/12/11 à 12h59, >"j-f.lucarelli" <****@****> 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

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

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