Changer de format de fichiers de chansons

[Luthaf]

L'utilisation de LaTeX pour les fichiers .sg induit plusieurs difficultés :

Pour l'utilisateur final

• la syntaxe, bien que simple à apprendre est relativement lourde
• les fichiers peuvent contenir des directives de formatage, alors que ce sont des fichiers de données, conduisant ainsi à la création de carnets à la mise en page inconsistante.

Pour le fonctionnement interne de patacrep

• Le parsing de LaTeX est une immense difficulté, et nous empêche de passer à Python 3, tout en étant très long à effectuer (c'était la motivation de mise en place d'un cache).

Proposition

Utiliser un autre langage de description des fichiers de données. Mais plutôt que de réinventer le notre juste pour le plaisir, utiliser le format chordpro, qui existe déjà, comprend donc de grandes bibliothèques de chansons, et est utilisé par plusieurs logiciels. J'avais déjà avancé l'idée dans le forum.

Le format est décrit ici. La plupart des directives se traduisent directement en LaTeX, et l'on peut en ajouter pour les directives du paquet Songs qui n'existent pas encore dans ce format, ainsi que pour les métadonnées exploitées par patacrep (auteurs, albums, etc.).

Inconvénients

• Pas forcément plus rapide : il faut générer des fichiers LaTeX à partir des fichiers chordpro. Le parsing devrait quand même être bien plus rapide, on a une grammaire plus simple.
• Légère perte en flexibilité sur le formatage des chansons par les transcripteurs

Avantages

• Passage à Python 3
• Extraction facilitée des métadonnées des chansons
• Fichiers ne contenant que des données, et pas de mise en forme

Implémentation

Il faut ajouter un module d'analyse des fichiers chordpro à patacrep, ou vérifier s'il en existe un en Python. Il faut ensuite utiliser ce module pour mettre en cache des versions LaTeX des fichiers chordpro afin de pouvoir inclure ces fichiers lors des passes pdflatex.

Ce module doit pouvoir être écrit à base de regex, les expressions à matcher étant relativement simples : {<key>:<value>}, {<directive>} et [<chord>]. Les commentaires peuvent être supprimés par une première passe.

Enfin, il faudra un script de transformation .sg -> chordpro pour mettre à jour patadata et les fichiers utilisateurs.

Dans un premier temps, le format chordpro peut être introduit sous la forme d'un plugin, puis devenir s'il en vaut le coup le format par défaut en conservant les fichiers LaTeX sous forme de plugin.

Quel est votre avis sur la question ?

[paternal]

L'utilisation de LaTeX pour les fichiers .sg induit plusieurs difficultés :
[...]

Je suis partage cette analyse.

Proposition

[Utiliser Chordpro]

Intéressant, en effet, et facilement convertible en LaTeX. De plus, il a l'air aisément extensible.

Inconvénients

• Pas forcément plus rapide : il faut générer des fichiers LaTeX à partir des fichiers chordpro. Le parsing devrait quand même être bien plus rapide, on a une grammaire plus simple.

Effectivement : ça sera toujours plus rapide qu'avec PlasTeX.

• Légère perte en flexibilité sur le formatage des chansons par les transcripteurs

Pas très grave pour les cas de base.

Avantages

• Passage à Python 3

Pas forcément (voir plus bas)

• Extraction facilitée des métadonnées des chansons
• Fichiers ne contenant que des données, et pas de mise en forme

Implémentation

Il faut ajouter un module d'analyse des fichiers chordpro à patacrep, ou vérifier s'il en existe un en Python. Il faut ensuite utiliser ce module pour mettre en cache des versions LaTeX des fichiers chordpro afin de pouvoir inclure ces fichiers lors des passes pdflatex.

Pour l'intégration de l'analyse à patacrep, ça peut se faire facilement avec les plugins. Pas besoin de mettre en cache un fichier : le plugin pourrait générer le code latex \input{chanson.chordpro}, où chanson.chordpro a été créé quelque part, mais on peut aussi générer plus simplement le code LaTeX directement.

Ce module doit pouvoir être écrit à base de regex, les expressions à matcher étant relativement simples : {<key>:<value>}, {<directive>} et [<chord>]. Les commentaires peuvent être supprimés par une première passe.

Je pense qu'il vaut mieux éviter les regex, mais utiliser un vrai analyseur syntaxique (pyparsing ou PLY par exemple, que je n'ai jamais utilisé, mais j'ai déjà fait de l'analyse syntaxique) : ça sera plus propre, et moins sujet à des bugs.

Dans un premier temps, le format chordpro peut être introduit sous la forme d'un plugin, puis devenir s'il en vaut le coup le format par défaut en conservant les fichiers LaTeX sous forme de plugin.

Le rendre « format par défaut » n'est même pas nécessaire : si on garde l'extension .sg pour les fichiers LaTeX, et le .chordpro (ou une extension plus simple) pour le chordpro, on peut simplement dire au plugin songs d'analyser les fichiers selon l'extension.

---

Tout ça est intéressant. Aucune contre-indication pour créer un nouveau plugin qui utilise ce format là (il semble déjà exister des bibliothèques analysant le chordpro : exemple1, exemple2, exemple3, il faut voir si c'est réutilisable).

Ensuite, pour passer à Python3, il faut abandonner plasTeX, ce qui devrait simplifier la maintenance. Deux solutions :

• abandonner le format LaTeX (l'actuel .sg) complètement ;
• ne supporter qu'un sous-ensemble de LaTeX, en écrivant un analyseur syntaxique rudimentaire pour n'analyser que l'en tête du fichier.

Ce que j'en pense :

• À première vue, la première solution me semble dommage, mais c'est peut-être seulement une résistance au changement ; il faut que j'y pense.
• Pour la seconde solution, ça pourrait m'amuser de me replonger dans de l'analyse syntaxique (je ne sais pas quand j'aurai le temps de faire ça, entre mon boulot et d'autres projets, mais ça devrait pouvoir se faire). C'est dommage de prendre un sous-ensemble du LaTeX, mais (1) ça n'est que pour l'en-tête (2) si c'est correctement documenté, et avec des avertissements pertinents (du genre Je ne sais pas analyser '\emph{Todo}' : je vais faire ce que je peux, mais il risque d'y avoir des erreurs de tri), ça passe. Pour Patanet, vous préciserez que les chansons écrite dans ce format ne pourront pas être éditées en ligne, mais ça n'est pas un problème.

---

À ce stade, ma préférence va à :

• créer un plugin (modifier le plugin songs, en fait) pour autoriser le format chordpro, le choix du format se faisant avec l'extension ;
• utiliser un analyseur syntaxique pour faire cette analyse ;
• abandonner PlasTeX pour le remplacer par un analyseur plus simple, pour autoriser tout de même l'utilisation du LaTeX par les vieux geeks barbus (suivant la période et le point de vue, j'entre dans une à trois de ces catégories) ;
• passer à Python3 !

Mais n'hésitez pas à me faire changer d'avis…

---

Question : Est-ce que l'on attend ces changement pour publier une version 4 ?

• Pour : C'est un gros changement.
• Contre : Ça ne devrait introduire aucune rétro-compatibilité.

[Luthaf]

Je pense qu'il vaut mieux éviter les regex, mais utiliser un vrai analyseur syntaxique (pyparsing ou PLY par exemple, que je n'ai jamais utilisé, mais j'ai déjà fait de l'analyse syntaxique)

Oui, en effet, ce sera mieux.

Ce point de vue mon convient :

• créer un plugin (modifier le plugin songs, en fait) pour autoriser le format chordpro, le choix du format se faisant avec l'extension ;
• utiliser un analyseur syntaxique pour faire cette analyse ;
• abandonner PlasTeX pour le remplacer par un analyseur plus simple, pour autoriser tout de même l'utilisation du LaTeX par les vieux geeks barbus (suivant la période et le point de vue, j'entre dans une à trois de ces catégories) ;
• passer à Python3 !

En y ajoutant l'item suivant :

• Transformer l'ensemble des chansons de patadata au format chrodpro, principalement pour en permettre l'édition via patanet.

Question : Est-ce que l'on attend ces changement pour publier une version 4 ?

On attends surtout de pouvoir mettre à jour le site patacrep.com. Mais je ne pense pas que cette évolution sera finie avant que le site ne soit mis à jour, et comme on reste rétro-compatible, on peut garder ça sous la main pour la 4.1

[paternal]

Hé bien en route !

Je vois les étapes suivantes (renommez les branches à votre guise) :

1. Créer une branche python3 pour ce travail (pour que la branche master reste fonctionnelle).

2. Désactiver plasTeX.

3. Passer à Python3

4. Peuvent se faire en parallèle :

   a. Autoriser l'intégration de fichiers chordpro (dans une branche chordpro).
   b. Autoriser (à nouveau) l'intégration de fichiers LaTeX (dans une branche LaTeX).

5. Merger chordpro et latex dans python3, puis python3 dans master.

6. Reporter ces changements dans les autres projets :

   a. Mettre à jour la documentation.
   b. Convertir les fichiers de patadata.
   c. Mettre à jour patanet.

[Luthaf]

La proposition me va. Concernant l'organisation du code, je propose un module patacrep.file qui se charge de l'analyse syntaxique des différents types de fichiers (et qui contiendra aussi le traitement des encodages). Ce module devrait pouvoir prendre un chemin de fichier et renvoyer un objet qui contienne :

• Les métadonnées de la chanson dans un dictionnaire (titre, titres alternatifs, auteur, auteurs alternatifs, albumS, ...)
• Un arbre syntaxique du contenu de la chanson, classé par types : verse, chorus, bridge (pas de verse*, il ne s'agit que d'un type d'implémentation).

Concernant les extensions, je propose d'utiliser .lsg pour LaTeX Song et .csg pour ChordPro Song. .sg deviendrai alors un alias vers .lsg. Si on modifie patadata, il faudrait un script update-to-chordpro qui se charge de mettre à jour les fichiers .sb.

[paternal]

Je pensais effectivement à un module de ce genre, mais :

• je pense qu'il a toute sa place dans patacrep/content/song.py ;
• pour la partie encodage (je pense que tu fais référence à Problème d'encodage des templates #62), puisque les fichiers de chansons ne sont pas les seuls que l'on lit, je pense que le module dont tu parles fera appel à un module d'encodage (mais ne contiendra pas la mécanique de cette histoire d'encodage) ;
• ce module ne retournera pas nécessairement un arbre syntaxique, puisque pour du LaTeX, on n'a pas cet arbre. Je pense que (1) la fonction render suffit pour patacrep, et (2) les objets de la classe ChordProSongRenderer pourront avoir un attribut ast (abstract syntax tree) ou équivalent, pouvant être utilisé par patanet.

En fait, pour patanet, en supposant qu'on ait dans patacrep une classe ChordProSongRenderer qui nous permette le rendu LaTeX des chansons chordpro, vous pourrez faire hériter une nouvelle classe de celle-ci, en lui ajoutant (ou en remplaçant) la méthode render() pour générer de l'HTML plutôt que du LaTeX.

[paternal]

J'y ai repensé, et voici mon idée.

patacrep
\_ content
  \_ __init__.py
  \_ song
    \_ __init__.py
    \_ intersong.py
    \_ latex.py
    \_ chordpro.py

song est un plugin qui gère les contenus de type chanson (il faudra modifier content/__init__.py qui n'importe pour le moment que des modules sous la forme de fichiers .py, et pas les dossiers). Il définit une classe SongRenderer qui correspond plus ou moins à la classe SongRenderer actuelle, mais qui a en plus un dictonnaire metadata qui contient auteurs, album, couverture, etc. Ensuite, chacun des sous-modules de song est un module qui associe une extension à une classe (de la même manière que les plugins de content associent un type de contenu à une fonction). Les classes suivantes sont donc définies, et héritent de la classe SongRenderer : IntersongRenderer pour les fichiers .is, LatexRenderer pour les fichiers .lsg, et ChordproRenderer pour les fichiers .csg (et .sg ?).

La signature (de base) des classes héritant de SongRenderer est : le constructeur prend en argument un nom de fichier (ou le contenu du fichier ? ou un nom de fichier et l'encodage ? Il faut voir ce qui doit être factorisé, et comment), remplit l'attribut metadata, et définit la méthode render(), qui permet de produire le code LaTeX correspondant.

Pour Patanet, il suffit de définir une classe qui hérite de ChordproRenderer, et qui définit une nouvelle méthode render_html (ou qui écrase l'ancienne méthode render).

En fait, je me dit qu'on a déjà trois types de fichiers différents, donc que ça commence à valoir de coup d'avoir un (nouveau) système de plugins… Mais si je surréagis, dites-le moi.

---

C'est un peu anecdotique, mais je me demande si on ne renommerait pas la méthode render en render_latex.

[Luthaf]

J'y ai repensé aussi, et je voyais le truc plus comme ça :

patacrep
\_ content
   \_ __init__.py
   \_ songs.py
\_ songfile
   \_ __init__.py
   \_ latex.py
   \_ chordpro.py
\_ files
   \_ __init__.py
   \_ encoding.py

À savoir on délègue à un module songfile la responsabilité de convertir un fichier en représentation interne pour patacrep, et content.songs appelle ce module pour gérer les inclusions de fichier pour pdflatex.

songfile.__init__.py se charge de définir une classe SongFile de base, qui ressemble à :

class SongFile:
    metadata = {}
    path = ''
    ...

    def include_latex(self, context):
        '''
        Renvoie la chaine \input{path} pour latex et se charge du pré/post-traitement si besoin
        '''

Ce même module se charge d'associer les types de contenus aux extensions des fichiers. C'est un système de "plugins", pour les types de fichier en entrée.

[paternal]

J'ai l'impression que la seule différence (aux noms près) est que dans ta proposition, le module songfile est un sous-module de patacrep, alors que dans le mien, c'est un sous-module de patacrep.content.

Seulement, pour la classe SongFile, je ne vois pas pourquoi on aurait une méthode include_latex plutôt qu'une méthode render.
Jusqu'à maintenant, on incluait directement les fichiers de chanson dans le carnet, car c'était du LaTeX. Donc faire un \input{path} était pratique, pour ne pas dupliquer de l'information. Avec ChordPro, on peut générer du LaTeX, l'écrire dans un fichier temporaire, renvoyer un \input{fichier_temporaire}, supprimer le fichier temporaire ; ou on peut simplement renvoyer le code LaTeX généré. Ça simplifie le traitement (notamment, pas besoin de faire gaffe à : Où j'écriis le fichier ? Est-ce que j'ai le droit ? Est-ce que le fichier va être modifié entre le moment où je l'écris et celui où je le lis ? Qu'est-ce que je fais si je ne peux pas l'écrire/le lire/le supprimer ?

Enfin, je pense que l'attribut path peut très bien aller dans le dictionnaire metadata. D'une part, je ne vois pas en quoi c'est une métadonnée différente des autres ; d'autre part si dans le futur, on n'a plus la relation un fichier = une chanson, on sera embêté avec ça.

[Luthaf]

ou on peut simplement renvoyer le code LaTeX généré.

Je n'y avais pas pensé, c'est une bonne idée ! Sinon pour la position du module songfile, je préfère quand même ma proposition, mais ce n'est pas très grave.

[paternal]

C'est par ici : #65. Comme d'habitude, ça n'est pas prêt à être mergé : c'est juste pour centraliser les discussions.

[paternal]

Sinon pour la position du module songfile, je préfère quand même ma proposition, mais ce n'est pas très grave.

Ma logique pour le placer dans patacrep.content est que ce module contiendrait principalement une classe SongRenderer (et ses sous-classes), héritant de Content, défini dans le module patacrep.content.

Quelle est ta raison pour le placer directement dans patacrep ?

PS : Je ne suis pas en train d'essayer de te forcer la main, seulement de t'aider à me convaincre.

[Luthaf]

Il faudrait définir les extensions que l'on apporte au format chordpro. Je propose d'avoir les éléments de base :

{title: title string} ({t:string})
{subtitle: subtitle string} ({su:string})

{start_of_chorus} ({soc})

{end_of_chorus} ({eoc})

{start_of_tab} ({sot})

{end_of_tab} ({eot})

{comment: string} ({c:string}) -> équivalent de \textnote
{guitar_comment: string} ({gc:string}) -> équivalent de \musicnote

{new_song} ({ns})  -> Commence une nouvelle chanson si plusieurs chansons sont dans le même fichier

{define: <chord> base-fret <base> frets <Low-E> <A> <D> <G> <B> <E>} -> Définition de diagrammes d'accord

Les accords étant définis par [Gm]texte et les couplets délimités par des passages à la ligne.

On peut alors y ajouter les éléments suivants :

{start_of_bridge} ({sob})

{end_of_bridge} ({eob})


{album: string} ({a: string}) -> peut apparaître plusieurs fois, la première apparition est prise comme album par défaut
{cover: path_to_image} 
{artist: string} -> peut apparaître plusieurs fois
{key: string}
{capo: integer}
{tags: string} -> peut apparaître plusieurs fois

[paternal]

Pour les titres, je pensais simplement à autoriser plusieurs balises {title: Titre} : la première représentant le titre principal, les autres les sous-titres.

Pour les métadonnées des chansons, on peut définir quelques balises déjà utilisées (album, cover, vcover, etc.). J'ajouterais à cela une balise générique : si l'utilisateur (avancé) a défini une nouvelle clef clef au paquet songs, il peut la définir dans ses chansons en utilisant {meta:clef:Valeur}.

C'est une bonne idée d'autoriser plusieurs balises artiste, pour autoriser plusieurs artistes. On utilise les mêmes règles pour pour les chansons LaTeX (à savoir un artiste chanté par Brassens devient Brassens) ?
Comment fait-on pour la séparation nom/prénom : comment dire que dans The Dire Straits, le « « prénom » est The, et le « nom » Dire Straits ? Avec l'espace insécable (tout le monde ne peut pas le taper facilement) ? Avec un caractère spécial (par exemple The Dire~Straits, où on peut utiliser ~~ pour représenter le caractère tilde) ?

Pour les tags (vous compter les utiliser dans patanet ?), on peut mettre le singulier, puisque chaque balise ne contient qu'un seul tag, non ?

Pour le {new_song}, pour le moment, le code est fait pour une chanson par fichier, et inversement. Donc je propose d'ignorer ce paramètre pour le moment.

Quelle est la signification du {key:string} que tu proposes ?

---

Pour la mise en œuvre, si on utilise ply (comme pour LaTeX), ça devrait être plus simple que pour LaTeX. @Luthaf : Est-ce que tu sais faire ; est-ce que tu veux t'en occuper ? Je peux le faire, et ça m'amuse plutôt. Mais (en supposant que tu ne saches pas encore faire) si tu veux apprendre, et qu'on ait deux personnes qui comprennent cette partie du code au lieu d'une seule, c'est peut-être bien que tu t'en occupes. Je peux t'expliquer si nécessaire.

[Luthaf]

Pour les titres, je pensais simplement à autoriser plusieurs balises {title: Titre} : la première représentant le titre principal, les autres les sous-titres.

La balise subtitle est présente dans le format par défaut de chordpro, c'est la raison de sa présence ici.

J'ajouterais à cela une balise générique : si l'utilisateur (avancé) a défini une nouvelle clef clef au paquet songs, il peut la définir dans ses chansons en utilisant {meta:clef:Valeur}.

Bonne idée !

à savoir un artiste chanté par Brassens devient Brassens)

J'ai pas compris ...

Comment fait-on pour la séparation nom/prénom : comment dire que dans The Dire Straits, le « « prénom » est The, et le « nom » Dire Straits ? Avec l'espace insécable (tout le monde ne peut pas le taper facilement) ? Avec un caractère spécial (par exemple The Dire~Straits, où on peut utiliser ~~ pour représenter le caractère tilde) ?

On peut trouver un caractère spécial en effet, que ce soit la tilde ou autre chose.

Pour les tags (vous compter les utiliser dans patanet ?)

Si possible oui.

on peut mettre le singulier, puisque chaque balise ne contient qu'un seul tag, non ?

Oui en effet !

Pour le {new_song}, pour le moment, le code est fait pour une chanson par fichier, et inversement. Donc je propose d'ignorer ce paramètre pour le moment.

Je crois qu'il fait aussi partie du format par défaut, à vérifier.

Quelle est la signification du {key:string} que tu proposes ?

C'est la convention pour indiquer la tonalité de la chanson utilisée par par mal d'autres logiciels chordpro.

Est-ce que tu sais faire ; est-ce que tu veux t'en occuper ?

Je ne sais pas faire, et je ne sais pas si j'aurai le temps de m'en occuper. Je vais essayer un peu, et puis j'aviserai. La doc de ply sera mon amie !

[paternal]

à savoir un artiste chanté par Brassens devient Brassens)

J'ai pas compris ...

Dans le paquet LaTeX songs (et dans patacrep) configuré correctement, si on met en option de la chanson by={Écrit par Jean Boyer, Chanté par Georges Brassens}, la chanson sera présente à deux endroits dans la table des auteurs : à Boyer (Jean) et Brassens (Georges). Je propose simplement de faire la même chose pour ChordPro.

[Luthaf]

Ok. Pour moi ce genre de cas est typiquement le cas où l'on écrit au début du fichier

{artist: Jean Boyer}
{artist: Georges Brassens}

Ainsi, on ne dépends pas d'une langue pour les chaînes "écrit par" ou "chanté par".

[paternal]

Mais avec ça, ça permet aussi, dans le rendu PDF, d'avoir les détails « Paroles de X, Musique de Y ». En utilisant seulement {artist: X} {artist: Y}, on perd cette information.

[Luthaf]

Vu qu'{artist:} est de toute manière une extension, on peut alors utiliser quelque chose comme {artist: X} {singer: Y} {lyrics: Z} {composer: H}. On garde toute l'information, et on évite de dépendre d'une langue particulière.

Du coup, il faut aussi avoir les instructions {lang: french} et {columns: 3} pour pouvoir convertir tous les fichiers de patadata.

[paternal]

En fait, on ne dépend pas d'une langue particulière, puisque l'utilisateur peut définir (dans le fichier .sg ou dans les templates) comment sont interprétées les chaînes de caractères artist (by dans songs). Du coup, si on ne propose que la balise artist, l'utilisateur peut, au choix : configurer les options pour faire une analyse de la chaîne (pour que « Paroles de X (1972), Musique de Y (d'après une mélodie traditionnelle) » devienne X et Y) ; on ne pas configurer ces options, et aucun traitement ne sera fait sur la chaîne qu'il va entrer.

[paternal]

J'ai fait une page décrivant le format utilisé : chordpro. J'ai coché les balises pour lesquelles nous sommes d'accord (n'hésite pas à décocher si j'ai mal interprété tes messages). Je te laisse accepter ou discuter mes propositions.

• Il reste la question des balises artist à clore (discussions dans le fil de ce ticket).
• Question pour la balise album : tu écris « {album: string} ({a: string}) -> peut apparaître plusieurs fois, la première apparition est prise comme album par défaut ». Je ne comprends pas ce que tu entends par « album par défaut » : le paquet songs n'accepte qu'un seul album, non ? Si on met plusieurs albums, que se passe-t-il ? Pour LaTeX, seul le premier est pris en compte ; pour patanet, vous interprétez ça correctement ? Si c'est ce que tu avais en tête, ça me va.

[Luthaf]

Bonne idée !

Si on met plusieurs albums, que se passe-t-il ? Pour LaTeX, seul le premier est pris en compte ; pour patanet, vous interprétez ça correctement ?

C'est en effet l'idée originale, afin de faciliter la recherche par albums. Il serait aussi possible de modifier Songs ou patacrep.sty pour gérer ça, mais plus tard.

Des balises spécifiques : {lyrics:Jean Boyer} {singer:Georges Brassens}.

Ma préférence reste là-dessus, parce qu'il est possible d'ajouter les clefs correspondantes à patacrep.sty. Sinon,

Une balise artiste, interprétée comme le champ by de \beginsong, et configurable dans le fichier .sb (voir la section auteur) : {artist:Paroles et musique de Jean Boyer, chantée par Brassens….

Peut aller aussi.

lilypond : Fichier .ly.

Je propose partition pour les fichiers de partition, lesquels sont ensuite compilé selon leur extension. Ça permet de mettre des fichiers .abc facilement plus tard par exemple.

Sinon, je suis d'accord avec les autres points non cochés, et j'ai rempli les TODO. À ce sujet, la "norme" chordpro pour les tablatures est d'utiliser simplement des zones de texte à chasse fixe, mais cela risque de poser problème dans notre cas (3 colonnes et une tablature prévue pour de l'A4 par exemple). Je propose donc d'ignorer ce point, sachant que les tablatures peuvent être écrites avec Lilypond. Un exemple de tablature de ce genre ici.

EDIT: J'ai ajouté {language : lang} à la liste.

HS : j'ai lu la doc de PLY, je vais tenter quelque chose ce soir.

[paternal]

HS : j'ai lu la doc de PLY, je vais tenter quelque chose ce soir.

J'ai créé le système de plugins pour les types de fichiers : fe2d2da. Tu pourras y intégrer tes modifications quand tu auras fini l'implémentation.

[paternal]

Comme proposé en #16, j'ai enlevé le tag version 4 : l'architecture est en place pour accueillir le format chordpro, mais l'ajout de chordpro sera maintenant une fonctionnalité rétro-compatible. Donc ça pourra attendre une version mineure.

@Luthaf Rajoute le tag si tu n'es pas d'accord.

[paternal]

Oups… La fermeture de ce ticket était une erreur…

[paternal]

Je suis en train de bosser là dessus, et j'ai deux questions (rappel : je ne suis pas musicien) :

• Quelle est la syntaxe des accords (les notes marquées entre crochets) ?
• À quoi sert le {define: …} (exemple) ? Il fait apparaitre l'accord à l'endroit où il est défini, où cette définition est utilisée ailleurs ?

[Luthaf]

Quelle est la syntaxe des accords (les notes marquées entre crochets) ?

La syntaxe est de la forme <note>[#b][m][sus|aug|dim][4579][/<note>[#b]] : une note de base (A B C D E F G ou La Si Do Ré Mi Fa Sol) et plein de trucs optionels : un # ou un b, un m pour mineur, sus si il manque des notes, 45679 pour ajouter des notes, ... Bref, le contenu de crochet risque d'être compliqué à parser si c'est ça que tu as en tête. On a même des accords de la forme G#m7+/F, donc bon ...

Sinon, les accords sont toujours entre crochets, et sont associés à la syllabe qui suit, ou rien si c'est un espace après.

À quoi sert le {define: …} (exemple) ? Il fait apparaitre l'accord à l'endroit où il est défini, où cette définition est utilisée ailleurs ?

Le define permet de générer les diagrammes d'accords, ils correspondent aux \gtab du paquet Song. On peut donc considérer que pour générer des carnets, il suffit de reprendre les define et de les regrouper au début de la chanson avant de les transformer en \gtab.

[paternal]

Merci. Juste une demande de précision : dans ton expression régulière pour un accord (que l'on traduit bien par chord ?), à quoi correspond le [/<note>[#b]] ? On peut avoir un dièse ou bémol à la fin de la note, ou c'est un mauvais copier-coller de la balise de départ ?

[Luthaf]

que l'on traduit bien par chord ?

Tout à fait !

à quoi correspond le [/[#b]]

On peut avoir un accord de la forme G/B, ou F/Bb ou D/F#. Mais la regex que j'ai donnée est loin d'être complète et de prendre en compte tous les cas.

[paternal]

On continue dans les questions : les tablatures, elles sont affichées au fil du texte, ou regroupées au début / à la fin ?

[Luthaf]

Le mieux est sans doutes de les afficher au fil du texte, via lilypond (pour ne pas avoir à gérer la largeur du papier). Elles peuvent être là pour noter des passages instrumentaux.

[paternal]

Bon, c'est tout (et c'est déjà trop) pour ce soir. Je bloque sur l'analyseur syntaxique. Maintenant que j'ai une vue d'ensemble, il faudra que je reprenne ça du début, à tête reposée.

[paternal]

Fait : #79