Should I Use abc Music Notation

I don't know how often I looked at the abc music notation and considered using it. I never did, and the first look was 27 years ago. Not that I did not need it, I have always been using and writing music on paper, and a computer would have offered some valuable features like transposing a score from one key to another in a second. But abc never convinced me. And with every look at it I found new disadvantages.

In 1997, the years when abc evolved, I decided to implement my own music notation language. The goal was to write notes for a single-voiced melody and output it as printable sheet music. I achieved it by using Java/AWT as graphical input user-interface, a self-designed notation language using simple text characters, and a GNU awk script that translated it into into MusixTeX, which is a very mature French TeX package for writing music scores. Together with the C-programming make utility and UNIX shell scripts I wrote and printed over 120 of my pieces on that application. This worked very well for 26 years, across several different LINUX distributions, although I had to manually configure the MusixTeX files and pathes sometimes when changing distros. I would not dare to write MusixTeX source directly, that's not readable. If you have unreadable source, it will be time-consuming and error-prone to maintain, correct and extend your pieces. My own notation language is simple, structured and readable, although more a commandline-language than a context-free grammar.

So how readable is the abc alternative?
By the way, alternative to abc is just musicXML, but this is not readable at all, too big.
The abc language is free open source, and it was well accepted by both musicians and developers. There are online-translators on the web where you can try it out. It even has a grammar definition, but not final, and version-specific. Basically it is a commandline-language, that means every line of an .abc file is interpreted in the context of the header lines read before. Thus the order of lines matters. Another thing is the readability. Not good at all. Not too big like musicXML, to small instead.

• Spaces:
  If you want "beaming" (eighth notes with a common flag-line), you must do it by leaving out spaces between the notes. The result is really hard to read. What would you expect is this:

  X:1
  L:1/8
  K:C  % end of header lines
  c2G EFG

  Look at the last line. In IPN notation, this is a "C5" quarter note, then a "G4" eighth note, then "E4", "F4" and "G4" eighth notes. The EFG will be beamed together, not the c2G, because a quarter note has no flag that can be written as beam. (Fortunately, for all cases other than beaming, spaces can be used to separate notes.)


• Newlines:
  If you want the "staff" (note line) to end, you insert a newline. If you don't, the note line will get wider and wider. In other words, you must do the layout of the score manually through newlines. There is no formatter that sizes notes and bars to some formatting parameter, like musixflx provides in MusixTeX - abc source code hard-codes layout:

  X:1
  L:1/4
  K:C
  GBd2|GBd2| 
  a/g/f/e/d2|a/g/f/e/d2|

  This will be rendered in two "staffs" (note lines), each containing two bars. Effect is that whenever you maintain your score and add some fill notes, the overall layout will be affected. The idea behind this may have been to formulate conceptual units, but in fact it was an ignored model-view separation.


• Numbers:
  There is misleading similarity between IPN notation and abc notation concerning numbers.
  The IPN "C2" means the C in 2nd octave (very low).
  The abc "C2" means an IPN "C4" that is 2 times longer than the standard-length of a note (which is given in header via e.g. "L:1/8", in that case it would be a quarter note).


• Separators:
  In abc the comma is not a separator. It lowers the octave of the note before. The expression C, (C comma) is one octave lower than C. A single quote is used to put the note one octave higher, c' is one octave higher than c (which surprisingly is one octave higher than C).

Many more cryptographies have been used that make abc scores hardly readable. Not only the author will have problems when coming back to his score years later, maybe also other people would like to be able to maintain some abc source that was written by an author (that unfortunately likes to apply every trick the language offers).

Finally the recommended EasyABC editor - can probably be installed on LINUX, but you should take yourself a day for it. I just threw away my nerves. So much Python documentation and Blogs to read. Everything so outdated (2017), written in so tiny fonts. The editor was implemented in Python, using the wxPython UI toolkit, which is platform-dependent. (Is Python really platform-independent?) The Python package installer (pip) seems to not support LINUX when a package contains platform-dependent binaries. How elegant Java is ....

Summary:
The informatic heresy "Write Less Do More" has done lots of harm, also here in abc. I can understand that shortness was important in 1980 when machines had just 64 KB memory, but since then there is no need for shortness, just the contrary would be needed, as so much unreadable source code blocks the human side of digitalization. Simplicity and accuracy will win in the long run.
Ask yourself:
Will I still be able to understand my abc code in a year?
Will my colleague be able to maintain my abc code when I go on vacation?

Yes, it would be nice to be part of the abc community with nearly a million tunes on its web-repository, but not for the price of having to layout tons of hard-to-read code after every maintenance. So I'll stay on my home-grown solution, will improve it and add an optional "to abc" converter to it. Maybe we all should use MuseScore.

Why is there no better solution for writing music notes? Because this is so complex. It has grown over centuries. It even contains programmatic structures like loops and conditions, an look how complicated programming languages are.

In case you already fell into abc, here is an example how to not write abc code:

....
L:1/4
K:G
GBd2|GBd2| 
a/g/f/e/d2|[Aa]/g/f/e/[Dd]2| 
G,/G/zg2|D/d/z[Aa]2|
z2[Dd]B|[G,G]4|]

(Can anyone read that?) You can achieve the same through more readable code:

....
L:1/1
K:G
G/4 B/4 d/2 | G/4 B/4 d/2 | 
a/8` g/8` f/8` e/8 d/2 | [Aa]/8` g/8` f/8` e/8 [Dd]/2 | 
G,/8` G/8 z/4 g/2 | D/8` d/8 z/4 [Aa]/2 | 
z/2 [Dd]/4 B/4 | [G,G] |]

• Set the standard note length to the whole bar (1/1), and put the length of the note to every note, else you will have to always calculate their lengths while reading (Write more do more:-)
• Add spaces wherever it is possible. If impossible due to beaming, you can use back quote ` instead of space to separate the notes.

How do you make your abc code more readable? Leave a comment!

---

UPDATE 1: didn't take me long to break it, look at following triplet clamps:

X: 1
T: Triplet Clamps Too Short
N: For all of eighth / quarter / half triplets the clamp is too short
M: 4/4
L: 1/1
(3 E/8`F/16`-G/16`A/8 B/4 c/2 |\
(3 D/4 E/8`-F/8 G/4 A/2 |\
(3 C/2 D/4`-E/4 F/2 |

This is not due to the '-' character (slur), you can also leave them out. I tried this abc code on several web translators, was the same everywhere.

---

UPDATE 2: this may become a longer list of abc bugs, maybe concerning only abcjs. Try to play this tune on some online abc translator:

X: 1
T: Lengthened Notes Play Differently
M: 4/4
L: 1/1
(C | C) | F | C- | C | F |

You will notice that the "(C | C)" expression plays two tones, while the "C- | C" expression correctly just sounds once before the F. The printed notes are the same in both cases, with a slur into next bar.

---