I have used, or tried to use, many different GUI tablature programs over the years with varying degrees of success. I have come to the conclusion that not only is a GUI completely unnecessary for engraving historical tablature, but that it is often counter productive. I have also come to the conclusion that the inflexibility of these programs means that they are not useful for repositories of historical tablature. In the realm of software engineering, they constitute an Anti-Pattern.
Why do we have GUIs anyway? The only purpose of a GUI is to make a difficult task easier. Now consider tablature setting fret 5, course 1 of duration crotchet in a typical GUI tablature editor:
- Locate and select the duration from a menu/toolbar that may have many possible entries (good eyesight required!)
- Drag the selected duration to the stave
- Select the course (steady hand required!)
- Type the fret number/symbol on to the course (optional – it’s not accepting my text entry – why? – read the manual)
- (Optional) go back to 1, because the tablature I am engraving is in Italian format and the tablature program is working in French format and I have got myself confused.
OK – I exaggerate a bit for comedic purposes, but we have all been at 4. and 5. at some point…
Now consider the same action in STL:
- Type C 1-5
Actually, that’s quicker than saying, “fret 5, course 1 of duration crotchet”.
You wouldn’t dream of writing text using an editor where you had to select a character from a palette and then drag it on to the page, so why would you choose to do this for historic tablature? A GUI is great for a drawing program, but historical tablature, although it looks like a drawing, logically has more in common with text.
So I would argue that GUI based tablature engraving programs don’t really make things easier at all. In fact, they can be an infuriating waste of time. OK – with text based engravers you need to learn a language to use them, but I can assure you that it takes much less time to learn the few keywords in STL than it does to lean to use the leading historical tablature program.
Another big problem I have with GUI tablature programs is that they invariably use a proprietary (usually binary) file format. This means that once you have spent however many hours painstakingly entering your tablature into one of these programs, you are completely locked in. There may be some sort of “Export to format X” facility, but this is generally limited and unsatisfactory. So you can’t repurpose your work outside of the program that created it. Worse, if the file format of the tablature program is not open source, then you also face the risk that the developer will no longer actively develop the program and that, like so many other binary files, your tablature will no longer be accessible. This is why these program should not be used for repositories of tablature.
There is also a question of workflow to be considered. If you are engraving a lot of historical tablature, WYSIWYG GUIs are not necessarily your friend. A better workflow is to first capture the music (the logical domain – see below) and only then work out the details of its presentation (the visual domain). This separates the two concerns of capturing the music and engraving it. The logical music can be engraved in different forms without changing it. This is exactly how STL works.
However, the real crux of my objection is really the conflation of logical vs. visual musical domains. According to the MEI website:
Maxwell (1981) outlined three separate domains for encoding music notation in a computer: physical, logical, and graphical.
In this model, the logical domain includes the musical content or structure including pitches, time values, articulations, dynamics, and all other elements—defined as the symbols that communicate the composer’s intentions.
The visual domain describes the contributions of an editor, engraver, or typesetter, and encodes information about the physical appearance of the score, such as symbol locations, page layout, or font. Finally, the analytical domain covers commentary and analysis of the music document in any of the three previous domains.
Now this is actually a very, very important issue. GUI tablature editors conflate the logical and visual domains in such a way that the logical structure of the music is completely lost in its visual syntax and is buried in a proprietary (often binary) file format. The advantage of STL is that it is a literal implementation of the logical domain in text. The visual domain is generated from this by the action of the various STL compilers.