P'tit nouveau pour grande structure

Bonjour à toutes les grenouilles (si je puis me permettre) !

Alors, euh... Ah oui, se présenter (version courte) :
Bertrand, 21 ans, chanteur, organiste, claveciniste, continuiste et utilisateur intense de Lilypond depuis 4 ans.
Également un petit passé d'ASM, C++, LaTeX, python etc. Utile pour rajouter à Lilypond des petites fonctions dès que j'en ai besoin :slight_smile:

J'aurais une question pour un "problème" récurent :
Comment faites-vous pour créer l'arborescence de fichiers d'un long ensemble de partitions?
Existe-t-il un script pour automatiser la création de fichiers suivant des modèles?

Je m'explique :
Par exemple, voilà comment je procède pour un livre de cantates :
Le fichier principal contient certains paramètres globaux comme les définitions du \paper suivi d'un \book contenant des \include "bookpart_[nom_d'une_cantate].ly".
Chaque bookpart contient donc la succession de scores qui constitue une seule cantate.
Chaque score fait appel aux parties séparées par des \include.
Et j'ai toujours plus ou moins cette structure pour mes recueils.

Cependant il est très lourd, pour chaque nouveau livre, de recréer tout ce pseudo-bazar !
Surtout quand on ne sait pas trop quelle taille il va faire et qu'on ajoute au fur et à mesure des copies de la structure préexistante.
J'utilise Frescobaldi et LilypondTool. Sans m'être lancé dans leurs sources, j'imagine que ça doit être très faisable. D'autant que jEdit semble gérer les projets, avec les plugins adéquats.
Ou alors pire, en bash ! ...Bon, je m'égare un peu...

En espérant avoir été clair,
Merci,
Bertrand.

Réponse courte : non.

Réponse un peu plus longue : non, mais chacun finit par faire sa sauce
à sa façon :slight_smile:

Réponse plus technique :
Il existe quelques "frameworks" développés sur mesure par quelques
LilyPondeurs émérites : Nicolas Sceaux (
Public Git Hosting - nenuvar.git/summary ) ou Reinhold Kainhofer (
lilypond:orchestrallily [Reinhold's Wiki] ).
J'ai moi-même développé un framework assez avancé, mais je ne l'ai pas
encore rendu public ; personnellement je stocke tout mon code sur un
dépôt git : la branche "master" me sert à développer le noyau, et les
autres branches, forkées de master, servent chacune à une partition
différente (lorsque j'implémente de nouvelles fonctions dans le noyau,
je n'ai plus qu'à faire "git merge master" pour que toutes mes
branches soient synchronisées).

Bref, où en étais-je ? Ah oui : chacun fait sa sauce :slight_smile:

Bienvenue sur la liste, et bon courage !

Cordialement,
V. Villenave.

···

2010/11/17 Bertrand Bordage <****@****>:

Comment faites-vous pour créer l'arborescence de fichiers d'un long ensemble
de partitions?
Existe-t-il un script pour automatiser la création de fichiers suivant des
modèles?

Merci pour cette si rapide réponse :o)
Pas bête le coup du dépôt ! Intéressant aussi ce OrchestralLily.

Mais, presque "évidemment", ça ne convient pas tout à fait à ce que je veux faire :smiley:
Il ne me reste plus qu'à mettre les mains dans le cambouis et m'attaquer à Frescobaldi ou jEdit pour ajouter ce qui me convient.
Et me mettre à git :wink:

Merci de m'avoir éclairé, Ô Maître, (hum... si, ça convient)
Bertrand.

== En réponse au message du 17-11-2010, 23:53:50 ==

Bonjour à toutes les grenouilles (si je puis me permettre) !

Alors, euh... Ah oui, se présenter (version courte) :
Bertrand, 21 ans, chanteur, organiste, claveciniste, continuiste et
utilisateur intense de Lilypond depuis 4 ans.
Également un petit passé d'ASM, C++, LaTeX, python etc. Utile pour rajouter
à Lilypond des petites fonctions dès que j'en ai besoin :slight_smile:

J'aurais une question pour un "problème" récurent :
Comment faites-vous pour créer l'arborescence de fichiers d'un long ensemble
de partitions?
Existe-t-il un script pour automatiser la création de fichiers suivant des
modèles?

Je m'explique :
Par exemple, voilà comment je procède pour un livre de cantates :
Le fichier principal contient certains paramètres globaux comme les
définitions du \paper suivi d'un \book contenant des \include
"bookpart_[nom_d'une_cantate].ly".
Chaque bookpart contient donc la succession de scores qui constitue une
seule cantate.
Chaque score fait appel aux parties séparées par des \include.
Et j'ai toujours plus ou moins cette structure pour mes recueils.

Cependant il est très lourd, pour chaque nouveau livre, de recréer tout ce
pseudo-bazar !
Surtout quand on ne sait pas trop quelle taille il va faire et qu'on ajoute
au fur et à mesure des copies de la structure préexistante.
J'utilise Frescobaldi et LilypondTool. Sans m'être lancé dans leurs sources,
j'imagine que ça doit être très faisable. D'autant que jEdit semble gérer
les projets, avec les plugins adéquats.
Ou alors pire, en bash ! ...Bon, je m'égare un peu...

En espérant avoir été clair,
Merci,
Bertrand.

Comme disait Valentin, chacun sa sauce.

Personnellement, pour chaque oeuvre, un répertoire principal qui contient les seuls fichiers "compilables" : partition d'orchestre, parties séparées, et éventuellement, partition d'étude ou encore mouvements séparés.

Puis un répertoire "common" qui contient les fichiers de définitions générales :
- variables globales : compositeur, titres, références, opus, année, ...
- N° de version (à inclure uniquement dans les fichiers compilables, ainsi la 'compilation' d'un fichier impropre génère un avertissement de n° de version absente)
- set-global-staff-size, différent selon le type de partition
- variables papier, différentes également selon le type de partition

Puis, pour chaque mouvement (s'il y en a), un répertoire différent avec
- les fichiers de notes pour chaque partie, commençant par une instruction de type
  voiceM1Flote = \new Voice { ...
- un fichier de variables reprenant les tempi, marques de reprises, et tout ce qui est commun à toutes les parties
- un fichier d'agencement des parties pour réaliser la 'directrice', du genre :
  staffM1Flote = \new Staff \with {
    \override VerticalAxisGroup #'next-staff-spacing =
    #'((space . 0.0) (padding . 0.0) (minimum-distance . 2.8) ( stretchability . 5.0))}
    {\voiceM1Flote}
  staffM1Oboe = \new Staff \with {
    ...
                                     
Et accessoirement (personnellement je trouve ce point très important), chaque mouvement contient un sous-répertoire "quotation" qui reprend une copie des parties séparées. Ces fichiers sont ensuite modifiés pour servir aux citations (suppression des << \\ >>, utilisation de nombreux \tag, occasionnellement correction des enharmonies pour les instruments transpositeurs ...)

Lors de la conception d'une nouvelle pièce, on réalise un copy *.*, puis grâce aux puissantes fonctions de remplacement de jEdit, on crée en moins d'une heure le squelette de la nouvelle pièce.

Et ... à chaque fois, on améliore cette structure pour éviter les doublons, de sorte qu'une modification importante se traduise par un changement mineur dans un seul fichier.

Voilà, ce sont des pistes, un gros travail à réaliser une fois pour toutes, mais que de temps gagné pour la suite.

···

_______________________________________________
liste de diffusion lilypond-user-fr
lilypond-user-fr@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user-fr

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

Personnellement, pour chaque oeuvre, un répertoire principal qui contient les seuls fichiers "compilables" : partition d'orchestre, parties séparées, et éventuellement, partition d'étude ou encore mouvements séparés.

Lors de la conception d'une nouvelle pièce, on réalise un copy ., puis grâce aux puissantes fonctions de remplacement de jEdit, on crée en moins d'une heure le squelette de la nouvelle pièce.

Oui, je fais à peu près tout de la même façon, à quelques détails négligeables près.
Mais je trouve tout de même cela trop fastidieux et long pour une utilisation quotidienne de Lilypond sur des projets professionnels.

Et si on souhaite se servir d'OrchestralLily ou des travaux de Nicolas Sceaux (si c'est autorisé), on est nécessairement contraint à au moins deux choses :
*Apprendre toutes les nouvelles commandes à disposition (plutôt facile)
et soit :
*Être contraint dans une structure qui ne convient pas forcément à ce qu'on souhaite réaliser (surtout quand on a la fâcheuse manie d'utiliser toutes les bidouilles possibles de Lilypond)
ou
*Devenir un maître en Scheme (pour faire des fonctions ou des tweaks simples, ok, mais de là à comprendre et personnaliser les travaux cités plus haut...)

C'est pourquoi il me paraît plus accessible et plus maléable pour "le commun des grenouilles" de faire un script ne générant que du Lilypond dans une hiérarchie de fichiers s'accroissant automatiquement au fur et à mesure que progresse un projet.

Et oui, je sais, c'est facile de balancer une idée comme ça :smiley:
Plus qu'à se mettre au boulot... C'est parti...

======== le 19-11-2010, 00:00:28 vous m'écriviez: ========



> > Personnellement, pour chaque oeuvre, un répertoire principal qui contient les seuls fichiers "compilables" : partition d'orchestre, parties séparées, et éventuellement, partition d'étude ou encore mouvements séparés.
>
> > Lors de la conception d'une nouvelle pièce, on réalise un copy ., puis grâce aux puissantes fonctions de remplacement de jEdit, on crée en moins d'une heure le squelette de la nouvelle pièce.
>
> Oui, je fais à peu près tout de la même façon, à quelques détails négligeables près.
> Mais je trouve tout de même cela trop fastidieux et long pour une utilisation quotidienne de Lilypond sur des projets professionnels.
>
> Et si on souhaite se servir d'OrchestralLily ou des travaux de Nicolas Sceaux (si c'est autorisé), on est nécessairement contraint à au moins deux choses :
> *Apprendre toutes les nouvelles commandes à disposition (plutôt facile)
> et soit :
> *Être contraint dans une structure qui ne convient pas forcément à ce qu'on souhaite réaliser (surtout quand on a la fâcheuse manie d'utiliser toutes les bidouilles possibles de Lilypond)
> ou
> *Devenir un maître en Scheme (pour faire des fonctions ou des tweaks simples, ok, mais de là à comprendre et personnaliser les travaux cités plus haut...)
>
> C'est pourquoi il me paraît plus accessible et plus maléable pour "le commun des grenouilles" de faire un script ne générant que du Lilypond dans une hiérarchie de fichiers s'accroissant automatiquement au fur et à mesure que progresse un projet.
>
> Et oui, je sais, c'est facile de balancer une idée comme ça :smiley:
> Plus qu'à se mettre au boulot... C'est parti...

|

  • |

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

jEdit possède une macro qui permet de générer un canevas de départ. Je l'ai déjà utilisé pour des exercices simples, jamais pour un gros machin (si j'ose dire).

Peut-être vaudrait-elle la peine d'être regardée de plus près, ou adaptée à des projets complexes.

À nouveau, c'est une idée balancée comme ça, je suis totalement largué au niveau de la programmation (c'est l'âge, paraît-il), ne serait-ce que pour des macros dans jEdit.

Mais on n'arrivera jamais à réaliser un canevas général. Il y a toujours un petit détail qui fait qu'une oeuvre diffère de la "normalité" : un mouvement divisé en plusieurs parties, un violon solo qui entre au milieu du mouvement, les premiers violons qui se subdivisent soudain en 4 parties ...

Jean-François

****@****
19-11-2010

C'est un des buts de mon framework "intelligent" : deviner (autant que
possible) comment organiser les parties entre elles, deviner la langue
utilisée par l'utilisateur (et adapter automatiquement le nom des
macros et variables utilisées), la partition qu'il est en train
d'essayer de compiler, parcourir l'arborescence de fichiers et inclure
automatiquement toute la musique trouvée (si possible dans le bon
ordre), deviner si l'utilisateur veut sortir une partie instrumentale
séparée ou un fragment, etc. Plus un système de surcharges, de
squelettes et de thèmes graphiques inspiré de SPIP.

Au demeurant, et pour répondre à Bertrand : d'expérience, j'ai
parcouru un peu le même cheminement avec la partition de mon opéra (ma
première rencontre avec LilyPond) : j'ai commencé simplement, avec des
bêtes fichiers pour chaque instrument, et sans avoir la moindre notion
de style de code. Puis j'ai vaguement commencé à rajouter des macros,
toujours d'instinct. Puis je suis tombé sur le framework de Nicolas,
j'ai été très impressionné et j'ai été tenté de l'adopter... mais il
n'était pas adapté à ce que je voulais faire. J'ai commencé à lui
pomper quelques idées, puis peu à peu j'ai réorganisé mon code de fond
en comble trois ou quatre fois (mon dépôt git en garde les traces).

Au bout du compte j'ai eu un truc qui me plaisait pas mal mais qui
n'était pas vraiment portable, donc je suis reparti de zéro avec un
projet mégalo de framework-à-tout-faire que je serai probablement seul
à utiliser, pour deux raisons : d'abord parce que, même si je l'ai
voulu "universel", j'y ai nécessairement étalé mes propres
présupposés, tics d'écriture etc.; ensuite parce que comme je le
disais tantôt (et jF l'a redit d'une autre façon), tous les
LilyPondeurs qui sont suffisamment avancés pour pouvoir avoir
l'utilité d'un tel bouzin... sont également ceux qui en ont le moins
besoin, et préfèrent très probablement organiser le code à leur façon.
Mais peut-être, tout au plus, s'inspireront-ils de quelques-unes de
mes idées à leur tour. Bref, le cycle de la vie :slight_smile:

Bon, décidément je suis de plus en plus bavard sur cette liste. Je
retourne illico à mon vaporware !

Cordialement,
Valentin.

···

2010/11/19 j-f.lucarelli <****@****>

Mais on n'arrivera jamais à réaliser un canevas général. Il y a toujours un petit détail qui fait qu'une oeuvre diffère de la "normalité" : un mouvement divisé en plusieurs parties, un violon solo qui entre au milieu du mouvement, les premiers violons qui se subdivisent soudain en 4 parties ...