final report transcribing lute tablature from midi files

Registration number 85

Final ReportTranscribing Lute Tablature from MIDI

Files

Supervised by Gavin Cawley

University of East Anglia

Faculty of Science

School of Computing Sciences

Abstract

Learning a fretted, stringed instrument poses a unique problem for beginners - the de-

cision of exactly how to play any given note. For instruments of this nature, any single

note may be played in several different places. Tablature notation is a style of musical

notation which describes a score as a sequence of string-fret pairs, rather than specific

pitches, unburdening the performer of said decision. This report describes the con-

struction and function of a software system - hereafter referred to as ‘System X’ - for

converting MIDI files into tablature notation. This system is specifically aimed at tra-

ditional lute music. The mechanism for evaluating the playability of particular chord

patterns, and thus, for determining the best way to fret the music, attempts to model the

biomechanical constraints of the human hand. The finished tablature is exported and

typeset using third-party software.

Acknowledgements

I would like to acknowledge and thank Dr. Gavin Cawley for his support and supervi-

sion during this project.

CMPC3P2Y Contents

Contents

1. Overview 1

1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1. S2T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.2. Graph Search . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.3. Genetic Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Existing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1. Power Tab Editor v1.7 . . . . . . . . . . . . . . . . . . . . . . 5

1.3.2. Guitar Pro 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5. Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Sequence Input 12

2.1. MIDI Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2. MIDI Input and Transformation . . . . . . . . . . . . . . . . . . . . . 13

2.2.1. Preliminary Chord Reduction . . . . . . . . . . . . . . . . . . 16

2.3. Score Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3. Fretting Algorithm 18

3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1. Retry Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2. Chord Fitness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1. Preliminary Chord Tests . . . . . . . . . . . . . . . . . . . . . 21

3.2.2. Chord Ranking Tests . . . . . . . . . . . . . . . . . . . . . . . 22

4. Export 24

5. Evaluation 26

5.1. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Reg: 85 iii

CMPC3P2Y Contents

5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.1. Failings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6. Conclusions 30

6.1. Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.2. Refinements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

References 33

A. Pieces used for system evaluation 35

Reg: 85 iv

CMPC3P2Y List of Figures

List of Figures

1.1. An example of tablature (lower) with traditional staff notation. Unless

otherwise stated, all figures are original works. . . . . . . . . . . . . . 1

1.2. Tablature produced by Power Tab Editor, above, with the original, human-

created tablature, demonstrating the tendency of PTE to avoid jumps. . . 6

1.3. Tablature produced by Power Tab Editor, demonstrating the loss of orig-

inal note durations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4. Gantt chart describing initial schedule. . . . . . . . . . . . . . . . . . . 10

1.5. Gantt chart describing revised schedule. . . . . . . . . . . . . . . . . . 11

2.1. Example MIDI messages, left, for a simple sequence. . . . . . . . . . . 13

2.2. Flow chart outlining the process of creating a score from a MIDI input. . 15

3.1. Flow chart outlining the process of fretting a score. . . . . . . . . . . . 19

3.2. Typical fretting for an A5 chord (left), and a possible position for an A5

with a sustained B5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1. An example of tablature produced by Wayne Cripps’ TAB software. . . 25

4.2. Different styles of lute tablature: French (left), Italian (right) and Ger-

man. Source http://en.wikipedia.org/wiki/Tablature#Lute_tablature . . . 26

5.1. Bar chart showing proportion of chord match-ups with human-created

tablature, for System X and Power Tab Editor. . . . . . . . . . . . . . . 28

Reg: 85 v

CMPC3P2Y List of Tables

List of Tables

1.1. Statistics for the number of possible positions for each note within the

instrument’s range. Values shown for a 6-string guitar with 22 frets, in

standard tuning, and a 6-course lute with 10 frets in renaissance G tuning. 8

5.1. Evaluation score statistics for System X and Power Tab Editor. . . . . . 28

Reg: 85 vi

CMPC3P2Y 1. Overview

1. Overview

1.1. Motivations

The two most common forms of musical notation are staff notation and tablature. The

former can be used to notate any instrument, since it represents music as a sequence

of absolute pitches, but takes time to learn to read. The use of tablature is restricted to

stringed, fretted instruments - most commonly guitar, lute, mandolin and banjo - since it

indicates precisely which string to play, and where. The use of traditional staff notation

poses a problem for beginners: most stringed instruments have several places where the

same note can be played, forcing the performer to decide exactly where to fret each

note or chord. This difficulty can limit the availability of music with which to practise,

and discourage beginning musicians. Figure 1.1 exhibits the difference between tabla-

ture and traditional staff notation. The former is more intuitive, and much easier for

beginners to work with, since it unburdens them of the fretting decision.

Figure 1.1: An example of tablature (lower) with traditional staff notation. Unless oth-

erwise stated, all figures are original works.

Due to its small size and portability, the MIDI format is often used to create and

circulate music. Numerous communities and individuals exist and dedicate time to the

distribution of music, in a number of formats (such as ASCII, PDF, and MIDI), such

as the Ultimate Guitar archive (Ultimate-Guitar, 2014), or Sarge Gerbode’s lute archive

(Sarge Gerbode, 2014). The purpose of this project is to develop a system that is ca-

pable of translating a MIDI file - specifically, one that encodes music written for the

Reg: 85 1


renaissance lute - into a form of tablature notation. Several commercial systems exist

already, notably Guitar Pro (ArobasMusic, 2010) and Power Tab Editor (Larsen, 2000),

but these are not tailored to producing lute tabs, which has some notational differences

to regular guitar tablature. Developing such a system would be of benefit to novice lute

players, by allowing them to produce a tab for any music that they can acquire a MIDI

file for.

1.2. Literature

1.2.1. S2T

Score-to-Tablature (S2T), is a system for determining appropriate fingering for guitar

music, developed by Miura and Yanagida (2002), and later described further by Miura

et al. (2004)). According to the developers, S2T compared favourably to unnamed com-

mercial systems, although it didn’t meet the same standards as expert guitar players.

However, the system described could not tabulate music containing chords, making it

unusable for most practical purposes. Furthermore, S2T only accepted melodies repre-

sented in a bespoke file format.

The cost evaluation of finger positions was based purely on sum movement of the

player’s left hand/fingers. Although this method may appear overly simple, if the sys-

tem does not accept chords, then there is little else to consider. One noteworthy point

is that S2T does partition input scores into phrases (based on rests and breaks in the

piece), finding the optimal fingering positions for each phrase as a whole. It is worth

highlighting that the best solution for the problem of chord positioning is unlikely to be

found by a greedy heuristic i.e. a method that ignores the piece as a whole and simply

focuses on each chord in isolation.

1.2.2. Graph Search

Another system, one that mapped the problem to a graph search, was proposed by

Sayegh (1989). Each node in a directed graph represented a possible position for a

given note, with the edges weighted by cost of transition (penalties assigned to chang-

ing hand position, and to changing strings). By solving the graph for the least-cost path,

Reg: 85 2


a global optimum can be found. This was later extended by Radicioni et al. (2004), who

proposed the (manual) segmentation of a piece into phrases1, and solving each phrase

individually. A composer writing guitar music will (usually) be writing for a specific fin-

gering arrangement, which will be optimised (according to their personal standards) on

a phrase-by-phrase basis. This arrangement can be guessed more accurately by dividing

the piece into phrases (assuming these divisions are accurate). However, manual seg-

mentation is a cumbersome limitation of the proposal. Automated segmentation would

be an improvement, but this can be difficult to achieve in practice, requiring musical

analysis of chord progressions when breakpoints are not clear-cut.

1.2.3. Genetic Algorithm

Another approach was described by Tuohy and Potter (2005). Their system makes use

of the genetic algorithm paradigm to ‘evolve’ an optimal solution, which operates in the

following manner:

1. A population of random, but viable tabs is produced.

2. Individuals are evaluated for playability - fitter specimens are chosen as ‘parents’

, and ‘children’ are created by splicing sections of said parents.

3. The process is repeated, with the convergence of the population indicating a prob-

able optimum.

The fitness function used to evaluate phrases for this system appears to be more com-

prehensive. The function is described as assessing total hand and finger movements,

number of string depressions (preferring open strings), and rewarding more favourable

hand contortions. The system was assessed by comparing tablature it had generated to

that generated by Guitar Pro 4, and also to that which had been originally published

(i.e. originals created by human experts).

One notable advantage of the genetic algorithm is the implicit parallelism of its

search; favourable possibilities from all over the state-space come together, creating

1A musical phrase can be thought of as a perceivable segment of a piece, defined by a particular musical

idea. Usually, the conclusion of a phrase can be detected by a distinctive harmonic resolution.

Reg: 85 3


a convergence that is usually close to the global optimum. This approach elegantly

overcomes the problem of ‘looking ahead’ in a piece, in order to ensure that a local

choice of fingering does not compromise the playability of later sections.

An extension of the genetic algorithm system was later described by Tuohy and Potter

(2006). This paper mainly describes the tuning and optimisation of the original system,

but also includes the addition of an artificial neural network for notating Left-Hand

Fingering2 (LHF). The extensions to the system are as follows:

Distributed Genetic Algorithm (DGA) Instead of initialising the system with a single

population, several ‘islands’ are created. These perform the genetic algorithm

individually, occasionally swapping particularly fit individuals. This results in

a more comprehensive search of particular areas of the state-space, producing a

more well-rounded solution.

DGA Optimisation The DGA operates within a set of eight parameters (number of is-

lands, population size, etc.), the values of which can be optimised to more com-

prehensively and efficiently search the state-space. This is accomplished by sys-

tematically testing different combinations of values, and evaluating the solutions

produced.

Fitness Function Optimisation The fitness function - comprising fourteen parameters

- was developed using the author’s musical expertise, and was tuned in a similar

manner to that in which the DGA was tuned.

Artificial Neural Network (ANN) This was developed, trained and optimised to deter-

mine the best Left-Hand Fingering notation for the tablature.

The authors reported considerable success with this system, and this is partly due to

the optimisation processes. However, it should be noted that the training sets for these

processes will influence their efficiency. The LHF-ANN, for example, was reportedly

trained using thirty pieces of guitar tablature, by composers from all across the classical

spectrum (from the 17th-20th centuries). However, this set does not exhaust the range

2In tablature, notes are usually defined as a string-fret pair, but a third variable can be included to specify

the exact finger that should be used to depress that string.

Reg: 85 4


of compositional styles and musical genres in existence, and may cause the system to

perform poorly for, say, an Iron Maiden track. In general, if expected input to the

system is not constrained, it should expect anything. Thus, the bigger and more varied

the training sets, the more prepared will be the system.

1.3. Existing Software

1.3.1. Power Tab Editor v1.7

Power Tab Editor (PTE) is a system for viewing, creating, editing and playing back

tablature. It is capable of importing MIDI files, and exporting them in the MIDI, HTML

and ASCII formats.

When importing a MIDI file, PTE allows the user to view and merge the different

tracks found in the sequence, and also to select the tuning used for each track. This

is a very useful feature, since the track-by-track make up of MIDI files can vary con-

siderably. Different ‘voices’3 in the composition may be set on different tracks, or the

piece may have been originally written for an ensemble (such as a string quartet), so

it is useful for the user to be able to merge these together. This is described further in

section 2.2. In addition to these facilities, the user also has the option to transpose the

piece up or down an octave, and to select the fingering style. It was observed that the

default picking style produced mostly unusable tablature, so the ‘fingerpick’ option was

used for all evaluation.

The ability of PTE to produce playable tablature was analysed by importing MIDI

tracks containing lute compositions. The resultant tablature was then evaluated using the

author’s expertise, and through comparison with the original human-created tablature.

Thus, several points regarding the way PTE frets music were identified:

• In the first instance, PTE attempts to fret notes as low as possible. This created

tablature very similar to the originals; indeed, for many of the pieces, much of the

positioning was identical.

3A musical ‘voice’ is an identifiable melodic line. The term originates from choral compositions, which

are made up of different parts, to be sung using different types of human voice - soprano, bass, tenor,

etc. A piece written for a single instrument may still contain several voices.

Reg: 85 5


• PTE appears to penalise jumps up and down the fretboard, preferring to keep

the positioning as consistent as possible. However, this creates an interesting

effect whereby, upon encountering a phrase that can only be played high, PTE

then continues to fret notes nearby, instead of returning to the lower end of the

fretboard. This is demonstrated in Figure 1.2: after the first bar, PTE elects to use

higher frets and lower strings, in order to prevent jumping (as it sees it). It should

be noted, however, that PTE offers no way to constrain the number of frets on the

instrument; it will allow any fret up to 29 to be input.

• Chords are not checked for playability. Occasionally, PTE was observed produc-

ing unplayable chord combinations; in one instance, the combination [7 5 4 5 3

x] was produced, a physical impossibility.

• The original durations of notes are not preserved. Where a long note occurs si-

multaneously with a short note: instead of duplicating the note and tying it, the

longer note is shortened. The result is that this note, which should be held, is not

taken into consideration when positioning future notes. For example, consider

Figure 1.3. The four lower notes should each have four times their displayed

duration, being held while the higher notes are played. However, since their du-

rations have been shortened, they are not considered when positioning the higher

notes, resulting in awkward stretches spanning frets 2-7, and frets 4-9.

Figure 1.2: Tablature produced by Power Tab Editor, above, with the original, human-

created tablature, demonstrating the tendency of PTE to avoid jumps.

Reg: 85 6


Figure 1.3: Tablature produced by Power Tab Editor, demonstrating the loss of original

note durations.

1.3.2. Guitar Pro 6

Guitar Pro (GP), while having considerably more functionality than PTE, actually lacks

some basic features for creating tablature through MIDI import. GP can import MIDI,

ASCII, MusicXML, Power Tab and TablEdit (another commercial system) files, and

export tablature to MIDI, WAV, ASCII, PDF, PNG and MusicXML formats. This is a

much wider range than that of PTE. However, the MIDI import function does not allow

any manipulation of tracks prior to processing. When importing one piece, a string

quartet, GP simply dumped each track into a separate staff, with the number of strings

and tunings of the original instruments (i.e. violin, viola, cello). No options are given to

the user, such as selecting a tuning, or merging tracks. As such, the user has to manually

re-arrange and merge the tracks.

The focus of GP is on the manual creation and playback of music, and has a wide

range of features for this purpose. Its Realistic Sound Engine (RSE), is capable of

producing realistic-sounding playback. GP also includes a number of effects and tools

that can be applied to the instruments, including virtual amplifiers, distortions, EQ,

modulation and compression. The representation of music by GP is also much better

than that of PTE - among other things, bars are checked to ensure they contain the

correct number of beats, and left-hand fingering notation can be added. Despite this

functionality, it was determined that GP would not be used as a reference during the

evaluation of System X, due to the awkward process of importing MIDI processing.

Reg: 85 7


1.4. Scope

Whilst other work in this area has used the modern guitar as a basis, this project is

specifically examining music written for the lute, with a particular focus on baroque

and renaissance pieces (as opposed to contemporary compositions). This means that we

can constrain our expected input accordingly.

The instrument itself, while there is some variation, typically has less frets than a

modern guitar - around 8-10, as opposed to 20-24. This reduces the number of possible

positions for each note (see Table 1.1). Furthermore, there are notable differences in the

types of composition we can expect to see. Baroque and renaissance lute compositions

are usually less variable. They generally comprise sequences of chord progressions,

where a particular pattern of chord is held, and a melody is played on top of it. This

means that, on average, more strings are being held down at any one time, and the

performer’s left hand is much more restricted.

In contrast, contemporary guitar compositions are much more variable. Guitar parts

written for an ensemble performance are usually defined as either ‘rhythm’ or ‘lead’.

The former generally comprises background chords and supporting harmonies. The

latter is often more flamboyant, with difficult melodic sections, colloquially known as

‘solos.’ The consequence of this is that we can reduce the number and variety of situ-

ations that the system will be expected to cope with. For example, the rhythms used in

baroque and renaissance music are, typically, quite regular (compared to later music),

with little syncopation or irregular note groupings. This reduces the need for System X

to be able to handle rhythmically-complex input.

Table 1.1: Statistics for the number of possible positions for each note within the instru-

ment’s range. Values shown for a 6-string guitar with 22 frets, in standard

tuning, and a 6-course lute with 10 frets in renaissance G tuning.

Guitar LuteMean 3.0 1.9

Mode 3/4 2

Max. 5 3

Reg: 85 8


1.5. Schedule

The project was divided into two broad sections: understanding and transforming MIDI

files into some representation of a score, and developing an algorithm for calculating

fret positions. These were designed to be completed linearly, since the second section

cannot readily be developed and tested without the first being at least at a working

prototype stage. By the time of revision, work had been completed almost to schedule -

that is, the MIDI transformation stage was nearly complete, and was already in a usable

state. No formal testing occurred, excepting that of the final system. However, parts of

the program were tested on an ongoing basis, to ensure functionality and detect bugs.

Figures 1.4 and 1.5 show the initial and revised schedules, respectively.

1.6. Summary

From the reviewed literature and commercial systems available we can conclude several

important points regarding the project:

• The best approach will not be a greedy heuristic, but rather some method that

considers the piece as a whole.

• There are a number of generic techniques for searching the state space - we must

decide which best suits the requirements.

• The function used to evaluate the difficulty of chord patterns must be reasonably

accurate and fit for purpose, as this will have the greatest effect on the system’s

quality. Ideally, this should be systematically optimised.

• A useful system will accommodate the communities and users it is designed to

benefit i.e. producing output in a variety of convenient file formats, being able to

handle input files containing a range of musical features.

Reg: 85 9


Proj

ects

ched

ule

show

nfo

re-v

isio

nw

eek

num

bers

and

sem

este

rwee

knu

mbe

rs

89

1011

1213

1415

1617

1819

2021

2223

2425

2627

2829

3031

3233

3435

3637

3839

12

34

56

78

910

1112

CB

12

34

56

78

910

1112

EB

AS

Prop

osal

/Lit.

Rev

iew

/Res

earc

h

Lea

rnin

gM

IDIA

PIan

dD

isse

ctin

gFi

les

Lea

rnin

gTy

pese

tterF

ileFo

rmat

and

Exp

ortin

g

Cre

atin

gA

dapt

able

Map

ping

sfr

omM

IDIt

oFr

et

Map

ping

Not

esto

Ran

dom

Fret

s

Inve

stig

atin

g/Im

plem

entin

gL

egal

Fret

ting

Rul

es

Rev

isin

gR

esea

rch

into

Fret

ting

Opt

imis

atio

n

Iter

ativ

ely

Dev

elop

ing

Fret

ting

Rul

es

Fina

lTes

ting

and

Cod

eR

evis

ion

Cod

eD

eliv

ery

Rep

ortW

ritin

gan

dIn

spec

tion

Prep

arat

ion

Figure 1.4: Gantt chart describing initial schedule.

Reg: 85 10


Proj

ects

ched

ule

show

nfo

re-v

isio

nw

eek

num

bers

and

sem

este

rwee

knu

mbe

rs

89

1011

1213

1415

1617

1819

2021

2223

2425

2627

2829

3031

3233

3435

3637

3839

12

34

56

78

910

1112

CB

12

34

56

78

910

1112

EB

AS

Wor

kTo

Pres

ent

Com

plet

eSc

ore

Rep

rese

ntat

ion

Com

plet

eE

xpor

tFac

ility

Exp

and

On

Fret

ting

Rul

es

Des

ign

Gen

erat

ion

Alg

orith

m

Test

Alg

orith

m

Fina

lMod

ifica

tions

Rep

ortW

ritin

g

Figure 1.5: Gantt chart describing revised schedule.

Reg: 85 11

CMPC3P2Y 2. Sequence Input

2. Sequence Input

2.1. MIDI Format

The Musical Instrument Digital Interface was standardised in 1983 (MIDI Manufac-

turer’s Association Inc., 1995). It is a protocol defining modes of communication and

interaction between electronic synthesisers, computers, and other devices. Music is

arranged as an interpretable set of instructions, known as a sequence. Sequences are

streams of bytes, which relay a set of messages. Messages may pertain to one of sixteen

channels - each of which may be representing a different musical instrument - and are

divided into three categories:

Meta Messages These are used to convey particular composition information, includ-

ing, but not limited to, tempo, time signature, key signature, and track names.

Short Messages These include note on/off messages, pitch wheel bends, and playback

start/stop commands.

System Exclusive Messages These messages are manufacturer, or even device, spe-

cific, and are used to relay instructions relevant to a particular model or brand of

synthesiser.

In addition to an instruction, each event is labelled with a tick. This value, the scale

of which is arbitrary, is used to position events relative to each other. The absolute

duration of a tick is determined by inspecting the sequence’s timing division and tempo.

Timing division has two formats: SMPTE and PPQ. SMPTE (Society of Motion Picture

Television Engineers) gives an absolute time value for a tick. The alternative, Pulses Per

Quarter (PPQ), specifies how many ticks make up a single beat (one quarter note). If

this is the case, then a tempo meta message will also be given to specify how many

microseconds pass in the duration of a single beat. By dividing the tempo by the PPQ

value, we can obtain the number of microseconds per tick. Figure 2.1 shows an example

of some of the messages that would make up a simple sequence.

The MIDI specification also provides for some other functionality which is not cur-

rently supported by System X, but could be used to make improvements. For example,

Reg: 85 12


Tick Message Value0 PPQ 120

0 Note On C5

120 Note Off C5

120 Note On G4

300 Note Off G4

300 Note On B4

360 Note Off B4

360 Note On C5

480 Note Off C5

Figure 2.1: Example MIDI messages, left, for a simple sequence.

the ‘velocity’ value for Note On/Off messages is discarded, but could be used to detect

and notate performance dynamics, such as crescendi4. Pitch bends5 can be indicated

by Pitch Wheel messages; traditional lute music doesn’t generally require this, but the

system could be extended to cater for music that does.

2.2. MIDI Input and Transformation

System X is written exclusively in the Java programming language, and makes consid-

erable use of the javax.sound.midi package, an extensive API for handling MIDI

sequences (Oracle, 2013).

In order to transform a MIDI sequence into a representation of a score, we need to

determine each note that occurs, and their durations. This is done by iterating over

the Note On/Off messages, calculating lengths by subtracting the tick at which a note

is turned on from the tick at which it is turned off. Using the PPQ value, these notes

can be mapped to modern staff notation values (crotchet, quaver, etc.), which is used to

typeset the score.

4Crescendi (singular crescendo), represent a swell in volume.5A ‘bend’ is a physical bending of an instrument’s string to effect a more gradual change in pitch, used

to segue between notes or to create vibrato.

Reg: 85 13


Two sets of durations are calculated: one for regular note durations, and one for

triplet note durations. These will also be used in the export function, for determining

the correct rhythm flags to use for each note. The triplet set is required because irregular

groupings change the duration of a note. Of course, triplet groupings are just one of the

ways in which notes can be grouped irregularly, but this is the only one that System X

supports.

For each note, an attempt is made to match the calculated duration with a value in one

of these sets. If no match is found, then one of two things will occur:

1. If the duration is shorter than all available durations, then the note is discarded

(most likely they form part of an ornament, which System X does not handle).

2. In all other cases, the note is snapped to the nearest available duration.

It should be noted that MIDI sequences vary in their composition somewhat, due to the

number of different programs and software packages available for constructing them.

For example, instead of sending Note Off messages to end a note, some files have been

found to use Note On messages with a velocity value of zero. Some other deviations

include:

Track Arrangement Sequences can be divided into a number of tracks. This is an imi-

tation of the way recordings used to be made on multi-track cassette tapes, but it is

not part of the MIDI specification, and the manner of division is entirely arbitrary.

It is common practice to set each instrument in a sequence in its own track, but

this may not always be the case. Some files have been found to spread the data

for single-instrument compositions across more than one track. Sometimes, the

piece may have originally been written for an ensemble, such as a string quartet.

System X accounts for this by using the presence of Note On/Off messages to

determine which tracks have actually been used, and then collating the messages

from these tracks.

Playability Files used for testing have not always necessarily been written for the tar-

get instrument. Sometimes notes or chords indicated by the file are not even

playable, given the number of strings on the instrument, and their tuning. For

Reg: 85 14


Figure 2.2: Flow chart outlining the process of creating a score from a MIDI input.

Reg: 85 15


convenience, the system initially removes any notes which are beyond the range

of the instrument, and reduces (as far as possible) any chords which are immedi-

ately determined to be unplayable (see section 2.2.1 for details of the reduction

mechanism). Any duplicate notes are also removed.

2.2.1. Preliminary Chord Reduction

Initially, any duplicate and out-of-range notes are removed. Then, each chord in the

tablature is checked in turn, where a chord is a list comprising one or more notes that

occur simultaneously. If no playable combinations are found for the chord, then the

following steps are taken:

1. If the number of notes in the chord is three or less, the algorithm terminates,

and the system throws an error indicating that it is unable to process the piece.

It is deemed that the reduction of a three-note chord removes too much musical

meaning from it. The piece was most likely written for a differently-tuned lute,

or an entirely different instrument.

2. If there are at least four notes in the chord, then the algorithm first checks to see

if there are any octaves in the chord6. To the ear, notes separated by this interval

sound ‘the same,’ and for this reason the algorithm drops one of these first. If an

octave is found, the algorithm will drop the lower of the set of notes, since the

loss of higher notes is usually more noticeable.

3. If there are no octaves in the chord, the algorithm drops the note with the median

pitch.

2.3. Score Representation

The score is represented as a Java class, Score. Salient details are stored in mem-

ber fields, and the actual notes are represented by a list of chords, which are lists of

6An octave is an interval of twelve semitones between two notes (for example, the interval between C4

and C5).

Reg: 85 16


Notation objects that occur at the same position7. A Notation stores a length and a

position, and is currently sub-classed by Note, Fret and Rest. A Note has an addi-

tional field - value, representing the actual pitch of the note as an integer conforming to

the MIDI specification for notes. A Fret has two additional fields - a fret and a string,

where the fret is an integer between zero (unfretted) and the maximum number of frets,

and the string is an integer between zero (lowest string) and one less than the number of

strings. When a Score is processed, it is converted into a Tablature. A Tablature is

essentially equivalent to a score, containing the same salient details. The Notation list,

however, contains Frets and Rests, instead of Notes and Rests.

The rationale behind the use of a class hierarchy to represent elements of the score

was that it could be used to handle certain notations which made more sense as a sin-

gle entity, rather than a sequence of notes. For example, a ‘trill’ is a type of musical

ornament. A performer plays a trill by alternating two notes repeatedly, at an arbitrary

speed, over a given section of the score. Since much of the way in which a trill is played

is down to the performer, both traditional staff notation and tablature prefer to print a

symbol to indicate a trill (along with the notes to play it over) instead of explicitly print-

ing each note. Thus, it could be useful to have a mechanism for representing trills, and

other, similar ornaments, for the purposes of processing and exporting the tablature.

The length and position values for Notation objects was originally given in relation

to the duration of a 32nd note i.e. a note would last for X 32nd notes. The motivation

for this was to simplify note positioning. Furthermore, notes shorter than a 32nd occur

very rarely in renaissance and baroque music. This was soon found to be too restrictive

- certain durations could not be represented (specifically, tuplets8. The system was later

modified to simply use the original MIDI ticks for length and position, as it is always

guaranteed that the PPQ value is sufficiently divisible to represent all the notes in the

sequence (since the sequence was created in the first place).

7Initially, this was simply a list of Notations. However, it was found that, more often than not, whenever

the Score was being processed, a list of all Notations at the same position was needed, so it made

more sense to collate them once - upon the initial construction of the Score object.8A ‘tuplet’ is a grouping of a number of notes such that each note in the grouping lasts for an irregular

duration. For example, a ‘triplet’ is typically three notes of equal but irregular duration being played

in the space of 2 notes of regular duration (each note is 2/3 its normal length).

Reg: 85 17

CMPC3P2Y 3. Fretting Algorithm

3. Fretting Algorithm

3.1. Overview

The current implementation of the system uses a greedy heuristic. The process iterates

over the chords in the score and, for each chord, determines the best position by ranking

all playable positions. Figure 3.1 shows this process - the mechanism by which the

algorithm records and accounts for tried combinations is described in Section 3.1.1.

3.1.1. Retry Facility

When deciding how to position any given chord, previous chords must be taken into ac-

count. Often, notes from previous chords will still be ringing, and thus, the strings must

still be depressed. This means the position chosen for the next chord must accommodate

these held notes.

During the algorithm, a list of held frets is maintained. When a chord needs to be

fretted, this list is passed to the chord generation function, which subsequently removes

all generated combinations which do not contain every fret in the list. Consider Figure

3.2. The left-hand image shows a common fretting pattern for an A5 chord. However,

suppose that the second string is still being depressed at the second fret, due to a previous

chord; in this case, the chord generation function would omit the first combination,

instead returning something like that shown in the right-hand example (the fifth fret

depression on the bottom string replaces what would’ve been the open second string).

Notes sustained from previous chords create a chain of dependencies between chords.

For example, if Chord B is fretted while some notes from Chord A are still held, the

position of Chord B will depend on the position of Chord A. Furthermore, if Chord C

is then fretted while notes from Chord B are still held, then a chain is created where

C→ B→ A. If a situation occurs where Chord C is deemed unplayable, the algorithm

must first check whether this is due to previous dependencies, or not. If there are no

held-over notes, the system knows that there are no dependencies, and that the chord is

unplayable due to the notes it contains. However, if there are held-over notes, there may

yet be a way to fret the chord, if previous dependencies are changed. In this case, the

algorithm follows this sub-procedure:

Reg: 85 18


Figure 3.1: Flow chart outlining the process of fretting a score.

Reg: 85 19


Figure 3.2: Typical fretting for an A5 chord (left), and a possible position for an A5 with

a sustained B5.

Reg: 85 20


1. Go back to the chord containing the most recent held-over note, undoing progress

up to that point.

2. Check whether this chord has possible combinations that haven’t been tried yet.

a) If so, log the previously-used combination, choose another one, and continue

to process the score.

b) If not, then check whether this chord has any dependencies i.e. having re-

moved held-over notes up to this point, are there still remaining held-over

notes.

i. If not, then we have exhausted all possible combinations for a chord

with no dependencies - the piece is unplayable.

ii. If so, then go back to next chord containing the most recent held-over

note, and repeat the process.

3.2. Chord Fitness

3.2.1. Preliminary Chord Tests

When a chord needs to be fretted, a ‘generate-all’ function is used to create a collection

of playable combinations. As input, this function takes a list of notes in the chord, a

tuning for the instrument, the number of frets for the instrument, and a set of instrument-

specific rules. The function then follows this algorithm:

1. Generate all ways the given chord could be fretted (this includes impossible com-

binations, such as ones that use the same string for more than one note).

2. Remove generated combinations with any of the following properties:

a) A string has been used for more than one note,

b) The distance between the lowest and highest frets (ignoring open strings)

exceeds the allowed stretch, according to the given rules,

c) More than four unique frets have been used: the performer has only four

fingers with which to depress strings (the thumb can sometimes be wrapped

Reg: 85 21


around the neck of the instrument to depress the lowest string, but this is

currently disallowed),

d) An invalid barre chord occurs. A ‘barre’ is the action of a performer using

a single finger to depress multiple strings at the same fret, by laying the

finger across the fretboard. A chord is determined to require a barre if it

has more than four notes (since there are only four fingers available, at least

one finger will have to fret more than one note). The position of the barre

is determined by taking the lowest fret in the chord that occurs more than

once. Once the fret of the barre is determined, the chord is deemed invalid

if any notes occur on frets lower than this. This is because barres are almost

always played using the index finger, making it physically impossible to fret

anything below it. Consider a chord positioned on frets [2 2 4 4 2 2]; a

typical barred chord, the index finger will lie across the second fret, with the

ring and pinky used to fret the fourth fret notes. Now consider [2 2 1 1 2

2] - there is no way to depress all the second-fret strings, and still reach the

first-fret ones.

The abstract Java class FrettingRules is a template for creating a set of rules

for chord generation. This class specifies a number of properties for which values must

be given: maximum chord range, on the upper and lower halves of the fretboard9; and

weightings for each of the chord ranking tests. Functions involved with chord generation

require an implementation of this class as an input parameter, so one need only define

another extension of this class to alter the way in which chords are generated and ranked.

3.2.2. Chord Ranking Tests

Once all valid combinations have been generated, a score is determined for each one, in

order to determine the most suitable position to use. Each chord is awarded a score, from

0 to 1 (where 1 is a perfect score), for 4 different categories. Each of these categories is

assigned a percentage weight, denoting its relative importance in the decision process,

9On fretted instruments, the width of each fret decreases towards the body of the instrument; thus, one

can span more frets on the upper half of the fretboard, than on the lower half.

Reg: 85 22


which is then multiplied by that category’s score. The sum of all scores gives the total

score - again, from 0 to 1.

Position on the Fretboard After examination of tablature available at Sarge Gerbode’s

website (Sarge Gerbode, 2014), it is evident that the upper half of the fretboard is

used relatively rarely in classical lute music. Since, in most cases, the piece was

originally placed lower down the fretboard, the scoring system rewards chords

that occur lower down. The position of a chord is determined by its highest fret.

The equation for determining this score is

1− chordMaxinstrumentMax

where chordMax is the chord’s highest fret, and instrumentMax is the number of

fret’s on the instrument. Thus, the best score, 1, occurs when every note in the

chord is an open string. The score decreases linearly as the chord’s maximum fret

increases.

Range of the Chord This category rewards chords with smaller ranges, since these are

generally easier to play. The score for this category is determined by the formula

1− chordRangemaxRange

where chordRange is the range of the chord (that is, the absolute difference be-

tween its lowest and highest frets), and maxRange is the maximum allowed range

of a chord, according to the rules used. A perfect score of 1 is scored when every

note in the chord occurs on the same fret, and this score decreases linearly as the

chord range increases. It should be noted that, for the purposes of this category,

open strings are ignored when calculating the range. Thus, a chord positioned on

frets 0, 4, and 6 would be considered to have a range of two, not six.

Open Strings Chords are rewarded for containing open strings, since these (more often

than not) decrease the overall difficulty of the chord. Open strings do not require

fretting, and so reduce the number of left-hand fingers needed to play the chord.

Sometimes, of course, this is not the case. For example, consider a chord posi-

tioned on frets [5 5 5 0 5 5]: it cannot be said that the open fourth string makes the

Reg: 85 23

CMPC3P2Y 4. Export

chord easier. However, in this, and most other similar cases, the chord actually

becomes unplayable, rather than merely more difficult. These situations are al-

ready taken care of by the chord generation function. The score for this category

is calculated with the formula

openStringschordSize

where openStrings is the number of open strings in the chord, and chordSize is

the number of notes in the chord. Thus, a perfect score of 1 occurs when all of

the notes in the chord are played as open strings. This score decreases linearly as

the number of open strings decreases.

Jumping This category considers the distance travelled from the previous chord, in

an attempt to prevent big jumps from occurring. This category defines a chord’s

position as the value of its highest fret. The score is calculated using the formula

1− |previousMax− currentMax|instrumentMax

where previousMax is the highest fret in the previous chord, currentMax is the

highest fret in the current chord, and instrumentMax is the number of frets on

the instrument. Thus, a perfect score of 1 occurs when both chords share the

same maximum fret. If the chord being scored is the first in the piece, or the

previous chord was a Rest, then this chord is automatically given a perfect score

in this category. This score decreases linearly as the difference in maximum frets

increases.

4. Export

The system is currently capable of exporting tablature into Wayne Cripps’ TAB (Cripps,

2006) format. This format consists of a line-separated list of chords, where a chord is

one or more notes occurring simultaneously. The following is a simple example of a file

in TAB format ( represents a single space):

S2-2

0.0 2

Reg: 85 24

CMPC3P2Y 4. Export

1 000

0 24

x 23

x0 34

x 2

0.2 0

e

Figure 4.1 demonstrates the output TAB produces from this file. Each line represents

a chord, with the first number denoting its duration (lower is longer). A dot will ‘dot’

a chord, increasing its duration by 50%. Following that, a list of frets, one per string

(highest to lowest), with a space denoting an unplayed string. ‘e’ denotes the end-

of-file. An extensive manual for writing this format (Williams, 2006) is available at

ftp:// ftp.cs.dartmouth.edu/ pub/ lute/ TabManual.pdf . TAB is capable of notating using

Figure 4.1: An example of tablature produced by Wayne Cripps’ TAB software.

a variety of different styles. Lute tablature is usually created according to one of three

main styles - French, Italian and German (see Figure 4.2). Currently, System X outputs

using staff notation-style rhythm flags, and numbers to denote frets, but this can be

modified to present the user with a choice.

Reg: 85 25

ftp://ftp.cs.dartmouth.edu/pub/lute/TabManual.pdf

CMPC3P2Y 5. Evaluation

Figure 4.2: Different styles of lute tablature: French (left), Italian (right) and German.

Source http://en.wikipedia.org/wiki/Tablature#Lute_tablature

5. Evaluation

5.1. Testing

The system was tested by comparing produced tablature with that created by a human

expert. Nine pieces of low to moderate complexity were taken from the Sarge Gerbode

website (see Appendix A for a list of compositions). The MIDI files were processed by

System X, and the output compared against the human-created versions, also taken from

the website. For reference, the same files were also processed by Power Tab Editor, and

those outputs were compared against the human-created versions.

For each piece, the proportion of matching chords between the test and human-created

versions comprised the score. Here, a ‘chord’ means any group of one or more notes

occurring simultaneously. A chord matches if both versions position every note in the

chord in exactly the same place. The following settings were used when processing the

pieces:

Fret Limit PTE does not allow the user to set a bound on the fret; thus, the limit was 29,

the maximum PTE will allow to be input. System X was limited to 10, a typical

number for a lute.

Reg: 85 26


Tuning Both programs were set to use 6 strings, in Renaissance G tuning - G2 C3 F3

A3 D4 G4.

Picking Style PTE was set to the ‘Fingerpick’ style. In the initial evaluation of PTE,

the other styles assumed use of a plectrum, producing unplayable tablature. Sys-

tem X always assumes the finger-picking style: since it was designed to cope

with traditional lute compositions, and these are written to be played without a

plectrum.

Stretching Rules PTE does not allow the user to set any additional rules regarding fret

selection. System X was set to a maximum finger span of 4 frets (on occasion,

5 or even 6-fret stretches may be achievable for a performer with large hands,

but 4 is generally the most comfortable, and limits the chances of unnecessarily

difficult positions being selected).

Rule Weightings Again, PTE does not allow the user such control over the process.

System X was set with each rule (as described in Section 3.2.2) being allowed

equal weight, since there was no precedent.

5.2. Performance

The ability of System X to replicate the human-created tablature was about equal to that

of Power Tab Editor. Both programs achieved ∼85%accuracy, and outperformed each

other in a similar number of pieces (Table 5.1). None of the mismatched chord positions

chosen by System X made any of the pieces unplayable, although most created some

unnecessary finger stretches and jumps.

5.2.1. Failings

Both systems demonstrated a number of repeated errors when processing pieces. PTE,

not being constrained by a fret limit, had a tendency to veer off towards the upper end

of the fretboard when positioning chords. It was estimated that this was due to PTE

having a similar chord ranking mechanism to that of System X, in that it penalised

jumps between chords. This meant that higher-positioned chords came in sections -

Reg: 85 27


Figure 5.1: Bar chart showing proportion of chord match-ups with human-created tab-

lature, for System X and Power Tab Editor.

Table 5.1: Evaluation score statistics for System X and Power Tab Editor.

PTE System XMean 86.2% 85.1%

Median 90.3% 83.0%

Max. 99.5% 94.7%

Min. 61.3% 74.5%

Pieces Won 4 5

Reg: 85 28


once a higher chord was chosen, moving back down the fretboard would result in a

jump, and so the algorithm continued to choose high chords. System X demonstrated a

similar behaviour, although the fret constraint reduced the effect.

It was also observed that PTE could not correctly detect triplets in the pieces that

contained them - the chords remained the same, but the rhythm was changed to a close

approximation.

Both systems have the facility to remove notes that are out of the instrument’s range.

However, whenever this occurred in PTE, the chord was lost, in each case being replaced

with a single note (the top string, unfretted). This is most likely a bug of the software,

rather than a deliberate part of the fretting algorithm.

System X often chose chords containing open strings, where another chord would’ve

prevented jumps later in the piece. This is the result of a combination of the greedy

nature of the algorithm, and also the chord ranking rules. When the range of a chord is

determined, any open strings are ignored. For example, the range of a chord positioned

on frets [0 4 5 x x x] is determined to be one, rather than five. This creates an implicit

preference for chords containing open strings, since their range is usually lower. For

example, when played on a 6-string lute in renaissance G tuning, the chords [x 5 4 x

x x] and [x 9 0 x x x] contain the same notes. Due to the nature of the range rule, the

second position is determined to have a lower range - zero, rather than one. Since it

also contains an open string, the second chord will often rank higher than the first, even

though the preceding selections may create an awkward jump, and cause subsequent

chords to be positioned unnecessarily high on the fretboard. In order to avoid this, the

weighting of the open string rule should be reduced considerably, or the rule should be

removed altogether.

It was also noted that, in some of the MIDI files, notes would ring for longer than

they might reasonably be sustained by a performer. This was likely done for aesthetic

purposes, but the effect is that System X tries to hold notes for longer than necessary.

This causes the algorithm to be unable to select what would actually be the most appro-

priate position, being forced to choose something more awkward instead. It would seem

that this did not cause PTE any problems, since it was observed reducing the lengths of

notes, as already described in Section 1.3.1.

Reg: 85 29

CMPC3P2Y 6. Conclusions

6. Conclusions

While the original suggestion was that the best solution would not be a greedy heuristic,

the testing shows that the algorithm implemented works well enough for use with the

target material i.e. traditional lute music. System X performed, overall, on par with a

popular piece of software. Thus, it can be concluded that the chord ranking system is

acceptable for this purpose. It may not, however, be suited to more complicated music.

As it stands, the fretting algorithm is excessively greedy - when deciding how to fret

a given chord, only the preceding chord is considered. It could be possible to improve

the output considerably by implementing a mechanism to guess future positions. Even

looking one or two chords ahead would likely be enough to prevent some of the un-

necessary position choices observed during testing. However, the implementation of a

more complicated system, such as a genetic algorithm, may not be necessary to solve

the problem to a practical degree. The distributed GA system, described by Tuohy and

Potter (2006), reportedly achieved 91.1% accuracy using an optimised fitness function,

and 73% using an unoptimised one ? System X achieved 85.1%, using a much less

refined method.

6.1. Difficulties

The two main functions of System X - score representation and fretting - posed a number

of problems during development.

The transformation of MIDI data into a score is trivial for simple scores; the problem

lies in increasing the complexity of music that it is expected to handle. While nothing

like the problem of interpreting real sound data, MIDI files can still contain information

that confuses a transformation algorithm. For example, the correct detection of note

duration and rhythm. For regular note lengths, this is straightforward. However, when

irregular groupings i.e. tuplets become involved, a cover-all algorithm becomes much

more difficult to implement. System X supports triplets, on the assumption that the

triplet in fact contains three notes, but this is not necessarily the case. A grouping

denotes a change in rhythm over the notes it covers - the number of the grouping does not

necessarily reflect the number of notes in it. For example, typically a crotchet (single-

Reg: 85 30


beat) triplet would contain three crotchets, which are to be played in the same space of

time as two crotchets would normally occur. However, these crotchets could be in fact

replaced by six quavers (half-beat). Since the grouping describes the playing of three

beats in the space of two, this is still perfectly valid. Detecting this, however, is quite

problematic. Given that, theoretically, any grouping containing almost any number of

notes would be notationally valid, covering all possibilities becomes near impossible.

The fretting algorithm itself also posed some problems. The dependence of chords

upon previous selection, as described in Section 3.1.1, was implemented in a somewhat

inelegant manner. Ideally, the solution would be a concise, recursive function call. The

difficulty encountered can be seen in the actual implementation, which is a convoluted,

iterative algorithm.

6.2. Refinements

There are a number of ways in which the system could be improved in future develop-

ment:

Export The addition of support for exporting in other formats - such as ASCII, Power

Tab Editor, Guitar Pro and Fronimo (another popular piece of lute tablature soft-

ware) - would increase the software’s usefulness to the community.

GUI A graphical user interface would make the system more accessible to less experi-

enced computer users.

Chord Ranking A more effective system for ranking chords and determining fitness.

Furthermore, fine-tuning such a system through analysis of a large variety of ex-

isting tablature could reduce the difficulty of the tablature produced.

Fretting Algorithm The algorithm for processing scores could be replaced with a more

efficient, comprehensive solution. At the very least, a mechanism for considering

subsequent and preceding chord positions would avoid some of the issues already

described.

Score Representation The ability of the system to store and represent music could

be improved, allowing a wider variety of input files to be used. Notations such

Reg: 85 31


as ornaments, detection of repeating sections10, and support for more types of

irregular note groupings (tuplets) are some features which could be added.

10Usually, identical sections are not written out multiple times; instead, different types of bar lines are

used to identify sections that are to be repeated.

Reg: 85 32

CMPC3P2Y REFERENCES

References

ArobasMusic (2010). Guitar Pro v6.

Cripps, W. (1995-2006). TAB v4.3.54.

Larsen, B. (2000). Power Tab Editor v1.7.0.80.

MIDI Manufacturer’s Association Inc. (1995). Table 1 - Summary of MIDI Messages.

http://www.midi.org/techspecs/midimessages.php.

Miura, M., Hirota, I., Hama, N., and Yanagida, M. (2004). Constructing a system for

finger-position determination and tablature generation for playing melodies on guitar.

Systems and Computers in Japan, 35(6):10–19.

Miura, M. and Yanagida, M. (2002). Finger-position determination and tablature gen-

eration for novice guitar players. In Proceedings of the 7th International Conference

on Music Perception and Cognition, pages 701–704.

Oracle (1993, 2013). Package javax.sound.midi.

http://docs.oracle.com/javase/7/docs/api/javax/sound/midi/package-summary.html.

Radicioni, D. P., Anselma, L., and Lombardo, V. (2004). An Algorithm to Compute

Fingering for String Instruments. In Atti del Secondo Convegno dell’Associazione

Italiana di Scienze Cognitive (AISC), Ivrea, Italy.

Sarge Gerbode (2014). gerbode.net Home Page. http://www.gerbode.net.

Sayegh, S. I. (1989). Fingering for string instruments with the optimum path paradigm.

Computer Music Journal, 13(6):76–84.

Tuohy, D. and Potter, W. (2005). A genetic algorithm for the automatic generation

of playable guitar tablature. In Proceedings of the International Computer Music

Conference, pages 499–502. sn.

Tuohy, D. R. and Potter, W. (2006). Generating guitar tablature with LHF notation via

DGA and ANN. In Ali, M. and Dapoigny, R., editors, Advances in Applied Artificial

Reg: 85 33

CMPC3P2Y REFERENCES

Intelligence: 19th International Conference on Industrial, Engineering and Other

Applications of Applied Intelligent Systems, IEA/AIE 2006, Annecy, France, June 27-

30, 2006: Proceedings, volume 4031, pages 244–253. Springer.

Ultimate-Guitar (2014). Ultimate guitar homepage. http://www.ultimate-guitar.com.

Williams, L. (2006). TAB - A guide to Wayne Cripps’ tablature typsetting program.

Reg: 85 34

CMPC3P2Y A. Pieces used for system evaluation

A. Pieces used for system evaluation

The following is a list of the compositions used for system evaluation, all of which can

be found at http:// www.gerbode.net:

Ricercar 10 (Bossinensis, F.)

Fantasia 10 (Daza, E.)

Fantasia 20 (Daza, E.)

Praeludium (van den Hove, J.)

Toccata (van den Hove, J,)

Sonata 9 - Prelude (Zamboni, G.)

Sonata 9 - Allemande (Zamboni, G.)

Fantasy 1 (da Milano, F.)

Ricercar 3 (da Milano, F.)

Reg: 85 35

http://www.gerbode.net

final report transcribing lute tablature from midi files

Documents