Musings about ChordPro6
This is just my braindump about ChordPro 6. Also, badly formated for now…
ChordPro format is great: it is extensible, a bit known and somwehat documented, which is like a lot better than almost all other formats for songbooks I know. (Lilypond and maybe ABC may be exceptions, but those are way too complex for songbook creation.)
However, the format has several disadvantages: It is not possible to parse its syntax without knowing the behaviour of all possible directives (because of aliases), the directives are difficult to formalise (some have canonical names for attributes, some don't, some contain arbitrary strings, some are integer or other structured data (key)), the markup for chords and annotations is completely different (also: Pango? srsly?) and as far as I know, there is no way for adding custom annotations (which is especially silly given that the format does not support repeats, and using directives would be weird because they need to start at column 1).
Also, there are a lot of directives that deal with formatting, which make sense for printing[^fn: official term :-D] a single song, but otherwise mix layers of abstraction. And I cannot skip them during parsing, because I cannot recognise them in advance.
This means that while the format is a great idea (and again, probably the best I have seen so far), it feels quite hard to create an independent implementation[^fn: as I am doing with GmPro] in a way that would be easy to reason about. [^fn: Note that some other formats pretty much do not allow independent implementation, e.g. Lilypond requires a fully featured Scheme interpreter and has a lot of interfaces, which ties it to its own implementation quite tightly.]
Is there a way from this state?
I don't know. Naturally, I could make my own format and be incompatible with everyone (this is a way too common approach, since creating songbooks is so simple task I could do that in one evening [^fn: Especially if you only need to put a few chords above text]). However, my vision is merging songbooks and creating large collections, which is quite opposite of this approach. (I could create my own format and converters, but (1) insert xkcd about standards here, and (2) for the converters I still would need to be able to parse ChordPro and all the other formats, at which point I can just use ChordPro anyway.)
Tweaking ChordPro would be great, but either the changes would break compatibility with older songs, or I would need to support the current mess anyway. And ChordPro seems to care about backwards compatibility. On top of that, the reference implementation (whose source code I have not read yet) would need to support that too, so I would either need to convince its maintainers to do the changes, or write two implementations of the new thing.
There is a third option: supporting only a subset of ChordPro. However, it is hard to pick a subset that would be both strong enough to fit my needs (I need some metadata, delegated directives for typesetting melodies, chord parsing for transpositions, chorus marking, …), still have easy syntax and the fallback from “full” ChordPro file would be sensible (hello, conditional environments!). Never the less, I am probably going this way, with some hacky workarounds for putting repeats in annotations in a way that, conversely, they would be rendered somewhat sensibly by the reference implementation.
Using a more powerful format would be great, however, one should not be a programmer or have a specific supported platform to be able to typeset songs imho. ChordPro is a good middle ground in this regard: simple things are easy (text editor is sufficient and it is intuitive), difficult things are possible (abc notation). I am not sure whether a standard-ish format that would keep this property exists. (Specifically, I am not interested in anything XML based, because that means that creating the files is a chore for every song. Implementing a ChordPro parser is a voluntary chore done once [^fn: or like three times, given how many times I have redone my implementation :-)].)