The definitive abc standard

[cwalshaw]

For (far too) many years, there has been no definitive abc standard. (Apologies!)

Software developers are unsure which features to implement and users are unsure which are supported by a given package.

Accordingly, I would like the abc user community as a whole to vote on which standard they would like adopted so that we can resolve the situation once and for all. When enough votes have been cast, I will publish the selected version as the definitive standard and update the website to reflect the popular choice.

Of course, (as now) there will be no absolute requirement for software developers to stick to the standard. However, with a definitive published standard, developers can state which features they support and if they provide any extensions. Meanwhile, users should find it easier to create and modify abc files that can be used portably by a range of software packages.

Please take a moment to vote on your choice. You can vote here or on the "learn abc" page or both (in the event of a split decision, votes in the forums, coming from registered users, may carry slightly more weight).

Thank you.

Chris

[Lewis Jones]

My vote goes to abcPlus.

Lewis.

[Chris P]

I would like to hear the case made for each of the standards before I make my vote. I have opinions but am not sure how much they are based on facts, and I presume that others are in a similar case. Without some discussion any decision must be capricious.

[flipe]

the standard need to be updated?

2.1 or .2, .3, .4...? 3.0?

I really want to see abc with new features, like a repeat bar with the option to numered how much times that compass will be played.

:D

[hudsonlacerda]

Draft Standard 2.0 incorpored many features of abcm2ps and abcMIDI as well as BarFly macros.
I think it should become the standard, with a few changes.

ABC Plus is not a draft standard, but a description of abcm2ps/abcMIDI/abcpp features. Not all software features need to be included in a (not-just-de-facto) standard.

[henry]

Chris, I'm not sure what it would mean to support only one of abc v2 and ABC Plus — seems that a big part of the change in abc v2 is the incorporation of Guido's extensions, while the bulk of ABC Plus is abc.

Those of you who voted on one or the other of those: what drove your decision?

Hudson's interpretation of the situation makes sense to me, and puts me in the abc v2 camp. But then I haven't actually sat down to read abc v2 draft, and I've found enough undocumented things in ABC Plus and abcm2ps that I wouldn't want to immediately say "incorporate the whole thing" (I haven't found anything that's harmful in any way — fonts stuff, undocumented functions; I'd just like to see a full specification first). And as BarFly user, I certainly support building in Phil's extensions.

[farvardin]

I'm using both abcm2ps and abcmidi which are fantastic tools, so I vote for abc plus, if it's possible to get a standard from those definitions.

[tnovelli]

What a blast from the past! I just stumbled upon an ABC standards debate from 2003 and wondered what happened. Predictably, not much. I haven't done much with ABC, although I have learned a lot about parsing techniques...

I voted for AbcPlus because it came in handy for some keyboard and orchestral pieces, and I remember it being more extensible than vanilla ABC 1.x or 2.0. I think 2.0 is overkill. According to my notes from 2004, I liked the "non-abused" subset of 1.6. I haven't given this much thought lately, but a few things come to mind...
(1) ABC is great for melodies but for big pieces I'd rather use a GUI composition program.
(2) "Human-readable/writable" is ABC's key feature. Extensions detract from this.
(3) The definitive standard should be written in BNF (or similar unambiguous notation) -- not English!
(4) Standardization is tough, almost futile.
(5) AbcPlus can be extended with Postscript, and assumes a Postscript back-end. Should that dependency be part of the standard?

"Informational" headers were a sticking point in 2003... I wouldn't even try to "get it right" now. I can imagine a big website with a database-driven tune collection, HTML5+Javascript ABC rendering, BarFly-style editing in your browser, version control, etc. (Does this already exist?) You might enter the headers and body into database-backed form fields rather than a text file. Relational database modeling would add some rigor to all this metadata, which might eventually influence the standard. On the other hand, databases tend to be rigid and frustrating when you're dealing with "human" data. I'll probably maintain my ABC collection as plain old text files under GIT version control for the foreseeable future. Neither approach is ideal, but coming up with a happy medium between databases and files is way beyond the scope of ABC. Just some food for thought.

[tpaysen]

I haven't voted--because I assumed that abc would just evolve as it could--to incorporate more and more features. As for not using it for large scores (the above post), I have found that, because I can control things (such as # measures per line) I can make a much more satisfactory choral-with-accompaniment arrangement for my choir than I can on my GUI-based notation program (not mentioning brand-names--and it is really powerful!). So--with patience, I think that abc is really the way to go on just about any kind of score production. It can be psychologically tedious, but is not really all that time-consuming.

TP

(for some reason, I don't know what computer language the abc stuff is written in--in case I ever wanted to contribute. Can anyone tell me?)

[cboody]

Nice to be a tie-breaker. I voted for V2. But I must say I'm not sure that is the solution because I'm not sure I've really thought carefully about it. What I actually use is the things that abcm2ps can handle along with (sometimes) some of the tab and special chord diagrams hudson has provided.