From lutetab to frettab

One of the data sources we're working with on Transforming Musicology is Tim's corpus of encoded lute music sources. In order to prepare this for use with some more contemporary toolchains for dealing with digitised music notation, we've previously worked on extended the Music Encoding Initiative (MEI) schema to allow for lute tablature. We wrote about this is a previous post and also presented our work at the Music Encoding Conference (MEC) last year.

Following this, another strand of our work on the project unexpectedly motivated extension of this work. At the Digital Humanities @ Oxford Summer School in 2015 we ran a workshop on Digital Musicology. One of the participants at this workshop was Jessica Schwartz (UCLA) who talked to us about the possibility of encoding guitar tablatures as found on the Web, the so-called ASCII tabs.

So over the last couple of months we've been working on extending our original work on MEI for lute tablatures to work with guitar tablatures. This has also been an opportunity for us to incorporate some of the suggestions we received from our presentation at MEC last year.

First off, we have replaced our original specialist <tabChord> and <tabNote> elements with the standard <chord> and <note> elements. Then to make these work for tablatures, we allow <chord> to have a child <rhythmGlyph> element which encodes the stem and flags used to depict the rhythm of a tablature chord. This is the visual domain equivalent of the standard logical domain @dur (duration) attribute that a <chord> element may bear.

In order to get the <rhythmGlyph> element into the <chord> content model in the ODD schema we proposed a small extension to the core schema which added a model.chordPart class to group together all the things can be inside chords. Previously, the allowed children of <chord>s were just listed explicitly. This modification was then accepted.

Next, we added a new attribute to the att.note.ges.tablature class, @tab.course which encodes which course of the instrument a <note> is on. This replaces the @course attribute on our original <tabNote> element. Relatedly, we also altered the @tab.fret datatype (data.FRETNUMBER) to allow the value x, meaning a dampened string, in addition to numerical values for frets (and o for open string). We found x used in the ASCII tab sources we are aiming to encode.

Next, we altered our related instruments module to make use of the new <perfRes> element which effectively replaces the current <instrVoice> element. We altered our model.instrvoicePart to be model.perfResPart. So now <instrName>, <instrDesc>, and <instrConfig> are all in model.perfResPart and can therefore be children of a <perfRes>.

Next, we added some more fretted string instrument articulation markings as we found them in ASCII tab sources. For example, we have the <slide> element which indicates a slide up or down the fret board from one numbered fret to another.

Finally, we renamed our module. Now instead of being the lutetab module it's the frettab module: an extension of MEI for encoding tablatures for fretted string instruments.

In our repository you will find our schema files (see especially frettab.odd) along with our example encodings. One ASCII tab we've worked on is a transcription of Cannonball by The Breeders. Our encoding of this transcription is here. And you can find the original ASCII tab (by Adam Carrel, 2002) here.

To pick out a few demonstrations of our changes:

<staff n="1">
  <staffDef lines="6" />
  <layer n="1">
    <chord>
      <note tab.course="6" tab.fret="6">
        <slide tab.course="6" tab.fromFret="1" tab.toFret="6" />
        <fretGlyph>1/6</fretGlyph>
      </note>
    </chord>
    <chord>
      <note tab.course="6" tab.fret="6">
        <fretGlyph>6</fretGlyph>
      </note>
    </chord>

Here you can see an example of a <slide>. Notice that the <fretGlyph> encodes the symbol that we see in the source for this (1/6). Also notice that the source does not give any rhythm information for the chords. The only way a player can find out what the rhythm is supposed to be is by listening to the recording. This is a very characteristic feature of such informal notations as guitar tablatures; they're really intended as prompts for players who already know the music and plan to learn to play it without following the notation.

<staff n="2">
  <staffDef lines="6" />
  <layer n="1">
    <dir startid="tc-100" endid="...">
      they change this riff during the song sometimes, with
      hammer ons and pull offs instead of slides
    </dir>
    <chord xml:id="tc-100">
      <note tab.course="3" tab.fret="7">
        <slide tab.course="3" tab.fromFret="7" tab.toFret="9" />
        <slide tab.course="3" tab.fromFret="9" tab.toFret="7" />
        <fretGlyph>7/9/7</fretGlyph>
      </note>
    </chord>

Again, as informal notations, it's quite common for these sources to include explicit textual instructions (rather than, as in common practice notation, relying on well-established symbolic language). Here the transcriber is describing how the articulation of a passage changes during the song, but there's no attempt made a full transcription of the recording.

Tim and Jessica will be presenting at MEC this week, giving some of the context and motivation around our encoding decisions for these sources. But I'd welcome any comments on the details!