ECOLM - An Electronic Corpus of Lute Music

Lute tablature is a specialised system of musical notation based on the notion of telling the performer which string to play at which fret. There were various ways of doing this, but they all use ciphers: letters in ‘French’ tablature; numbers in ‘Italian’ tablature - to specify these string/fret ‘coordinates’; and, in German tablature, unique typographical symbols or ‘glyphs’, based on letters, for entire coordinates.

Since the prescriptive nature of lute tablature gives it a close resemblance to a computer program listing - events follow each other in a linear fashion - it is a comparatively simple task to devise a code for the representation of tablature notation on a computer. The music data in ECOLM is encoded using Tim Crawford’s TabCode, an ASCII text format that facilitates the sharing of data across all computer platforms, whilst at the same time remaining compact, intuitive and readable enough for direct human input. It is intended to be able to represent all graphical elements of the tablature in a manner that is readable both by humans and by machines.

TabCode takes the form of a number of ‘tabwords’ separated by whitespace (usually a line-break for readability, although a space or tab does just as well).

These tabwords encode musical events (vertically stacked in the tablature): a tabword will usually take the form of a rhythm sign followed by a number of letter/number pairs standing for fret/string combinations carrying the pitch information. A tabword consisting of a rhythm sign on its own without any pitch data represents a rest or silence of the duration implied by the rhythm sign. Other events, such as bar-lines, line and system breaks and time signatures also have their own symbols with whitespace on either side.

The TabCode format has has two levels of encoding available:

• Basic TabCode

  This level allows for the encoding of sufficient information to construct a tablature edition. It lacks some of the more advanced notational details of complete TabCode, but permits faster input and is less verbose. A common procedure will be to generate Basic TabCode in the first stage of transcription of a source and then to add extended features in subsequent stages.

  Both levels of encoding are potentially subject to change, but the more intensive testing and use of Basic TabCode means it can be considered a stable format.

  Basic TabCode covers rhythms, pitches and a selection of Other events.

• Full TabCode

  The Full TabCode implementation permits the use of a number of more sophisticated features. These include more complex musical or graphical elements - lines, ornaments, fingerings and text items - and a provision for editorial amendments.

  This specification is subject to expansion, as and when new ornaments or symbols are felt to be needed, but this should not affect backwards compatibility, as a degree of expansion is contained within the specification. The format has, however, had less intensive testing than Basic TabCode, and so it is possible that elements of it will be revised