Re: Structure de fichiers, arrangements et pdf multiples

[Nicolas Sceaux]

Le 3 août 09 à 01:00, Cécile Huneau a écrit :

> [...]
>
> %%%%
> %% Générer
> %%%%
> \score {
>     \new StaffGroup
>     <<
>         \new Staff = "Voix A" { << \relative sol { \stemNeutral  
> \clef F \myMusicVoixA } \\ \myStructure >> }
>         \new Staff = "Voix B" { << \relative sol { \stemNeutral  
> \clef F \myMusicVoixB } \\ \myStructure >> }
>     >>
> }

Je trouve qu'il serait plus clair de mettre les "\relative sol" au
niveau de la définition des voix (les variables myMusicVoixA et B),
de façon à ce que lorsqu'on lit ces définitions on sache qu'il faut
les lire en relatif plutôt qu'en absolu.

Il n'est pas rare de voir ta variable `myStructure' nommée `global'
dans les partitions LilyPond. D'ailleurs dans un premier temps en
voyant ce nom j'ai cru qu'il allait s'agir de la structure de la
partition (l'organisation des portées).

En supposant que les \relative sont déplacés au niveau définition
des voix, la structure de la partition devient :

\score {
  \new StaffGroup <<
    \new Staff << \myStructure \clef F \myMusicVoixA >>
    \new Staff << \myStructure \clef F \myMusicVoixB >>
  >>
}

ce qui est plus lisible.

Mais à part ça, la structure du fichier est correcte. Il est aussi  
souvent
d'usage de placer la définitions de voix dans un fichier, et la  
structure
dans un autre, le second incluant le premier.

> Le dernier exemple de cette page (qui me semble un peu buggé) a  
> beaucoup sollicité mon neurone solitaire, sans résultat : http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Multiple-voices#Writing-music-in-parallel

A mon sens, quand on copie une partition existante, cette bidouille
de \parallelMusic n'est pas utile.

> [...]
> Je suis partie sur l'utilisation de tags à l'intérieur de mes  
> variables de notes, ça marche plutôt bien, sauf que l'écriture en  
> relative devient lourde à gérer, et cela ne me plait pas trop de  
> mettre autre chose que des notes dans mes variables notes... j'ai  
> l'impression que ça va vite devenir un boxon monstrueux.

Je trouve les \tag assez casse pied à utiliser, à cause des  
\removeWithTags
et compagnie que cela force à utiliser systématiquement.

Les \tags ajoutent un attribut à la musique saisie, et ensuite avec les
fonctions qui vont bien (\removeWithTag et \keepWithTag), on peut
sélectionner les bouts de musiques que l'on souhaite voir apparaître.  
Dans
l'exemple suivant :

  myMusic = { do-\tag #'partie \p }

myMusic est composé d'une séquence contenant une note avec une nuance,
laquelle est taggée `partie', le but pouvant être de ne faire apparaître
cette nuance que dans la partie séparée et non dans le conducteur où  
elle
pourrait être redondante avec une autre voix. Donc ensuite, dans le
conducteur il faudra inclure cette musique avec \removeWithTag  
#'partie et
dans la partie séparée \keepWithTag #'partie par exemple.

On peut faire autrement : avoir des fonctions qui, en fonction de la  
valeur
d'une propriété, va inclure au non la musique là où elle est saisie.
Par exemple :

  myMusic = { do-\whenPart \p }

où whenPart testerait la valeur d'une option `part' par exemple. Alors,
\myMusic contiendrait la nuance seulement si on compile la partition
avec l'option -dpart, et dans tous les cas on utilise \myMusic dans
la structure de la partition sans avoir à s'embêter avec des  
\keepWithTag.

Les deux approches ont leurs avantages et inconvénients : \tag et
\keepWithTag existent de base, tandis que quelque chose comme \whenPart,
\whenLeadSheet, \whenReduction, etc, serait à écrire ; d'un autre côté
l'utilisation des seconds peut rendre les parties structure plus  
claires.
A essayer éventuellement pour se faire une idée.

Nicolas