Algorithms and Data Structures for a

Music Notation System based on

G UIDO Music Notation

Vom Fachbereich Informatik

der Technischen Universität Darmstadt
genehmigte

Dissertation

zur Erlangung des akademischen Grades Dr.-Ing.

vorgelegt von Dipl.-Inform. Kai Renz, geb. Flade

geboren in Darmstadt

Tag der Einreichung: 26. August 2002

Tag der mündlichen Prüfung: 21. Oktober 2002

Referenten:
Prof. Dr. Hermann Walter, Darmstadt
Prof. Dr. Keith Hamel, Vancouver, Kanada

Darmstädter Dissertationen D17

ii
Acknowledgment

First of all, I would like to thank Prof. H. K.-G. Walter for his support. Without him,
research in the field of computer music would not have started at the computer
science department of the Darmstadt University of Technology.
I would also like to express my thanks to Holger H. Hoos and Keith Hamel for
their fundamental work on G UIDO Music Notation and for countless discussions
on the subject of music representation and music notation. Special thanks also to
Jürgen Kilian for many fruitful conversations and encouragement. Additionally, I
would like to thank Marko Görg, Matthias Huber, Martin Friedmann, and Christian
Trebing for working on different aspects of G UIDO. Parts of this thesis would not
have been possible without their work.
Many thanks go to the colleagues at the “Automata Theory and Formal Languages”
group of the computer science department of the Darmstadt University of Technol-
ogy, who have always been extremely helpful and open to discuss the sometimes
unfamiliar subjects of computer music.
Last but not least, I wish to express my love and gratitude to my wife for her trust
in my work.
iv
 Abstract

Many aspects of computer-based music notation have been previously

discussed. The presented thesis deals with the process of converting a
textual description of music into a conventional musical score that can be
either printed or viewed on a computer screen.
The chosen textual music representation language is G UIDO Music No-
tation, an adequate, human-readable format, which has been developed
since 1996. Because G UIDO Music Notation is not solely focused on score
representation but rather on being able to represent all logical aspects
of music, the conversion of arbitrary G UIDO descriptions into a conven-
tional score is not necessarily an easy or straightforward task.
The thesis begins by introducing the three-layered structure of G UIDO
Music Notation. The most important features of G UIDO are presented
and compared to other music representation languages. The thesis con-
tinues to describe how G UIDO descriptions are first converted into a suit-
able computer representation. Then, automatic musical typesetting algo-
rithms work on this inner representation. The major difference to other
music notation systems lies in the fact that all implemented typesetting
algorithms are described as G UIDO to G UIDO transformations. Each step
of the musical typesetting process adds more richness to the G UIDO de-
scription. The final description, which contains all typesetting informa-
tion, is then used for viewing and printing the score.
In this thesis, the implemented music notation algorithms are described,
some of them in detail; especially those parts of the musical typesetting
process that have similarities to text setting, namely spacing and line
breaking, are presented. An improved algorithm for spacing a line of
music is discussed and it is shown how the resulting spacing more closely
matches the spacing of a human engraver. Additionally, a new algorithm
for optimally filling pages is presented for the first time.
The implemented music notation system is used within several applica-
tions including an online music notation server which is freely available
on the Internet using any standard web browser.
vi
Contents

Abstract v

1 Introduction 1

2 The G UIDO Music Notation Format 7

2.1 Basic G UIDO Music Notation . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Notes and Rests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Sequences and segments . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Tags and basic musical concepts . . . . . . . . . . . . . . . . . . 11
2.2 Advanced G UIDO Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Syntax extensions in Advanced G UIDO . . . . . . . . . . . . . . 13
2.2.2 Exact formatting and score layout . . . . . . . . . . . . . . . . . 14
2.2.3 Advanced notational features . . . . . . . . . . . . . . . . . . . . 17
2.3 Extended G UIDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Microtonality and Tuning . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Exact Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Hierarchical and Abstract Scores . . . . . . . . . . . . . . . . . . 19
2.4 G UIDO as a Music Representation Language . . . . . . . . . . . . . . . 19
2.5 Other Music Representation Languages . . . . . . . . . . . . . . . . . . 21
2.5.1 MIDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2 DARMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.3 MuseData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.4 SCORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.5 Common Music Notation (cmn) . . . . . . . . . . . . . . . . . . . 27
2.5.6 Plaine and Easie Code . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.7 MusiXTEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.8 LilyPond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.9 NIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.10 SGML based Music Representation Formats . . . . . . . . . . . 33
2.5.11 Commercial file formats . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.12 Other representation formats . . . . . . . . . . . . . . . . . . . . 37
2.5.13 Comparison chart . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

vii
viii CONTENTS

3 A Computer Representation of G UIDO Music Notation 41

3.1 Defining the Abstract Representation (AR) . . . . . . . . . . . . . . . . 42
3.1.1 Document View Model . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.2 Definition and Requirements . . . . . . . . . . . . . . . . . . . . 44
3.2 G UIDO Semantic Normal Form . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.1 Semantic equivalence . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.2 Transforming G UIDO descriptions into GSNF . . . . . . . . . . 47
3.3 Structure of the Abstract Representation . . . . . . . . . . . . . . . . . 48
3.3.1 Representing chords in the AR . . . . . . . . . . . . . . . . . . . 54
3.4 Transforming G UIDO descriptions into the AR . . . . . . . . . . . . . . 56
3.5 Accessing the AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5.1 Accessing class ARMusicalVoice . . . . . . . . . . . . . . . . . 59
3.5.2 Parallel Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.6 Manipulation of the AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.6.1 Operations on range tags . . . . . . . . . . . . . . . . . . . . . . . 61
3.6.2 Operations on events and non-range tags . . . . . . . . . . . . . 63
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4 Converting Arbitrary G UIDO Descriptions Into Conventional Scores 67

4.1 Music Notation as G UIDO to G UIDO Transformations . . . . . . . . . . 68
4.2 Music Notation Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3 The Graphical Representation (GR) . . . . . . . . . . . . . . . . . . . . 76
4.3.1 Graphical Requirements for Conventional Music Notation Sys-
tems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.3.2 Structure of the GR . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4 Converting the AR into the GR . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.1 Manager-Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.2 Other helper classes . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.5 Spacing, Line Breaking, and Page Filling . . . . . . . . . . . . . . . . . 85
4.5.1 Spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.5.2 Line breaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.5.3 Optimal Page Fill in Music . . . . . . . . . . . . . . . . . . . . . 109
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5 Applications 121
5.1 The G UIDO NoteViewer . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.1.1 Architecture of the G UIDO NoteViewer . . . . . . . . . . . . . . 122
5.1.2 Interface Functions of the GNE . . . . . . . . . . . . . . . . . . . 124
5.2 The G UIDO NoteServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.2.1 Browser-Based access . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2.2 CGI-Based access . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2.3 Usage of JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.2.4 The Java Scroll Applet . . . . . . . . . . . . . . . . . . . . . . . . 130
CONTENTS ix

5.2.5 The Java Keyboard Applet . . . . . . . . . . . . . . . . . . . . . . 131

5.3 Java-based Music Notation and Editing . . . . . . . . . . . . . . . . . . 132
5.3.1 The G UIDO Graphic Stream Protocol . . . . . . . . . . . . . . . . 133
5.4 A Musical Database System and Music Information Retrieval . . . . . 134
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6 Conclusion 137

Bibliography 140

Appendix

Complete Advanced G UIDO Description for Bach Sinfonia 3 147

Curriculum vitae 153

Erklärung 153
x CONTENTS
 “In general, a study of the rep-
resentation of musical notation
induces a profound respect for
its ingeniousness. Graphical
features have been used very
Chapter 1 cleverly to convey aspects of
sound that must be accommo-
dated in the realization of a
single event.” [SF97a], p. 11
Introduction

“Sound waves are longitudinal mechanical waves. [: : :] There is a large range of

frequencies within which longitudinal mechanical waves can be generated, sound
waves being confined to the frequency range which can stimulate the human ear
and brain to the sensation of hearing.”1 This physical description of sound waves
also describes how musical information is usually transmitted: human music per-
ception is always a perception of sound waves. One way to record or store musical
information is therefore the recording of sound waves using microphones. Replay-
ing the recorded sound waves re-creates the original musical information. Because
recording sound waves has been technically possible only for around 1252 years,
other ways of recording musical information were invented earlier and are still used
today. The earliest and easiest way to transmit and store musical information is to
memorize it: a “teacher” sings or plays the music, a “pupil” learns it and can then
play or sing the music by heart. This form of oral transmission of musical infor-
mation is used all over the world everyday and works very well not only for simple
musical structures.3 This approach has several disadvantages: The “teacher” must
be physically present in order to teach the music. As the musical structure gets
more complicated (if, for example, other voices or instruments are added), the oral
transmission may become impossible. Because of these drawbacks, people have at-
tempted to write down music beginning in ancient times [Blu89a]. Obviously, the
musical information contained in written scores is different from recorded sound
waves: Any performance of a written score will sound slightly different depending
on the interpretation of the performer. The information contained in a graphical
score transports the essential musical ideas, but leaves room for interpretation and
ambiguousness.
Only because of the existence of written music, the traditional roles of the com-
poser and the musician (or performer) have come into existence. When recording of
1
Quote taken from [HR78], p. 433.
2
Edison invented the gramophone in 1877.
3
As an example consider children learning children’s songs. In some cultures, extremely complex
music is all transmitted orally.

1
2 CHAPTER 1. INTRODUCTION

sound waves became possible, these roles were beginning to loose importance. Only
because music could be recorded and therefore easily distributed, performers (for
example jazz musicians) were beginning to become as popular as previously only
the composers were. Today, someone can be the composer and single performer of a
piece at the same time; for these musicians, the need to produce a graphical score is
of little importance. Still, a large number of composers are producing scores today,
which are then interpreted and performed by musicians. Therefore, transmitting
musical information using graphical scores is an important subject.
Conventional music notation as it is used today
has evolved over a long period of time, beginning
well before the invention of printing techniques.
One of the most important contributors to todays
music notation is Guido d’Arezzo (? around 992,
y around 1050), who was the first to place notes
on and between lines, which form the staves of a
score known today [Blu89b]. This was the birth of
the two-dimensional structure for graphical music
representation that is used until now.4 As the com-
plexity of musical compositions grew and new in-
struments were invented, music notation evolved
continously to adequately represent the new ideas.
The techniques for producing scores also changed
over time. As printing techniques were invented
around 1500, they were also used and adapted for
music notation. Guido d’Arezzo
The printing process for creating scores that was used from around 1600 until be-
yond the invention of computer driven printers is called engraving [Blu89c, eng98].5
Here, the (human) engraver uses a copper plate to “engrave” the score into the soft
metal plate using specialized tools. The quality and readability of the score greatly
depends on the experience of the human engraver. Very often, music notation is
ambiguous, as there exist multiple ways to represent a musical idea graphically:
“Musical notation is not logically self-consistent. Its visual grammar is open-ended
– far more so than any numerical system or formal grammar.”6 Because of the com-
plexity of the task, some books on the art of music engraving have been written
[Had48, Rea79, Ros87, Vin88, Wan88], which give detailed instructions on how to
engrave music. These instructions are usually derived by studying and extracting
examples from “real” scores, which were engraved by an expert human engraver.
Nevertheless, for almost any typesetting rule, there seems to exist at least one score,
4
As shown in Figure 1.1, the pitch of a note is indicated by the vertical placement on and between
lines of a staff. The attack time of an event is denoted by the horizontal placement on the staff.
Events with the same attack time have the same horizontal position.
5
Some music publishers are still employing human engravers today.
6
Quote taken from [SF97a] (p. 15)
 3

where this rule is explicitly broken in order to obtain a good overall result. This
makes automatic music typesetting a complicated task.

high

pitch
low 0 ¼ ½ ¾
time position

Figure 1.1: Two-dimensional structure of conventional scores

The invention of computers and high quality laser printers has dramatically chan-
ged the way musical scores are being produced today: Nowadays, almost all music
typesetting7 is done with the help of computers, but it must be noted that even
though computer programs are capable of producing very fine scores, a large amount
of human interaction is still required, if high quality output is desired.
The issues and problems found when automatically typesetting music are mani-
fold. Don Byrd, who has written a dissertation on the subject, defines three main
tasks that must be solved by any music notation system: Selecting, Positioning, and
Printing the music notation symbols [Byr84]. Each of these tasks requires know-
ledge that was formerly held by engravers only. In order to automatically create
music notation, the human knowledge must be transfered into a computer system,
a task, which is always challenging and interesting. Different approaches to encode
engravers knowledge into music notation systems have been tried. Most approaches
use a case (or rule) based approach to automatically select and position the music
notation symbols [BSN01, Gie01]. Unfortunately, there is currently little public dis-
cussion on music notation algorithms: most commercial vendors of music notation
software do not publish or discuss their internal algorithms.
Even though quite a number of music notation programs are being used today, no
commonly used and wide spread notation interchange format exists. Even though
many proposals for such an interchange format have been made (for example NIFF
or SMDL), none of them are widely used. One of the main reasons for this seems to
be the complexity of any such format. Because music notation and musical struc-
ture are generally so rich, the developed formalisms are also complex. Very often,
supporting such an interchange format involves enormous effort for an application
developer. Additionally, some developers of commercial music notation software
seem to have little interest in an unrestricted interchange of scores from one appli-
7
Note that the word “typesetting” is borrowed from printed text; actually scores where prepared
using types for a period in time, but the results were not satisfactory. Nevertheless, the term “musical
typesetting” describes the process of creating a visual score (for computer display or printing).
4 CHAPTER 1. INTRODUCTION

cation to another.
The only (structured) music representation format that is widely accepted today is
MIDI, which is not suited as a notation interchange format because it was never
intended as such; much of the information present in a graphical score can not be
represented using MIDI. Many other music representation formalism have been de-
veloped since computers are being used for music information processing. Most of
these were created for a specific purpose and not for notation interchange.
Beginning in 1996, a group of developers began developing a new music representa-
tion language called G UIDO Music Notation8 which is named after Guido d’Arezzo
[HHRK98]. G UIDO is a human readable, adequate music representation language
that is not primarily focused on conventional music notation; it is much more an
open format, which is capable of storing musical, structural and notational infor-
mation. One of the main design criteria for G UIDO was adequateness, meaning
that a simple musical idea should have a simple G UIDO representation, whereas
more complex ideas may sometimes require more complex G UIDO representations.
G UIDO is also intuitive to read because commonly known musical names are used:
it is easy to understand that the G UIDO description [ nclef<"treble"> c d e ]
describes a treble-clef and three consecutive notes c, d, and e. Despite of the intu-
itive character of simple G UIDO descriptions, it can very well be used for represent-
ing complex musical ideas. It was shown in [HHR99] that G UIDO is also very well
suited as a notation interchange format.
Because of its features, an increasing number of research groups and individuals
began to use G UIDO Music Notation as the underlying music representation for-
malism in various music related projects. In this context, the need for an easy
to use music notation system that converts G UIDO descriptions into conventional
graphical scores became quite strong; this demand led directly to the design and
implementation of a music notation system based on G UIDO, which is being de-
scribed in the presented thesis. Other music notation software has been adapted to
import and export G UIDO [Ham98]. Even though G UIDO descriptions may contain
all necessary formatting information, the general process of converting an arbitrary
G UIDO description into a conventional score is not trivial: Because a G UIDO descrip-
tion can be highly unspecified, meaning that no explicit formatting information is
contained, the missing information must be generated automatically. Additionally,
the G UIDO description may contain notes or rests with unconventional durations,
for which no standard graphical representation is possible. These cases must be
dealt with by a set of music notation algorithms, which must first be recognized,
defined, and implemented. It should also be possible to describe each of these music
notation algorithms as a G UIDO to G UIDO transformation. This means that each
algorithm gets a G UIDO description as its input and returns an enhanced G UIDO
description, where well defined formatting aspects have been automatically added.
8
In the following, the terms G UIDO Music Notation and G UIDO are used in parallel. Both terms
describe the format as well as specific files. It will be clear from the context, what is meant.
 5

This concept greatly simplifies the exchange of music notation algorithms and is
also very helpful for generally discussing the issues found in automatic music nota-
tion systems.
Because G UIDO descriptions are human-readable plain text, any application sup-
porting G UIDO requires an internal, computer-suited representation for storing,
manipulating, and traversing the musical data. As part of this thesis an object-
oriented class library, called Abstract Representation, was designed and imple-
mented as such an internal representation for G UIDO descriptions. The G UIDO
parser kit [Hoo] is used to convert a G UIDO description into one instance of the
Abstract Representation. Because the general structure of the Abstract Represen-
tation closely matches the internal structure of G UIDO, the conversion process is
straight-forward. As the Abstract Representation is an object-oriented data struc-
ture, the required manipulation and traversal functions are an integral part of the
framework. These manipulation functions, which are mostly used by music nota-
tion algorithms, include operations for deleting or splitting events or adding musical
markup.
In order to create a graphical score, an additional object-oriented class library, called
the Graphical Representation was developed. Each notational element found in a
conventional score has a direct counterpart in the Graphical Representation. Two
steps are then required to create a conventional score from an arbitrary G UIDO
description: first, the G UIDO description must be converted into the Abstract Rep-
resentation, which must then be converted into the Graphical Representation. Once
the notational elements of the Graphical Representation have been determined,
they must be placed on lines and pages. This requires sophisticated algorithms
for spacing, line breaking and page filling. All of these issues have been thor-
oughly dealt with during work on this thesis. The spacing algorithm used in most
current music notation system, which has been previously discussed in the litera-
ture [Gou87], has been enhanced to provide better results for complex interaction of
rhythms. The line breaking algorithm has been extended to be usable for obtaining
optimally filled pages, which is a standard requirement for graphical scores. There
have been no previous publications on the subject of page filling, although one com-
mercial music notation system includes an implementation of such an algorithm.
The stand-alone music notation system that has been developed using the data
structures and algorithms described above is freely available and is being used by
a growing number of people and institutions around the world. The implemented
music notation system is also used in other areas: the G UIDO NoteServer is a free
Internet service that converts G UIDO descriptions into pictures of scores. This ser-
vice can be accessed using any standard web browser. Another part of research
which was carried out while working on this thesis focused on the development of a
Java based music notation editor.
The rest of this thesis is structured as follows: In the first part of chapter 2, G UIDO
Music Notation is thoroughly described and numerous examples for the various fea-
tures of G UIDO are given; several sections of this part of the chapter are enhanced
6 CHAPTER 1. INTRODUCTION

versions of previous publications [HHRK01, HHR99, HHRK98]. In the second part

of chapter 2, G UIDO is compared to the following other music representation for-
malism in use today: MIDI, DARMS, MuseData, SCORE, Common Music Nota-
tion, Plaine and Easie Code, MusiXTEX, LilyPond, NIFF, and SGML based formats.
Where appropriate, examples contrasting G UIDO and the compared formats are
given. In chapter 3 an internal, computer-suited representation for G UIDO called
Abstract Representation is introduced. It is shown, how this object-oriented class
library matches the internal structure of G UIDO, and how a G UIDO description can
be converted into it. The chapter closes with describing the required manipulation
and traversal functions for the developed data structure. In chapter 4 the conver-
sion of arbitrary G UIDO descriptions into conventional scores is described in detail.
As was already mentioned above, the necessary music notation algorithms can be
described as G UIDO to G UIDO transformations. Additionally, the Graphical Rep-
resentation is introduced and the enhanced algorithms for spacing, line breaking
and optimal page fill are elucidated. Parts of this chapter are currently being pub-
lished in [Ren02]. Chapter 5 shows, which applications have been developed using
the implemented music notation data structures and algorithms. These include a
stand-alone NoteViewer and online applications for music notation. Additionally, a
prototypical Java based interactive music notation editor is described briefly, and
the requirements for a music notation editor are discussed. Most of the content of
chapter 5 has been published previously [RH98, Ren00, RH01, HRG01]. Finally,
chapter 6 gives an overview of the presented thesis and points out possibilities for
further research projects.
Chapter 2

The G UIDO Music Notation Format

Introduction
In this chapter, G UIDO Music Notation,1 a music representation language which
has been developed since 1996 [HH96], will be introduced and compared to other
representation formalisms. G UIDO Music Notation is named after Guido d’Arezzo
(ca. 992-1050), a renowned music theorist of his time and important contributor
to today’s conventional musical notation [Blu89b]. His achievements include the
perfection of the staff system for music notation and the invention of solmization
(solfege). G UIDO is not primarily focused on conventional music notation, but has
been invented as an open format, capable of storing musical, structural, and no-
tational information. G UIDO has been split into three consecutive layers: Basic
G UIDO introduces the main concepts of the G UIDO design and allows to represent
much of the conventional music of today. Advanced G UIDO extends Basic G UIDO by
adding exact score-formatting and some more advanced musical concepts. Finally,
Extended G UIDO can represent user-defined extensions, like microtonal information
or user defined pitch classes.
G UIDO Music Notation is designed as a flexible and easily extensible open stan-
dard. In particular, its syntax does not restrict the features it can represent. Thus,
G UIDO can be easily adapted and customized to cover specialized musical concepts
as might be required in the context of research projects in computational musicol-
ogy. More importantly, G UIDO is designed in a way that when using such custom
extensions, the resulting G UIDO data can still be processed by other applications
that support G UIDO but are not aware of the custom extensions, which are grace-
fully ignored. This design also greatly facilitates the incremental implementation
of G UIDO support in music software, which can speed up the software development
process significantly, especially for research software and prototypes.

1
In the following, the terms G UIDO Music Notation and G UIDO are used in parallel. Both terms
describe the format as well as specific files. It will be clear from the context, what is meant.

7
8 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

G UIDO has not been developed with a particular type of application in mind but to
provide an adequate2 representation formalism for score-level music over a broad
range of applications. The application areas include notation software, composi-
tional and analytical systems and tools, musical databases, performance systems,
and music on the web.
This chapter introduces the most important musical features of G UIDO Music Nota-
tion and then compares G UIDO to other music representation languages, namely the
MIDI File Format, DARMS, MuseData, SCORE, Common Music Notation, Plaine
and Easie Code, MusiXTEX, LilyPond, NIFF, SMDL, and XML-based representa-
tions.

2.1 Basic G UIDO Music Notation

Generally, G UIDO Music Notation is designed to adequately represent musical ma-

terial, which can then be interpreted by computer music software and also be used
for conventional music notation. The Basic G UIDO layer covers the relevant aspects
for representing “simple” music, from primitive musical objects such as single notes
or rests, to complete pieces with multiple voices, dynamics and other markings, as
well as text. There is no inherent restriction on the length or complexity of pieces
specified in Basic G UIDO (although applications supporting G UIDO might impose
such restrictions). Rather, the limits of Basic G UIDO lie in the features it allows
to express — focusing on basic musical concepts; it does not cover, e.g., the exact
placement and graphical appearance of musical objects (which can be specified in
the next layer, Advanced G UIDO). The advantage of this layered concept is the
ability to adjust the level of encoding to the applications need. Only if exact score
formatting information is really needed, this information can be encoded.
In general, G UIDO Music Notation is based on two basic syntactic elements: events
and tags. An event is a musical entity which has a duration3 (e.g. notes and rests)
whereas tags are used to define musical attributes (such as e.g. a meter, a clef, a key,
or a slur). Figure 2.1 shows a simple example of Basic G UIDO containing a single
voice with some musical markup and a couple of notes.

2
The notion of adequateness is a major design criteria of G UIDO. Synonyms for the term “ade-
quate” are: decent, acceptable, all right, common, satisfactory, sufficient, unexceptionable, unexcep-
tional, unimpeachable, unobjectionable. From Merriam-Webster’s Collegiate Dictionary: adequate
means “sufficient for a specific requirement”. G UIDO is an adequate representation format, because
simple musical concepts can be represented in a simple way; only complex musical notions may
require more complex representations.
3
Please note that the specified duration may be zero; an event with duration zero can be helpful
in exact score formating, as will be shown in later chapters.
2.1. BASIC GUIDO MUSIC NOTATION 9

# # 4 ——
— EÚ ——— . j
—— —— —— ——EÛ— EÚ– ——— . j
—— —— ——
[ \clef<"treble"> \key<"D"> \meter<"4/4"> & 4 EÛ –– =‹ XÛ=====
====== XÛ XÛ XÛ ‹ ==== –– ‹ XÛ==== XÛ XÛ XÛ=‹
a1*1/2 b a/4. g/8 f#/4 g a/2 b a/4. g/8 f#/4 g
# # —— —— XÚ–– XÚ–– EÚ–
a/2 a b c#2/4 d c#/2 b1 a/1 ] EÚ EÚ––
& =EÛ====
== EÛ =
‹ ––– =====– – = ‹ –– ==== – ‹ w===
= =\

Figure 2.1: A simple Basic G UIDO example

2.1.1 Notes and Rests

In G UIDO, notes are represented by their names (eg. c, d, e, do, re, mi, : : :) fol-
lowed by optional additional parameters: accidentals, register and duration (includ-
ing dots). By leaving out these parameters, incompletely specified music can be
represented in G UIDO. A complete note description in G UIDO has the following
form: “c#1*1/4.” which specifies the dotted quarter note c-sharp in the first octave
(just above the middle C).4 Note that register and duration information is carried
over from one note to the next within note sequences. This carry feature can also
be found in other music representation formats, which are described later in this
chapter.
As G UIDO has been developed for a broad range of musical applications, different
systems of diatonic note names are supported. Different types of note names may
be mixed freely in a G UIDO description: “do” and “c” are equivalent, the same is
true for “si”, “h” and “b”.5 In addition to the well-known pitch classes, G UIDO also
provides chromatic pitch-classes: There is, for example, a pitch-class called cis that
is different from c# and d& (where the # denotes a sharp, the & denotes a flat), even
though when played on a regular MIDI device all sound just the same. This concept
is important to cover aspects of 12-tone-music, where twelve distinguished pitch
classes of equivalent importance are used.
Rests are represented like notes; instead of a note name, an underscore is used:
‘ *1/4’ is a quarter rest; alternatively, the special note name ’rest’ can be used.
Obviously, rests don’t have accidentals or register information; rest durations are
specified as for notes. There is another “special” rest, which is denoted with the
note name ’empty’. An ’empty’ rest is not represented graphically in the score; it
is used to represent music, where voices appear and disappear visually. This is an
important feature, especially for exact formatting of scores.

2.1.2 Sequences and segments

G UIDO provides two orthogonal constructs for grouping notes and rests into larger
4
The * between the register and the duration is needed to distinguish between register and dura-
tion information. If no * appears after the note, the first number is interpreted as the register.
5
The “h” is the German name for “b”; the name “b” in German stands for b-flat. This is the reason
why the composer J. S. Bach can compose his last name as music: the equivalent G UIDO description
is [ b& a c h ], which could also be written as [ h& a c h ].
10 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

structures: sequences and segments. A sequence describes a series of temporally

consecutive musical objects, whereas a segment describes a number of simultaneous
musical objects. The most simple form of a segment is a chord where the separate
voices consist of single notes.
Sequences and segments are realized in G UIDO using the following syntax: A se-
quence begins with a square bracket ’[’ and ends with the corresponding closing
bracket ’]’. Segments are enclosed in curly braces ’f : : : g’. Musical objects within
segments are separated by commas. Within sequences and chords, octaves and du-
rations are implied from the previous note, if they are not explicitly specified.
G UIDO’s two grouping constructs have not only been chosen for reasons of formal
simplicity and elegance, they are also motivated by the fact that essentially most
musical pieces can be represented in two fundamentally different ways: As a se-
quence of chords (chord-normalform) or as a set of simultaneous voices (poly-normal
form). In the former case, the music is described as a sequence of chords (which is a
sequence of segments), while in the latter case it is represented by a set of sequences
(a segment of sequences). The usage of either one of these normalforms for the de-
scription of a piece depends heavily on the style of the piece: homophonic choral mu-
sic can often very naturally be written in chord-normalform, whereas a fugue is typ-
ically more adequately described using poly-normalform. Basic G UIDO facilitates
both normalforms by supporting an extended poly-normalform which allows chords
within sequences of a segment (i.e. chords within polyphonic voices). Figure 2.2
shows, how a musical fragment6 can be represented in G UIDO using either multi-
ple voices (which is poly-normalform) or using a single voice with chords (which is
chord-normalform). One detail needs to be pointed out: in the poly-normalform of
Figure 2.2 there are two eighth-notes in the second bar of the third voice, which
are omitted in the chord-normalform. The reason for that is that in a G UIDO chord,
all notes must have the same duration.7 Therefore, the two eighth-notes can not
be put in a chord together with single quarter-notes. Extended G UIDO allows more
complex nestings of sequence and segment constructors (see Sec. 2.3).
The graphical scores of Figure 2.2 are provided to visually describe the difference
between the two normalforms; it is important to understand that poly-normalform
does not require each voice to be placed on an individual staff-line. G UIDO offers
simple mechanisms to place the individual voices on one common staff-line. Some-
times the choice between poly- or chord-normalform is difficult; in many cases, poly-
normalform offers more freedom when exact score formatting is required.

6
These are the first three bars from the Bach Choral “Wie wunderbarlich” from the St. Matthew
Passion.
7
It is possible to write [ f c*1/4, e/8, g/16 g ]. The G UIDO specification deals with this, as
if [ f c*1/4, e/4, g/4 g ] had been written: the longest note of a chord determines the chord
duration.
2.1. BASIC GUIDO MUSIC NOTATION 11

##
c XÚ–– XÚ XÚ–– # ——XÛ ——XÛ— XÚ–– XÚ–– XÚ––– XÚ–– XÚ– XÚ–– UXÚ–
‹ ––– ===== – ‹ –– === – –– =\
{ [ % soprano
\clef<"treble"> \key<"b"> \meter<"C"> =====
& – = – =
‹ – ======
–
b1*1/4 | b b a# f# h c#2 d d e d \fermata( c# ) ],
## U
[ % alto
c ——XÛ ——XÛ # ——XÛ ——XÛ— —— — ——XÛ— ——XÛ— XÚ–– XÚ–– XÚ– # ——XÛ
–
\clef<"treble"> \key<"b"> \meter<"C">
a1*1/4 | g g# f# c# b0 f#1 f# b c#2 h1 \fermata( a# ) ] ,
=====
& =
‹ ===== _XÛ— =‹ _—XÛ====== – ‹ – === – =\
# # c XÚ–– Ú
X — Ú
X Ú
X Ú
X Ú
X
– Ú
X
– Ú
X
– UXÚ–
– XÚ–– XÚ– # —XÛ –– –– XÚ–– ––– –– – –– ––
[ % tenor
– =‹ –– ===== – –– ‹ – ======
– – ‹ – ===
\clef<"g2-8"> \key<"b"> \meter<"C">
f#1*1/4 | e d c# a#0 e1 e d/8 e f#/4 g f# \fermata( f#) ] , =====
& = =\
[ % bass
Ú
X Ú
X Ú
X U
# c # XÚ– XÚ # XÚ–– XÚ–– XÚ–– # XÚ––– # XÚ–– ––– –– # XÚ–– –– XÚ–
\clef<"bass"> \key<"b"> \meter<"C">

‹ ––– =====
? # – – ––
===== –– = – – – = ‹ ====== ‹ – === =\
d#0*1/4 | e e# f# f# g# a# b b a# b \fermata( f# ) ] }

[ \clef<"treble"> \key<"b"> \meter<"C">

——X— —— U——
{ d#0*1/4, f#1*1/4, a, b } |
# # —— — —
c —XX—X —X—X— # ———XX # ——XX— ——X— ——X— ——X— ——X— ——XX—
{ e0,e1, g, b } { e#0, d1, g#, b }
X— XX— X—X
‹ _X——====
{ f#0, c#1, f#, a# } { f#0, a#, c#1, f# }
=====
& _ —— ‹ _X—=====
_ — X _ —
X _ —
X ‹ _—X—X=====
= _ —X—X _X—X— _X—— = X— X—— \
Û
X Û
X XÛ _—XÛ _
{ g#0, e1, b0, b1 } { a#0, e1, f#, c#2 }
{ b0, d1, f#, d2 } { b0, f#1, b, d2 } _ _ — _ — _
_XÛ— _XÛ #_XÛ _XÛ _XÛ
#_ — _ X
— #_ —
Û
X #_ Û
X #_ _
_—XÛ
{ a#0, g1, c#2, e} { b0, f#1, b, d2}
\fermata( { f#0, f#1, a#, c#2 } ) ]

Figure 2.2: Poly- and chord-normalform of a Bach fragment

2.1.3 Tags and basic musical concepts

Written and played music does not only consist of notes and rests but also con-
tains additional musical and graphical information. G UIDO can represent all the
commonly known musical attributes by using tags. A tag has a name, optional pa-
rameters, and an optional range of application. A multitude of tags are defined in
Basic G UIDO; for a complete description see [HH96]. Just to name a few, there are
tags to describe clefs, meter, tempo, intensity, crescendo, accelerando, slurs, and
more. The semantics of the tags defined in G UIDO can normally be inferred easily
from their names. The example in Figure 2.1 illustrates the usage of tags in Basic
G UIDO. Please note that the example contains no formatting information. It is up
to the notation program to make good assumptions on standard formatting issues.
Syntactically, tags begin with a backslash followed by the name. Parameters are
defined within pointed brackets (’<’ and ’>’); multiple arguments are separated by
commas. If the tag has a range of application (for example a slur beginning at one
note and ending at some later note), this is specified by round brackets (’(’ and ’)’).
Figure 2.3 shows another example of Basic G UIDO. Here, tags are used to specify
the clef, the meter and some slurs. All additional formatting information, like for ex-
ample the beams, or the spacing and line breaking are automatically inferred from
the original G UIDO description as they are not explicitly defined. Some additional
points concerning tags should be noted:

 Usually, a number of different commonly used musical expressions can be used

as parameter values for tags to produce the same result: this can be seen by
looking at the nclef- and nkey-tag of Figure 2.3. The term nclef<"treble">
and nclef<"violino"> both produce a treble clef. Another acceptable pa-
rameter value for the treble clef would be “g2”.8 The nkey-tag both accepts a
8
“g2” stands for a g-clef on the second line from the bottom. nclef<"f4"> is an f-clef on the fourth
 12

b c XÚ–– . XÚ–– XÚ– ——EÛ ——

============
& – –J –– XÚ––
– ‹
= ======== EÛ =‹
{ — —— —— ———X ———X ——
[ % voice 1
b c —X—XÛ
============
&
——
X
—
XÛ —
X
Û
X X
—
Û
X = —
Û
X ——
Û
X —
Û
X
‹ ======== —X—XÛ =‹
\clef<"treble"> \key<"F"> \meter<"C">
\slur(do2/4. re/8) do/4 si&1 \bar a/2 g \bar c — —— XÚ ——
\sl(f/4 g/8 a) h&/4 a \bar g/2 _ | a/4 c2 ============
? b —EÛ . XÛ =
‹ –– ========XÚ–– –XÚ–
– XÛ =‹
–
d c | f/2 \slurBegin e/4 d \slurEnd |
c \sl( b&1/8 a ) h&/4 c2 | a1/2. _/4 ], ——
b ——XÛ ———XÛ ——XÛ XÚ–– XÛ ——
===========
& – =
‹ —EÛ=========‹
[ % voice 2
\clef<"violino"> \key<-1> \meter<"C"> b —— —— —— — —j
{a1/4,f} {g,e} {a,f} {h&,g} | {c2,a1} f1
———X
===========
& X—XÛ _——ÛXX _—X—XÛ _—X—XÛ —XÛ = .
‹ _——XÛ========
——XÛ _——XÛ _——XÛ— =‹
{g1,c2} {h&1,e1} | {a,f} {g/8,c/8} {f,c}
{c/4,e/4} {d,f} c/4. d/8 c/4 h&0 f1 e
XÚ XÚX–
b –
XÚ– XÚ– XÚ–– ––X– XÚ . XÚ–– XÚ–
d/8 e f g {f/4,a/4} {f1,d2} {f1,c2} ===========
? – – – –– ‹ –– ========
= –J – –XÚ– XÚ–– =‹
–
{f1,h&1} {f,a}{e1,c2}{d1,f1,h&1}{e,g}
{f/2.,a/2.} _/4 ], — EÚ––
b —— XÚ–– XÚ––
–
XÚ–– –XÚ–
–
XÚ––
–
============
& XÛ – – ‹ – ========
= ‹
[ % voice 3 — —
\clef<"basso"> \key<-1> \meter<"C"> b ——XÛ —— —
——
—
X
—X—
—
—X—
—
——
g-1/2. c0/4 f d e c d e/8 f ============
& —
XÛ — ——— ——XÛ ———XÛ
XÛ XÛ = Û
X
‹ ======== Û
X Û
X X—XÛ
‹
{ g/4 , h&/4 } { f , a } e/4. f/8 e/4 d/8 _XÚ–– XÚ– _XÚ––X _X–– X
Ú
e { f/4, a } { f0 , c1 } b
X–XÚ–
–
X–
–
XÚ– .
– –XÚ– –XÚX–
– X
–
– – –
f0/4. e/8 { d/4, a } {d,h&} {a0,c1}
============
? ‹ – ========
–J = – ‹
{h&0,d1} c1/2 g0/4 c f c f _ ]

Figure 2.3: Another example of Basic G UIDO

} XÚ XÚ–– XÚ– XÚ–– XÚ–– —— .
============
& b ––– – – – – ‹ —EÛ======== ¥ =\
—— ——X ——
b ——X—XÛ
============
&
X——
—
XÛ —
—
X
———X
— ¥
XÛ XÛ ‹ E.—E.Û======== =\
_EÚ––
b – XÚ––
–
———XÛ XÚ– ———XÛ XÚ–– ¥
============
? ‹ –– ======== – =\
CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT
2.2. ADVANCED GUIDO NOTATION 13

number (-1) or a string “F” to produce the same key-signature (F-major, one
flat).

 Abbreviations for tag names exists: the nslur-tag can be also specified as nsl.
The same is true for a variety of tags (nbm for nbeam, ni for nintens, and many
more). For a complete set of tag-names and their abbreviations, see [HH96].

 Range tags (like the nslur-tag in the example) can be specified either by using
round brackets or by using begin- and end-pairs. One of the slurs in the exam-
ple of Figure 2.3 is specified using a nslurBegin- and a nslurEnd-tag. Using
this mechanism, it is possible to allow a simple form of overlapping ranges.
This feature is enhanced in Advanced G UIDO (see section 2.2.1).

 If a time signature has been set by using the nmeter-tag, no bar lines have to
be encoded explicitly. Bar lines can be set explicitly to denote an up-beat. The
nbar-tag is equivalent to the use of “j” (using the nbar-tag it is also possible to
explicitly set bar numbers).

2.2 Advanced G UIDO Notation

Advanced G UIDO Notation comprises some of the more advanced concepts not cov-
ered in Basic G UIDO Notation, such as glissandos, arpeggios, clusters, different
types of noteheads, different types of staves, and many features from contemporary
music notation. It also addresses the issue of advanced score formatting such as ex-
act spacing and positioning of notational and graphical elements. Using Advanced
G UIDO, it is possible to specify exact score-formatting information that can be used
by any kind of professional notation software, which supports G UIDO import. This
feature makes Advanced G UIDO an ideal candidate for a platform-and application-
independent notation interchange format as was also shown in [HHR99].

2.2.1 Syntax extensions in Advanced G UIDO

Advanced G UIDO is based on the same syntax as Basic G UIDO with three slight
extensions: named tag parameters, parameter values with units, and multiple over-
lapping tag ranges.

Named tag parameters

In Advanced G UIDO, tag parameters can be specified by using predefined names.
An example for this is nclef<type="g2",size=0.5>, which specifies a g-clef on
the second line (i.e., a treble clef) whose size is only 50% of the standard size. Note
line, which is equivalent to a standard bass clef, which could also be written as nclef<"bass">.
14 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

that parameter names are optional and can be omitted, as long as all required pa-
rameters are specified. Using parameter names not only increases the readability
of Advanced G UIDO sources (which is beneficial for implementing G UIDO support),
it also makes it possible to only partially specify parameters, and to assume default
values for unspecified optional parameters.

Parameter values with units

Advanced G UIDO allows different measurement units to be used with tag parame-
ters. These units, such as cm, mm, in (inches), pt (points), hs (halfspaces)9 , and pc
(picas) can be optionally used with the numerical values of sizing and positioning
tag parameters by specifying the unit type directly after the value. As an example,
consider the tag npageFormat<20cm,40cm>, which defines the width and height of
a page to be 20cm and 40cm respectively.

Multiple overlapping tag ranges

Basic G UIDO already supports overlapping tag ranges by using pairs of begin- and
end-tags, such as in nslur(c1/2 ncrescBegin e/8 d) g/4 ncrescEnd. This
mechanism, however, does not handle the (rather rare) cases of multiple occurrences
of the same tag with overlapping ranges. To support the most general case of ar-
bitrary multiple overlapping tag ranges, Advanced G UIDO supports explicit disam-
biguation for begin- and end-tags. For every tag nid which can be used with a range,
the tagged range nid<: : :>( : : : ) can be alternately represented as nidBegin<: : :>
: : : nidEnd. Both the nidBegin and nidEnd tags are used without ranges, and the
nidBegin tag takes the same parameters as the original tag nid. To allow multiple
overlapping tag ranges, the tags can be extended with a unique numeric postfix us-
ing the syntax nidBegin:n<: : :> : : : nidEnd:n. Thus, three overlapping slurs can
be represented as shown in Figure 2.4.

—— XÚ–– —— XÚ––
[ \slurBegin:1 g0*1/4 \slurBegin:2 f1
XÛ – XÛ –
====================
& _ _ =\
\slurBegin:3 g2 a0 \slurEnd:1 g1 _XÚ–– _XÚ––
\slurEnd:2 f2 \slurEnd:3 ] – –

Figure 2.4: Multiple overlapping slurs

2.2.2 Exact formatting and score layout

Advanced G UIDO allows to completely specify the formatting and layout of scores.
This is realized by defining some additional tags and adding a large number of new
9
One halfspace is defined as the vertical distance between two adjacent notes, e.g. between c
and d.
2.2. ADVANCED GUIDO NOTATION 15

tag parameters to existing Basic G UIDO tags, which control the physical dimensions
of score pages, the position and size of systems and staves, as well as the exact
location of all graphical elements associated with staves. While notes, rests, most
notational symbols, and text are typically associated with staves, Advanced G UIDO
also supports graphical and text elements like, e.g., a title, which can be placed at
specific locations on the page independent from staves.
While the full set of mechanisms and corresponding tags for completely specifying
score layout and formatting cannot be presented here in detail, some main concepts
are highlighted while others are outlined rather briefly. A small set of tags is used
to specify the physical dimension and margins of score pages (npageFormat), the
relative positioning of systems on a page (nsystemFormat), type and size of staves
in a system (nstaffFormat) and their relative location (nstaff), page and sys-
tem breaks (nnewPage, nnewSystem), etc. Spacing and layout are based on graph-
ical reference points, which Advanced G UIDO specifies for each notational element.
Some elements (such as systems, or composer and title information) are positioned
relative to the page, others are relative to the staves or notes they are logically
associated with.
Generally, for elements associated with a staff, vertical offsets are usually specified
relative to the size of the staff, using the relative unit halfspace (hs). Likewise,
the size of many elements, such as notes or clefs, is always specified relative to the
size of the staff. The most important mechanism for exactly specifying horizontal
locations is the nspace tag. Placed between two notational elements, e.g., two notes,
it overrides any automatic spacing and forces the given amount of horizontal space
to separate the horizontal reference positions of the elements.
Advanced G UIDO includes all tags defined in Basic G UIDO, but allows exact posi-
tioning and layout information to be specified using additional optional parameters.
For instance, it is possible to exactly define the slope of a slur, or to change the size
or type of a notehead, whenever this is needed. While automatically created Ad-
vanced G UIDO descriptions10 will usually include complete layout and formatting
information, in many cases this information is only partially specified. In this case,
an application reading such a G UIDO description will try to infer unspecified in-
formation automatically where needed. This is the major goal of the presented the-
sis: Converting an “under-specified” G UIDO description into an acceptable graphical
score; the required steps for this conversion process are examined in the following
chapters.
If specific information is not required or supported by an application, it can easily
be ignored when interpreting the G UIDO input. Note that this approach allows the
adequate representation of scores: only when exact formatting information is really
needed, the corresponding additional tags and parameters have to be supplied.
10
Because Advanced G UIDO can be used as a notation interchange format, completely formatted
scores can be saved as a complete Advanced G UIDO description by notation programs supporting
G UIDO.
 % The first page of a BACH Sinfonia, BWV 789
% Most of the element-positions are specified 16
% using Advanced GUIDO tags. The layout has
% been very closely copied from the URTEXT
% edition by the Henle-Verlag.
% This example has been prepared to show, that
% Advanced GUIDO is capable of exact score- SINFONIA 3
% formatting.
%
BWV 789
{ [ % general stuff 5
4 1 3
3 2 2
\pageFormat<"a4",lm=0.8cm,tm=4.75cm,bm=0.1cm,rm=1.1cm> ——— — —— —— —— —— —— —— —— —— 5
2
\title<"SINFONIA 3",pageformat="42",textformat="lc",dx=-2cm,dy=0.5cm> # # c a X——Û XÛ— _XÛ— n X———Û X———Û X——Û X——Û XÛ—— X———Û ——— ——XÛ— X——Û X——Û ——— ———— X——Û X——Û X——Û— X———Û _XÛ_XÛ— XÛ— X——Û X——Û X——Û— ——XÛ X——Û X—Û X——Û # XÛ— _XÛ— XÚ– XÚ– X—Ú–Û–
— —
\composer<"BWV 789",dy=1.35cm,fsize=10pt> &
========= X Û
=‹ ======= XÛ XÛ — =‹ ======== a –– –– – nXÚ–– ‹
‹ ‹ 2 ‹
_ X
Ú
–
_ _X
Ú
% indent of 1.05 cm for the first system.
XÚ–– ‹ ––– ––– XÚ–– XÚ–– # XÚ– XÚ–– XÚ–– _XÚ––– _XÚ–––– _XÚ––– XÚ–– ‹
\systemFormat<dx=1.05cm> ?
## c –
=========
a X–Ú–– XÚ–– a XÚ–– ‹‹‹ X–Ú–– a XÚ– XÚ––– XÚ–– XÚ––––
XÚ ‹
‹ X
Ú
– – – – – – – – ‹
3 1
« J 3
J– ======== J– 2
–– ––– =– ========‹ 1

% voice 1 5
3 2
45 1 5
45
1 1 2 1 3
— — — — — # X—Û _E—Û
\staff<1,dy=0.85cm> % next staff is 0.85 cm below
# # X—Û
X
Ú X
Ú
–
– XÚ–– X—Ú–Û–– XÚ X—Û XÚ– XÚ–– X—Ú–Û—– X—Û— XX—Ú–Û– XX—ÚÛ–– XX—Û—Ú– # XX—Û—Ú– XÚ–––– XÚ––– XÚ––– XÚ–– XÚ–– XÚ– XÚ–– XÚ–– XÚ– XÚ–– XÚ––
\staffFormat<style="5-line",size=0.9375mm> &
==============
– ‹ XÚ–=========== =‹
2
– XÚ–– – – – XÚ– = ‹ – –– –– – – – – – – – – – – – – – ‹
% barlines go through whole system _
X
Ú ‹
\barFormat<style="system"> # X
Ú
– # X
Ú X Ú
– X Ú
– –
– X
Ú
– n X
Ú
– X
Ú X
Ú X
Ú
– X
Ú
– X
Ú
– n X
Ú —
— — — — — — n X
Ú
% measure 1 (voice 1)
# – X–Ú – – – – – – –– XÚ–– X–Ú– –– –– –– –– –– ‹ X–Ú– XÚ– XÛ — — — X—Û XÛ— XÚ–– X–Ú– –– XÚ–– ‹‹
? # – – – –
============== 1
– – – –
1
= ‹ – =========== – 1 2 3
– – – = – ‹
4 3
\clef<"treble"> \key<"D"> \meter<"C"> \stemsUp
« _X—Û— XÛ— XÛ
\restFormat<posy=-1hs> _/8 \beam( \fingering<text="3", 2 1 5 4
3 5 4
— — — — — — 4 3
dy=8hs,dx=-0.6hs,fsize=7pt>(f#2/16) g) 5
\beam( \stemsUp<5hs> a/8
# # _XX—ÛÚ– ——XÛ— X——Û X——Û X—Û— X—Û X—Û— X——Û # X——Û ——— X——Û— X——Û X——Û X—Û— ——XÛ n X——Û X—Û— —— —— X—Û— X——Û X——Û X——Û X——Û— ——
–
– X XÚ–
\fingering<text="2",dx=1hs,dy=11.5hs,fsize=7pt>( &
============== Ú–– XÚ–– XÛ = XÛ XÛ XÚ– XXÛÚ– XÚ–– XÚ– XÚ– XX—ÛÚ XÚ––– XÚ––– =
12
– – XÚ–– ‹ XÚ–– ===========
‹ –
–
\stemsUp<8hs> c ) )
–– –– –– –– ––– ––– –– ––– ‹‹
\beam( \stemsUp h1 e2/16 f#)
‹ — — —— —— —— —— —— —— —— XÚ– XÚ XÚ ‹
\beam( \stemsUp<5hs> g/8 \stemsUp<8.5hs> h1 \stemsUp) \bar
# # XÚ–– XÚ–– XÚ–– X–Ú–– XÚ––– n XÚ– XÚ XÚ–– XÚ–– X–Ú–– XÚ ‹ — X—Û XÛ— XÛ — — XÛ XÛ— X—Û XÚ– ––– ––– ––– ‹
============== ‹ X—Û=========== X—Û X—Û – ‹
% measure 2 (voice 1)
« ? – – – – –– ––– –– – –– ––– = –– –– – =
\beam( a1/8 d2/16 e) \beam( f#/8 a1)
\beam( \stemsUp<12hs> g/16 3 — — — — — —
\stemsUp \fingering<text="4",fsize=7pt,dy=9hs,dx=-0.2hs>(f#2) e # # X—Û —— X——Û— .
—
X Ú X
Û X
Ú X
Ú XX—ÛÚ– X—Û— X——Û ——— X——Û X—Û— X——Û X——Û— # X——Û— X—Û X———Û XÚ XX—ÛÚ– . XÚ XÚ– XX—ÚÛ– X——Û— X——Û— X——Û X—Û— X——Û— X——Û— X—Û— X—Û
\stemsUp<8hs> d \stemsUp) –
==============X
Ú Ú
X – # X
Ú – X
Û = XÚ –
– – – – – – XÚ–
‹ XÚ–– =========== – – =‹
\beam( \stemsUp<12hs> c# \stemsUp
& –– ––– XÚ–– –– –– –– –– –– EÚ––
– ‹ – – – – – – – — ‹
\fingering<text="5",fsize=7pt,dy=9hs>(h) a ‹ —— ‹
. X Ú
–
– X
Ú X
Ú
– XÛ ‹
\stemsUp<8hs> g \stemsUp ) \bar
# # X–Ú– XÚ–– XÚ– XÚ–– X–Ú– XÚ–– X–Ú– # X–Ú– X–Ú–– XÚ–– X–Ú–– ‹ n X–Ú– X–Ú– XÚ–– X–Ú– X–Ú– X–Ú– X–Ú–– ––– – X–Ú–– X–Ú–
==============
? – – –– – – – – – – – = – – – – –
‹ – =========== =‹
% measure 3 (voice 1)
\beam( \stemsUp<5.5hs> f#2/16 \stemsUp e
«
\fingering<text="2",fsize=7pt,dy=10hs>( d ) — — — —
\stemsUp<5.5hs> e \stemsUp)
# # XÚ–– XÚ–– XÚ– XÚ–– XÚ–– XÚ– XÚ– XÚ–– —— X——Û X——Û X—Û— ———— ———— X—Û— X——Û X——Û # XÚ– XÚ–––– XÚ––– XÚ–––
\beam( \stemsUp<6hs> f# \stemsUp ==============
& – – –– – ––– n XÚ–– # X–Ú–– –– ––– –– n X–Ú–– = ‹ X—Û=========== XÛ XÛ— – – – = – ‹
\fingering<text="1",fsize=7pt,dy=11hs>(e)
‹ —— —— ‹‹
\fingering<text="3",fsize=7pt,dy=11hs>(f#)
—— —— —— _——XÛ _X——Û— __X——Û _X——Û— _X———Û —— —— —— —— _X———Û _X——Û— _X———Û —— ‹‹ —— —— —— —— —— —— —— _X——Û _X——Û— _
XÛ XÛ _XÛ X—Û— ‹
\stemsUp<6.5hs> g# \stemsUp)
XXÛÚ– # X—Û # XÛ— XÛ XÛ ‹ # XÛ— X—Û # X—Û XÛ— XÛ ‹
# # XEÛÚ–– # XÛ— XÛ – XÚ–– XÚ–– @ X
Ú
– XÚ––
\stemsUp<4.75hs> a/4 \stemsUp – – ‹ – XÚ–– XÚ––– n XÚ––– –
?
============== – =– =========== – – =‹
\slurBegin <dx1=2hs,dy1=3hs,dx2=0hs,dy2=2hs,h=2hs>
\fingering<text="5",fsize=7pt,dy=6hs>( \stemsUp<4.5hs> e/4 )
« — —
\bar \newSystem<dy=4cm> # # XÚ– XÚ XÚ XÚ– XÚ– XÚ– XÚ– —— —— —— —— X——Û
% measure 4 (voice 1)
X——Û X———Û # X———Û X——Û— X——Û XÚ X—Û ———— X———Û X——Û X——Û—
============== – X Ú _XÚ ‹
\staff<1,dy=0.98cm>
& –– ––– ––– –– ––– XÚ––– –– ––– # X—Û— # X—Û XÛ— XÛ # X–Ú–– XÚ––– n XÚ–– =
‹ # XÚ–– =========== XÚ–– –– ––– n XÚ–– _XÚ–– # XÛ
— – ‹ – – – – – _XÚ–– n XÚ––– n XÚ––– =
e/4 \slurEnd ‹
—X—Û —— —— — —— — – – ––– ‹‹
\tie<dy1=2.4hs,dx2=-1hs,dy2=2.4hs,h=1.75hs>( # n XÛ # XÛ— X—Û XÛ— XÛ— ‹ XÚ– # XÚ– XÚ # XÚ XÚ XÚ
\fingering<text="4 5",dy=8hs,fsize=7pt>( \stemsUp<5hs> d) d ) ‹
============== XÚ–– XÚ–– = XÚ–– =========== XÚ–– ‹‹

Figure 2.5: Advanced G UIDO example: Bach Sinfonia, BWV 789

? # EÚ––– – – –
XÚ–– –––– –––– –––– –––– XÚ––– # XÚ––– –––– –––– XÚ––– =
– – ––
\tieBegin<dy1=2hs,dy2=2hs,dx2=0hs>
......
«
CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT
2.3. EXTENDED GUIDO 17

Figure 2.5 shows an example illustrating Advanced G UIDO’s exact formatting fea-
tures. The G UIDO code includes page, system, and staff formatting as well as accu-
rate formatting of slurs. Stem length and directions, beam groupings, and ties are
also specified precisely. The complete G UIDO description for the page can be found
in Appendix 6.

2.2.3 Advanced notational features

Advanced G UIDO also supports “advanced” notational features, such as glissandos,
arpeggios, clusters, or figured bass indications, as well as less commonly used bar-
line types, clefs, rehearsal marks, etc.
Not all of these advanced musical concepts have standardized representations in
conventional music notation; this leaves notation software supporting G UIDO some
freedom in dealing with them.
While, due to the restricted space, we cannot discuss advanced notational elements
in detail here, the example in Figure 2.6 illustrates some of them. Note, for in-
stance, the nstaffFormat tag in the first voice, which not only defines the staff to
have three lines, but also reduces its size (compare to corresponding size-parameter
in third voice). Note also the use of a percussion clef (nclef<"perc">) in staves
1 and 2. As can bee seen in the first voice, nested tuplets can be described in a
straightforward way using ntuplet tags with nested ranges; nested beams are rep-
resented analogously. Voice 3 shows the usage of the nglissando tag, which allows
not only the style but also the exact offsets from the reference positions to be spec-
ified. Furthermore, the second voice demonstrates the use of the nstaffOff and
nstaffOn tag, to prevent sections of the staff from being shown.

2.3 Extended G UIDO

Extended G UIDO includes various features, which enhance Basic and Advanced
G UIDO beyond conventional music notation. The work on Extended G UIDO is not
yet finished: as different user groups currently experiment with using G UIDO in
different application contexts, the final version of Extended G UIDO will reflect the
needs and experiences of these user groups. Some issues have been discussed by the
“core” G UIDO developing group; these will be presented shortly in the following.

2.3.1 Microtonality and Tuning

While certain aspects of microtonality can already be realized in Basic G UIDO, such
as the differences between d##, e, or f&, Extended G UIDO also introduces repre-
sentations for other types of microtonal information, such that different notions of
microtonality, such as just tuning, microtonal alterations, arbitrary scales, or non-
standard tuning systems can be adequately represented.[ARW98] For example, us-
18 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

∞
¬ 3 +2 ¥ a X X X X XX X X X >X a X £ X >X X X >
Perc 1 8 X X
p ƒ §:∞
¶ ∞
Perc 2 X X XXX X X X
L ƒ
> > > >
'
>
XX___X^
#_X
~~~~ # _
_
3+ 2 ~~~~~
~~ ~ ~ ~ ~ _J
~~~~
~~~~~
& 8 _jX ~~~~gliss.
~~~~~

Piano p '
38+2 XJ ~~~~gliss.
~~~~~
~~~~~
~~~~~
? ~~~~~
~~~~ __j __
# #___XXX__XX
~~~~~
~~

{[ (* voice 1*) ... \systemFormat<staves="1-4",dx=0>

\accol<id=0,range="1-2",style="straightBrace"> ...
\staff<id=1,dy=2.5cm> \barFormat<style="staff">
\staffFormat<style="3-line",size=0.875mm> ...
\clef<"perc"> ... \meter<sig="3+2/8"> ... \dottedBar<2>
... \tuplet<format="-6:5-",dy1=-14.3hs,dy2=-10.3hs>(
\beam<dy1=-10hs,dy2=-6hs>(g*5/48 \grace<16,"/">(e g) ...
\tuplet<format="-3-",dy1=4hs,dy2=6hs>(\beam(g*5/144 c e))
... ) ) \barFormat<"accolade"> \bar ... ],
[ (* voice 2, system and staff-layout-tags removed *) ...
\staffOff \empty*5/8 \staffOn \clef<"perc"> \space<2.5mm>
\bar ... ], [ (* voice 3, some layout-tags removed *)
\accol<id=2,range="3-4",style="curlyBrace">
\barFormat<style="accolade">
\staffFormat<style="standard",size=1.125mm> ...
\glissando<style="wavy",dx1=2mm,dy1=1.5hs,
dx2=-0.7mm,dy2=0hs>( c1*1/8 \space<7mm>
\text<"gliss."> empty*4/8 \bar<2> \space<6mm>
\stemsDown \marcato( { \headsRight(g3*1/8),
f#, \headsRight(e), d# } ) )
\staffOff ], [ (* voice 4 *) ... ] }

Figure 2.6: Another Advanced G UIDO example

2.4. GUIDO AS A MUSIC REPRESENTATION LANGUAGE 19

ing the nalter-tag, microtonal alteration of standard pitch classes, such as quarter-
tone accidentals can be realized; nalter<-0.5>(a1/8) represents an eighth note
a1 altered downwards by a quarter tone. Likewise, different tuning systems can be
represented by two other new tags, ntuning and ntuningMap, which are used to
select predefined tuning systems, such as just tuning, or to specify a tuning scheme
based on systematic alterations of given pitch classes. Finally, concepts such as
quarter-tone scales or absolute pitches can be represented by parameterized events,
which generalize the concept of an event (such as a note or rest) in Basic or Ad-
vanced G UIDO.

2.3.2 Exact Timing

In Basic and Advanced G UIDO, note and rest durations are always specified as rel-
ative durations. Extended G UIDO also allows exact timing by specifying absolute
durations: c#2*2500ms represents the note c#2 with a duration of exactly 2500
milliseconds. Absolute and relative durations can be freely combined in a given
fragment or piece. This can be extremely challenging for a notation system, because
the traditional spacing11 and horizontal synchronization of multiple voices may get
very complicated.

2.3.3 Hierarchical and Abstract Scores

Extended G UIDO facilitates the direct representation of hierarchical score structures
by allowing arbitrary nesting of the sequence and segment constructs used in Ba-
sic and Advanced G UIDO (see section 2.1.2). A simple example for this is shown in
Figure 2.7; note that while there is no standard graphical representation of such
hierarchical scores, they can be extremely useful in analytical applications. Sim-
ilarly, Extended G UIDO supports the representation of abstract scores, which are
basically scores containing variable or “holes”. These can be useful for representing
incomplete structural information such as musical schemata.

2.4 G UIDO as a Music Representation Language

Experience has shown that G UIDO is a powerful and versatile music representa-
tion language. In most cases, a given graphical score can be converted fairly easily
into a suitable G UIDO description. The opposite – generating a conventional score
from an arbitrary G UIDO description – is sometimes more complicated (especially, if
the G UIDO description was algorithmically “composed”) but it will be shown in the
following chapters, how acceptable scores can be generated in most cases.
11
Spacing is the process of deciding how much space is put after a note or rest. Section 4.5.1
thoroughly covers this issue.
20 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

[ c2/8 d b1 e2 c e b1 d2 { [ c2/8 d b1 e2 c e b1 d2 ],
c2/8 e b1 d2 c d b1 e2 ] } c2/8 d b1 e2 c e b1 d2 ]

Figure 2.7: Hierarchical scores in Extended G UIDO

Using G UIDO as a music representation language offers some advantages over other
representation languages, which will be described in the following sections. Never-
theless, one issue concerning the grouping structure of G UIDO has to be mentioned:
When using several sequences to construct a piece (the piece is encoded in poly-
normalform; see section 2.1.2), synchronous events appear at different locations
in the description. This is a common problem for many music representation lan-
guages, especially if they are human readable. The issue is problematic, because
these G UIDO descriptions can not be used for streaming purposes, where a client
receives a stream of musical information from a server. In a streaming-scenario,
the receiving party must (in the worst case) already have received the complete
G UIDO description before it can (dis-)play the score or the music. To overcome this
disadvantage, a mechanism is needed, which converts poly-normalform descriptions
into chord-normalform G UIDO descriptions. Currently, one design issue in the Basic
and Advanced G UIDO specification prohibits this: as was already mentioned in sec-
tion 2.1.2, a chord is a collection of single events, which all have the same duration.
There are many instances, where this restriction is too tight. One such instance
can be seen in Figure 2.2 on page 11: the tenor voice contains two eighth notes in
the second bar; these are omitted in the chord-normalform. To create a streamable
G UIDO description, an extended chord-normalform must be defined, which allows
chords to contain simple sequences instead of only notes. The details of this still
need to be specified exactly.
Another issue, which is closely related to the streaming of G UIDO descriptions, is the
question of editing complex G UIDO descriptions: in a complex piece containing mul-
tiple voices, a single musical time position is present up to n times (where n is the
number of sequences). Therefore, changing the musical content at one time position
may require editing the G UIDO description at n different positions in the file. This
is a common problem that can be found with other representation formats aswell;
the only solution for a text based format would be the usage of a two-dimensional
spreadsheet which would basically look like a two-dimensional, textual representa-
tion of the graphical score. While this approach may solve the problems concerned
with editing, it requires somewhat complex formatting even for simple pieces. To
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 21

overcome the issue in the case of G UIDO, a specialized G UIDO editor needs to be cre-
ated, which is aware of different voices and keeps track of mapping time positions
to individual voice positions.

2.5 Other Music Representation Languages

Quite a number of different music representation formats have been developed and
used ever since computers have been used for music information processing. Some
of these representations were built with graphical scores in mind, others are rather
performance oriented while still others target the needs of musical analysis. When
comparing G UIDO to other music representation formalisms, several similarities
and differences can be found: Unlike the MIDI File Format [HwDCF+ 97] or NIFF
[Gra97], G UIDO is a plain-text, human-readable format. This facilitates the re-
alization of G UIDO support for music software and has considerable advantages
for using G UIDO to interchange musical data between applications or across plat-
forms and over the Internet. Compared to other plain-text approaches like DARMS
[SF97b], SMDL [SN97], or music representations based on XML [CGR01], G UIDO
shows improved representational adequacy (in the sense defined on page 7) which
again facilitates its usage and implementation. Finally, in contrast to representa-
tions which are specifically designed for graphic music notation, like Common Music
Notation (cmn) [Sch97], the G UIDO design is focused on musical information, while
also supporting exact score formatting features.
The rest of this section compares G UIDO with several other widely used music rep-
resentation formalisms. For an even more detailed description of musical codes the
reader might consult “Beyond MIDI – The Handbook of Musical Codes” [SF97a],
which offers a thorough and detailed overview of the most important music repre-
sentation formalisms in use today.

2.5.1 MIDI
MIDI (Musical Instrument Digital Interface) was originally developed as a proto-
col for the communication of digital musical instruments (primarily synthesizers).
Therefore, MIDI has a strong bias towards piano keyboards and mainly records
keyboard events (keys being pressed and released) together with other control pa-
rameters. The MIDI file format [HwDCF+ 97] offers the means to store this proto-
col information in a file. In order to be an efficient streamable format, MIDI data
is transmitted and stored as a stream of bytes which is not directly human read-
able.12 MIDI is strongly performance oriented and was never intended to be used
as a general music representation language. The usage of MIDI for the interchange
12
Different MIDI formats exists; when using format 1, different tracks are placed sequentially in
a file, therefore format 1 MIDI files are not suitable for streaming.
22 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

of musical data is therefore somewhat limited: “Standard MIDI Files have the dis-
advantage that they represent relatively few attributes of music” [SF97a], page 24.
Standard MIDI files cannot, for example, distinguish between D# and Eb , because
these notes are realized by pressing the same key on a piano keyboard. There is
also no mechanism for explicitly representing rests within MIDI files. Several ex-
tensions to MIDI have been suggested to overcome the various limitations of MIDI
for a general musical and notational information interchange.13 So far, none of the
extensions have been widely accepted, therefore, the basic problems remain.
Regardless of the shortcomings of MIDI as a music interchange language, millions
of MIDI files exists today. Almost every computer music application supports MIDI
either for importing or exporting musical data in a commonly understood format.
MIDI is one of the most used music file formats in the realms of score level repre-
sentation. Everything that can be represented in a MIDI file can also be represented
within a G UIDO description. Because G UIDO allows arbitrary event durations, there
is no loss of information when directly converting MIDI into G UIDO.14 This does
not hold for the inverse: in most cases, information is lost when converting from
G UIDO to MIDI. The reason for this lies in the fact that much of the musical infor-
mation contained in a G UIDO description simply cannot be explicitly represented
using MIDI (e.g. slurs, articulation, etc.).
The complexity of converting MIDI files into graphical scores very much depends
on the recorded MIDI data: if the notes are quantized (which means, that all note
onsets and durations are put into a predefined set of allowed timepositions), and
the separation of simultaneous voices into several tracks has been carried out, then
a conventional score can be created quite easily. Of course many issues and tasks
remain, for example deciding which voice to print in which staff for a piano score.
Another dissertation dealing with many of the complex problems of this domain is
currently being written by Jürgen Kilian and will be published within the next year
[Kil02].
The inverse process (producing MIDI files from G UIDO descriptions) is a straight-
forward process that has been implemented in [Fri00]. As stated above, most of the
explicit musical markup is lost, although it is used for creating a musical “sensi-
ble” performance (for example, a nslur-Tag in the G UIDO description changes the
played duration of the notes in the MIDI file, resulting in a legato playback).
Conclusion The MIDI file format is widely used for representing score level music
but has significant drawbacks when being used as a notation interchange format.
Because of the different underlying ideas, a direct comparison of MIDI and G UIDO
does not yield interesting results. All information present in a MIDI file can be
represented in G UIDO, which does not hold for the inverse.

13
See pages 73–108 in [SF97a].
14
A direct conversion from (unquantized) MIDI into G UIDO without any “intelligent” processing
does generally not produce usable information (at least for music notation purposes).
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 23

2.5.2 DARMS
DARMS stands for Digital Alternate Representation of Musical Scores [SF97b]. Its
development started as early as 1963 and it is still used as a music (and mainly
score) representation language today, although currently no “modern” application
for reading or writing DARMS exists. Because DARMS was developed to allow com-
plete scores to be coded with a generic computer keyboard, the resulting code is
human readable.15 A multitude of DARMS dialects exist, all specified for special ex-
tensions (like for example lute tabulature). All dialects are closely related to the so
called Canonical DARMS, which was first described in 1976. The term “canonical”
was thoughtfully chosen, meaning that the encoding of single elements of a score is
unambiguous: there is only one way of encoding notes, rests etc.
One major difference between DARMS and G UIDO lies in the fact that in DARMS,
pitch is represented by a number which encodes a position on a staff (which depends
on the current clef) rather then being represented explictly like in G UIDO. The
note “e” in the first octave would be represented by “1” if a treble clef was used, by
“7” for an alto clef, and by “13” for a bass clef, because the position on the staff-
line changes. Figure 2.8 shows the G UIDO and DARMS coding of a small musical
fragment together with the matching graphical score.

_
_XÚ–––
DARMS (1): !G 1Q !C 7Q !F 13Q

XÚ––
DARMS (2): !G 1Q !C 7 !F 13
——
GUIDO (1): [ \clef<"treble"> e1/4 \clef<"alto"> e \clef<"bass"> e ]
& XÛ B –
========= ?
GUIDO (2): [ \clef<"g"> e1/4 \clef<"c"> e \clef<"f"> e ]

Figure 2.8: DARMS and G UIDO

One important similarity between DARMS and G UIDO is the carry feature: In
DARMS, the duration or the pitch of a note is carried to the following note. This
feature is used in the second DARMS encoding (denoted DARMS (2)) of the previ-
ous example (Figure 2.8): the duration (here a quarter note) is kept for all following
notes. If the pitch stays the same and the duration is changing, it suffices to encode
the new duration without repeating the pitch (which is actually just the line num-
ber for the current staff). If neither the duration nor the pitch changes, either pitch
or duration can be used for encoding the repeating note.
In G UIDO, the carry feature does not work for pitch information, as pitch informa-
tion is explicit for every note. The carry feature works the for duration and for the
register (the octave); this makes hand coding of musical examples fairly fast.
In DARMS, so called push codes indicate non-printing rests: a similar feature is
available in G UIDO. Here, the non-printing rests are called “empty” and behave
15
In order to save memory and to optimize performance, DARMS uses single characters to encode
musical information; K stands for key signature, G and F are the treble and bass clef. Even though
the resulting code is human readable, the reader must know the meaning of the single characters in
order to understand the encoded music.
24 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

just like normal events without being visible in the final score.
The concept of grouping several elements horizontally by using a comma (“,”) and
whitespace (“ ”) for vertical placement is similar in DARMS and G UIDO.16
DARMS and G UIDO both encode music by storing several voices (called “parts” in
DARMS and “sequences” in G UIDO) sequentially, which are then stacked horizon-
tally.
One rather advanced feature of DARMS called “linear decomposition” allows to en-
code complex parts of a score by offering multiple parses, which is equivalent to
“going backwards” in time. This feature is not directly available in G UIDO, but as
G UIDO descriptions have no limitation on the contained number of voices, “linear
decomposition” can be simulated easily by adding voices containing “empty” events
together with notes and rests, which encode the relevant area of the score. Fig-
ure 2.9 shows a short fragment where linear decomposition (which is encoded in
DARMS using “!& : : : & : : : $&”) is used for the last three notes. The equivalent
G UIDO description is also shown: here, two voices are required.
DARMS:

— —— — —
!I1 !G -1QU 2QU !& 3EU( 2EU) / 2HU //

& _——XÛ —XÛ —XÛXÚ– _—XÛXÚ– =‹ _—EÛEÚ–=

=====
& 0ED( -1ED) / -1HD // $&

GUIDO:
–– –– ––
{ [ \staff<1> \clef<"g2"> \stemsUp c1/4 e \beam( f/8 e ) | e/2 ] ,
[ \staff<1> \stemsDown empty/2 \beam( d/8 c ) | c/2 ] }

Figure 2.9: Example for linear decomposition in DARMS

Conclusion DARMS is a very well thought of encoding scheme for music notation –
especially considering that it was created in the 1960’s. Because of the compressed
nature of the encoding format, DARMS looks rather cryptic and can not be under-
stood intuitively. Also, encoding pitch information by positions on staff-lines does
not offer an advantage over explicitly encoding pitch information for each note. All
information from a DARMS description can be encoded in G UIDO.

2.5.3 MuseData
The MuseData format has been developed by Walter B. Hewlett since 1982 at the
Center for the Computer Assisted Research in the Humanities (CCARH) [Hew97].
It is strongly focused on encoding logical aspects of musical information, meaning
that MuseData represents what could be thought of essential musical information
that in terms can be (re-)used for analytical and notational purposes. Up to now,
many classical works (by J. S. Bach, Beethoven and many others) have been encoded
as MuseData files. Some of the encoded works have also been published as scores
16
In order to allow an arbitrary amount of whitespace in the case of horizontal groupings (e.g.
chords), G UIDO additionally uses curly and straight braces (“f,g,[,]”).
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 25

which are sold commercially. One interesting aspect of MuseData is, that – similar
to G UIDO – the encoded information does not need to be complete in the sense, that
exact formatting information for notational elements needs not to be encoded; so
called print suggestions can be used to guide notation programs in producing exactly
formatted scores from a MuseData file.
MuseData files are text-based, human-readable files. Different from many other
text based representation languages, the formatting within the file is an integral
part of the represented music: each line is treated as a record, containing either
header information (like the title and composer of a piece) or musical information.
The musical attributes record contain attributes which usually pertain throughout
the file (key signatures, time signatures, clef signs, etc.). So called “Data Records”
encode musical information (such as notes, rests, etc.) by using different predefined
letters and numbers placed at specific column-positions. This encoding makes it
easy to find a specific location within a MuseData file, but additional overhead is
required to ensure the correct encoding of a piece.
Figure 2.10 shows an example MuseData encoding together with the matching
G UIDO description and the respective score. The header information is omitted
in the MuseData encoding in order to concentrate on the representation of musi-
cal parameters. The first line encodes the key signature (2 sharps), the division
per quarter note (4), the time signature (0/0), and the clef signs for the first and
the second staff (4 is a treble clef, 22 is the bass clef). In the following lines, the
notes and rests are encoded. A very powerful feature within MuseData is the “back”
command, which is used to “rewind” the time. This is used in the example to print
two simultaneous voices within the same part. This feature is similar to the “lin-
ear decomposition” feature of DARMS. The note names in the MuseData example
can be easily identified (“D4”, “G3”, etc.). In MuseData the (musical) duration of
a note or rest does not necessarily have to match the notated duration; this is an
important feature for a complete music representation language, because it allows
the representation of uncommon durations without producing an unreadable score.
A detailed description of the column-oriented formatting features of MuseData can
be found in [Hew97]. For a comparison of MuseData and G UIDO it suffices to know
that MuseData offers a large variety of formatting instructions commonly used in
conventional scores.
While there are quite some similarities between G UIDO and MuseData, the most
important difference is the restrictive formatting of MuseData files. While this may
have an advantage when navigating within a MuseData file, it results in quite an
amount of overhead when producing the files. Because MuseData and G UIDO were
both created as complete music representation languages, they share the notion
of encoding musical content rather than music notation. Both formats offer exact
formatting features, which may be ignored by applications. The “back” feature of
MuseData has no equivalent in G UIDO. This feature can be simulated quite easily
in G UIDO, as was shown in Figure 2.9. As the MuseData file format is very well
documented and a large number of MuseData files exist, a converting application
26 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

(a) MuseData Encoding (b) G UIDO Encoding

$ K:2 Q:4 T:0/0 C1:4 C2:22 {
rest 16 2 1 [ % voice 1, measure 1
back 16 \staff<1> \clef<"g2"> \key<2> _*16/16 |
rest 2 3 e 2 % voice 1, measure 2
D4 2 3 e d2 [ _*1/2 _*1/8 \beamBegin \stemsUp a1 a a \beamEnd ],
D4 2 3 e d2 = [ % voice 2, measure 1
D4 2 3 e d2 ] \staff<2> \clef<"f4"> \key<2> _*1/8 \beamBegin
G3 4 3 q d2 \stemsDown d1 d d \beamEnd g0*1/4 \tieBegin:1 b |
B3 4- 3 q d2 - % voice 2, measure 2
measure 2 \beamBegin b*1/8 \tieEnd:1 e a g \beamEnd f#*1/4 d ]
rest 8 2 h 1 }
rest 2 2 e 1
A4 2 2 e u1 [
A4 2 2 e u1 =
A4 2 2 e u1 ]
back 16
B3 2 3 e d2 [ ## a ——XÛ ——XÛ ——XÛ
===========
& ‹ ========= =\

«
E3 2 3 e d2 =

_XÚ– _XÚ– _XÚ–

A3 2 3 e d2 =
# # a – – – XÚ–– XÚ– XÚ– XÚ
– –XÚ–– ––– XÚ–––– XÚ–––
G3 2 3 e d2 ]
– – XÚ––
F#3
D3
4
4
3
3
q
q
d2
d2
===========
? ‹ – ========= – – =\
/END

Figure 2.10: Example for MuseData encoding

from MuseData to G UIDO was realized [Fri01].

Conclusion MuseData is a human readable, measure oriented, complete music
representation language. MuseData is capable of encoding all aspects of music
found in conventional scores. The encoding follows a restrictive line- and column-
oriented formalism, which simplifies navigation within the file, but cannot be under-
stood intuitively. A large number of scores encoded as MuseData files exist, which
can be automatically converted into G UIDO descriptions. In comparison to Muse-
Data, G UIDO offers a more flexible way to encode musical information.

2.5.4 SCORE
SCORE is a commercial music notation system available for DOS and Windows. It
has been developed since the 1980s by Leland Smith [Smi97]. Input to SCORE is
encoded as an ASCII file, which contains a description of notes, time position and
musical markup (like articulation and slurs).17
SCORE has been created with high quality publishing of musical scores in mind;
it is therefore very strongly graphically oriented: one input file always describes
exactly one page of a score. Many formatting decisions are made automatically by
SCORE, but it is also possible to specify the exact location of all graphical elements
through the use of parameter files. It is even possible to include arbitrary postscript
17
In the following, the term SCORE will be used to describe both the input file format and the
notation system. It will be clear from the context, what is meant.
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 27

symbols and files in a score, making it an ideal tool for contemporary music publish-
ing.
Because SCORE is so much concentrated on the visual aspects of a score, the file for-
mat itself is not very useful as a general music representation language, although
logical information for a piece can be extracted. Nevertheless, SCORE is a very suc-
cessful notation program used by many publishers for high quality musical typeset-
ting. The notation algorithms implemented in SCORE are among the finest avail-
able and include automatic formatting of various parts of a score. Unfortunately,
the developer has not published anything on the implemented algorithms, therefore
a direct comparison to other published notation algorithms can not be done.
Even though SCORE input files are ASCII files, they follow a somewhat non-in-
tuitive approach by first specifying the pitch of all notes, followed by the respective
durations, followed by articulations and finally ending with the description of beams
and slurs.18
Conversion from SCORE to G UIDO would probably be possible; at least the basic
data (like pitch, octave, most articulations, beaming and slurs) could be easily con-
verted to their respective G UIDO descriptions. From [Smi97] (p. 279): “[SCOREs]
strongly graphical nature produces occasional obstacles to analysis. For example,
the differentiation of ties and slurs [: : :] must be inferred from other information.”

2.5.5 Common Music Notation (cmn)

Common Music Notation (cmn) by Bill Schottstaedt [Sch97] is being described as
“a simple little hack that can create and display traditional western music scores”
on its web page [Sch98]. It actually is more than that: it is a primarily graphi-
cally oriented, lisp-based system that creates postscript files from a given textual
description, which is actually a LISP expression (resulting in quite a large num-
ber of brackets, although in many cases the brackets may be omitted). It can be
read and understood intuitively due to its use of common musical names like e.g.
“treble” for a treble clef or “double-bar”. cmn is very flexible: all output can be ex-
actly formatted where needed (it is, for example, possible to change the beam-width
and beam-spacing with simple commands). Because cmn creates postscript output,
everything can be easily scaled, rotated, and moved arbitrarily on the page.
A score is encoded in cmn as a series of systems, which contain staves, which con-
tain lists of notes, rests, and other musical objects. It is possible, to attach a list of
notes to an already existing staff; this technique is somewhat similar to the linear
decomposition mode in DARMS. It is also possible to reset the “musical time”, effec-
tively going backwards in time to place more then one voice on the same staff; this
is very similar to the “back” command in MuseData.
cmn can be used to encode most conventional and even modern scores. It also allows
18
Slurs and ties are treated alike in SCORE; this alone disqualifies the usage of SCORE as a
general music representation language.
28 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

the integration of user defined graphics, although a profound knowledge of LISP is

required to actually program new graphical output.
Figure 2.11 shows a short example of a cmn encoding together with the respective
G UIDO description and the matching score. Differing from G UIDO, cmn does not
offer a carry feature: each note requires an explicit pitch- and duration information.
The “duration” is only interpreted as a visual parameter and there is no encoding of
“musical” duration, as in MuseData or in G UIDO.

Common Music Notation (cmn):

_XÚ––
_
(cmn treble e4 q alto e4 q bass e4 q )
—— XÚ–– –
G UIDO description:
& —XÛ B –
========= ?
[ \clef<"treble"> e1/4 \clef<"alto"> e \clef<"bass"> e ]

Figure 2.11: Example of Common Music Notation (cmn)

Conclusion cmn is a graphical oriented score representation language. Because

cmn encodings are LISP expressions, the representation comes close to the “de-
scription being the program”-paradigm: the score is the result of evaluating the
expression. Because of its graphical nature, cmn is not suited as a general music
representation language. A conversion of cmn descriptions into G UIDO descriptions
seems possible, although such a conversion should be realized using LISP. The same
structural problems as mentioned when discussing the conversion of SCORE into
G UIDO will apply.

2.5.6 Plaine and Easie Code

The development of the Plaine and Easie Code by Barry S. Brook and Murray Gould
was driven by the same idea as the DARMS code: musical notation should be rep-
resentable by using ordinary typewriter symbols. Plaine and Easie Code was devel-
oped for the use in bibliographic applications, for example to classify and retrieve
musical themes and fragments in musical databases [How97]. The code was de-
veloped to represent melodies in conventional staff notation: therefore it primarily
deals with a single voice. Some extensions to the Plaine and Easie Code have been
proposed to also represent multiple voices [Gie01]. The Plaine and Easie Code uses
ASCII characters to represent pitch class and duration. The code can be best un-
derstood by looking at the example in Figure 2.12: first, the f clef on the fourth line
is denoted by “F-4”. Then follows the key signature (f# and c# ) denoted by “xFC”.
The time signature is simply encoded as “4/4”. Then follows an eighths-note rest
“8-” and a beam group of three D’s in the first octave (indicated by the high-comma)
encoded as “f ’D D D g”. Because the Plaine and Easie Code is oriented solely on
the notational elements visible in the score, it is not very useful as a general mu-
sic representation language: as can be seen in Figure 2.12, all notes are encoded
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 29

without accidentals, because no accidentals – besides the key signature – are visi-
ble. The encoding is not concerned with the sounding pitch, but stores the visible
pitch, ignoring the accidentals. When a melody needs to be written with another key
signature, all following notes must be updated to reflect the change. This greatly
differs from G UIDO and other formats, where the sounding pitch is encoded.

Plaine and Easie Code:

F-4 xFC 4/4 8- {’D D D} 4,G B+ / {8B E A G} 4F D
_XÚ– _XÚ– _XÚ– XÚ–– XÚ––
G UIDO description: # 4 a –– –– –– XÚ–– –
XÚ
– XÚ––– –––– XÚ–––– XÚ––– XÚ––
? #4
============ – ‹ – ======== – – =\
[ \clef<"f4"> \key<2> \meter<"4/4"> _*1/8
\beam( d1 d d ) g0*1/4 \tieBegin b |
\beam( b*1/8 \tieEnd e a g ) f#*1/4 d ]

Figure 2.12: Plaine and Easie Code

Conclusion Plaine and Easie Code is a compact notation representation formalism

that is not suitable as a general music representation language. The format pro-
duces very compact descriptions of melodies, but focuses exclusively on the visible
elements of a score. Despite the graphical nature of the format, exact formatting
information can not be encoded. A conversion from Plaine and Easie Code to G UIDO
could be realized quickly, because the supported notational elements are present in
both formats.

2.5.7 MusiXTEX
MusiXTEX [TME99] is part of a whole family of TEX based music typesetting sys-
tems. It is a set of TEX macros to typeset orchestral scores and polyphonic music. It
does not decide on esthetic problems in music typesetting, therefore the process of
“coding MusiXTEX might appear to be (: : :) awfully complicated (: : :)”.19 The manual
states right at the beginning: “If you are not familiar with TEX at all I would rec-
ommend to find another software package to do musical typesetting.” It is therefore
not intended to be easily used by the average computer user. Nevertheless, being
a non-commercial open-source development, MusiXTEX could be used as the under-
lying framework for a user friendly notation system, although this requires a lot of
work.
The basic idea of MusiXTEX is to describe a score as a textual description, which is
then converted into a graphical score. As indicated above, MusiXTEX does not make
formatting decisions: it is up to the user to provide the system with parameters for
every little formatting detail (for example the slope of a beam). Because of its graph-
ical nature, MusiXTEX contains a very large number of musical symbols but it is not
very useful as a general music representation format. Because MusiXTEX is based
on (plain) TEX, a score description encoded in MusiXTEX can be created and read
19
Citation taken from the MusiXTEX manual [TME99]
30 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

by humans only with intensive training. Therefore, a number of input languages

exists that are then converted into MusiXTEX descriptions using converters.
Figure 2.13 shows an example MusiXTEX encoding. For a detailed description of the
commands and their parameters, please refer to [TME99].
\begin{music}
\instrumentnumber{1}
\setname1{Piano}
\setstaffs1{2}
\gerenalmeter{\meterfrac44}
4 EÚ– XÚ–– XÚ––
– . XÚ–– XÚ–– EÚ––
\startextract
& 4 ––
========== – ‹ XÚ––– ========
= – – – ‹

«
\Notes\ibu0f0\qb0{cge}\tbu0\qb0g|\hl j\en Piano
‹‹ ‹‹
\Notes\ibu0f0\qb0{cge}\tbu0\qb0g|\ql l\sk\ql n\en 4 —— —— —— —— —— —— —— —— ‹‹ —— —— —— —— —— —— —— —— ‹‹
\bar & 4 _—XÛ XÛ XÛ— XÛ _—XÛ XÛ XÛ— XÛ =
========== XÛ XÛ XÛ — XÛ XÛ— XÛ ‹
‹ —XÛ======== _XÛ
\Notes\ibu0f0\qb0{dgf}|\qlp i\en
\notes\tbu0\qb0g|\ibbl1j3\qb1j\tbl1\qb1k\en
\Notes\ibu0f0\qb0{cge}\tbu0\qb0g|\hl j\en
\end{extract}
\end{music}

Figure 2.13: Example for MusiXTEX

Conclusion MusiXTEX is not meant to be a simple score description language;

it is a complex formatting language for musical scores based on TEX. Because a
MusiXTEX description already contains all formatting information, different input
languages to MusiXTEX exists. Therefore, it seems possible that complete Advanced
G UIDO descriptions can be converted into MusiXTEX files, which are then used to
render a score.

2.5.8 LilyPond
GNU LilyPond20 [NN01, MNN99] is another musical typesetting system based on
TEX. Differing from MusiXTEX, LilyPond does make formatting decisions. The
whole LilyPond system works very similar to the G UIDO Notation Engine:21 a text
file is converted into an internal score representation, which contains the exact lo-
cation of each notational element that together constitute the graphical score. Lily-
Pond uses TEX for the actual typesetting, whereas the G UIDO Notation Engine uses
the so called G UIDO Graphics Stream to describe which elements to put where.
Even though the name LilyPond encompasses the whole system for typesetting mu-
sic, the name is also used to describe the input format.22 In the following, it should
be clear from the context, whether the complete system or just the input file format
is meant.
20
LilyPond is distributed under the GNU Public License [GNU]; in the following, the term LilyPond
will be used as a synonym for GNU LilyPond
21
The G UIDO Notation Engine and the G UIDO Graphics Stream is described in detail in chapter 5.
22
In earlier versions of the LilyPond documentation, the name Mudela (short for “Music Descrip-
tion Language”) was used as the name for the input format. This name seems no longer to be used
in current versions.
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 31

The encoding of musical data in LilyPond does not only address typesetting issues,
but also performance aspects of a musical score.23 A LilyPond description is human
readable plain text, which can be intuitively understood (as long as simple examples
are encoded) due to the use of commonly used musical names (for instance note
names like “c,d,e” etc., and instructions like “key”, “meter”, “time” and the like).
This feature of LilyPond is very similar to G UIDO. LilyPond differs from G UIDO as
it allows the usage of variables and the definition of functions, which can change
the default behavior of the notation system. These features make LilyPond more a
“programming language” than just a music representation formalism. This greatly
enhances the expressive power of the language, but it also makes it more difficult
to process or convert LilyPond to other formats.
As LilyPond clearly addresses users, who are comfortable with specifying their mu-
sical input as text, great care has been taken to make the encoding of music as
comfortable as possible: some nice features include a relative-mode for note-entry,
which is used to interpret the octave of a note with respect to the preceeding note
by taken the shortest interval – this eliminates the need to explicitly switch octaves
too often, a common source of encoding errors when using G UIDO.
The LilyPond system converts the input file into a TEX description, exactly specify-
ing, where each glyph24 has to be put on a page. It is left to TEX to actually create the
graphical output (either a DVI-file or a postscript output). In order to make musical
typesetting decisions, LilyPond accesses the font information available (the width
and height of individual glyphs). The used musical font – called feta – is distributed
freely with the system.
The LilyPond system can be extended by advanced users. Because the input is in-
terpreted and can contain complete functions (using Scheme, a functional program-
ming language similar to Lisp), the LilyPond system is a very versatile and powerful
notation system. One problem of LilyPond is its dependency on a variety of other
programs and tools: a complete installation of TEX, GUILE, Scheme, Python, etc.
is required to run LilyPond. The system setup is rather complicated and can not
usually be carried out by people, who have only interest in music. The targeted user
of LilyPond is the computer literate, probably already using TEX for typesetting. It
is not intended as a replacement of commercially available notation packages and it
does not offer any graphical frontend.
Finally, LilyPond is work in progress. It is constantly being enhanced, new features
are added. Being an open development, it will probably attract more programmers
and users in the near future.
Comparing the LilyPond input-format to G UIDO is not easy, because the intended
use is different. LilyPond strongly focuses on notational issues while G UIDO is
meant to be a general music representation language. By being extremely flexible,
23
At the time of this writing, the only performance aspect that can be manipulated is the tempo of
playback when converting a LilyPond file into a MIDI file.
24
A glyph is a single element of a font; most musical symbols are constructed by combining several
glyphs.
32 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

LilyPond can nevertheless be expanded to include additional musical information

that is not used solely for printing. The main drawback of using LilyPond as a gen-
eral music representation language stems from the fact, that the number of tools
needed to run the system is complicated to maintain. An integrated system, that
encapsulates the internal mechanism would make LilyPond a very powerful and
accessible music notation system.
Figure 2.14 shows an example of a very simple LilyPond entry compared to the same
example encoded in G UIDO.

LilyPond:
\score {
\notes {
\clef violin
e4
_
_XÚ–––
\clef alto
—— XÚ––
e4 & XÛ B –
========= ?
\clef bass
e4
}
\paper { }
}

GUIDO (1): [ \clef<"treble"> e1/4 \clef<"alto"> e \clef<"bass"> e ]

GUIDO (2): [ \clef<"g"> e1/4 \clef<"c"> e \clef<"f"> e ]

Figure 2.14: LilyPond and G UIDO

Conclusion LilyPond is a powerful music notation system based on TEX. Input to

LilyPond is human readable text, which can be intuitively understood, especially if
simple music is encoded. Because the main focus of LilyPond is music notation, its
use as a general music representation format is somewhat restricted. Conversion of
LilyPond into other formats is aggravated due to the fact that LilyPond encodings
may include variables and functions, which are first interpreted internally using
the functional programming language Scheme. LilyPond depends on many helper-
applications (TEX, Python, Scheme, Perl, etc.), therefore an installation of the no-
tation system is rather complicated. Nevertheless, LilyPond is a complete music
notation system, which creates nicely formatted scores.

2.5.9 NIFF
The Notation Interchange File Format (NIFF) [Gra97, Bel01] is a binary format
that was meant to be the notation interchange format used by the majority of com-
mercial and non-commercial music notation programs as a commonly agreed format
to exchange music notation. The specification of the format was completed in 1995.
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 33

NIFF is based on the Resource Interchange File Format (RIFF), a data structure
defined by Microsoft (and also used in WAV files, for example).
The developers of NIFF, among them the major software companies dealing with
music notation, envisioned a complete and universally usable description formal-
ism that would allow the description and interchange of a large variety of scores.
Therefore, the actual specification grew rather large, resulting in very few complete
implementations of the format. As major sponsors dropped their support, there is
currently no further development of the original format (see [Bel01]); the format
is nonetheless completely specified and can be used free of charge by anyone inter-
ested. A software development kit (SDK) is available for free, which allows reading
and writing of NIFF files [Bel01].
One major difference between NIFF and G UIDO lies in the fact that NIFF is a binary
format, which requires specialized software for reading and writing a file. Another
difference is the lack of adequacy in NIFF – to encode something like a simple scale,
the complete layout of the score has to be specified aswell. This makes an intuitive
use of NIFF almost impossible, which is not necessarily wrong by itself, as NIFF
was never intended to be an easy to use representation formalism. Nevertheless,
a direct comparison of G UIDO and NIFF is not a fruitful endeavor. However, the
NIFF developers have identified and addressed many of the commonly understood
problems of representing music notation. Their effort is a valuable resource for
others working in this field.

2.5.10 SGML based Music Representation Formats

Standard Generalized Markup Language (SGML) is an international documenta-

tion standard (ISO) that exists since the 1980s [SGM86]. The most known instance
of SGML is the Hypertext Markup Language (HTML) [W3C02], which is used for
most of the web pages found on the Internet. Because HTML covers almost no
document structuring issues, a simplified version of SGML called XML (eXtensible
Markup Language) has been developed [Eck00]. XML is currently gaining popular-
ity and it can be assumed that in the near future a huge proportion of the documents
available on the Internet will be written in XML.
Because of the rapid growth of the Internet, some effort has been spent to create
music description languages that use the underlying markup language. The first
development in this area was the Structured Music Description Language (SMDL)
[SN97], a not yet published ISO Standard [SMD95]. SMDL is based on SGML and
HyTime (another ISO Standard [HYT95]).
34 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

Structured Music Description Language (SMDL)

“SMDL can represent sound, notation in any graphical form, and processes of each
that can be described by any mathematical formula.”25 The design of SMDL is based
upon several domains: the logical domain which is also called “cantus” is used for
music representation, while the visual domain is responsible for graphical aspects,
like for instance one or several images of a score. Another domain, the “gestural
domain”, covers performance aspects of a piece. The general idea is to allow one
piece of music in the logical domain to have many score representations in the visual
domain and also different performances in the gestural domain. The most important
musical representation aspects occur in the logical domain. Pitch can be represented
either as frequency or by using names, which are associated with frequencies by
using a previously defined lookup table. Duration may be specified using either
real time or “virtual” time (which just means that the duration of events is defined
relative to each other; conventional scores use virtual time). The use of virtual time
is supported by HyTime, which is used to map the virtual time of an event to a real
duration based upon tempo information. Any articulation and dynamic information
can be encoded in SMDL.
The syntax of SMDL follows the well known syntax of SGML, which is similar to
the syntax of HTML. An important aspect of SMDL is the fact that the code was not
devised to be easily human-readable; it is supposed to be used as an interchange
format, which is read and written by computer programs. The overhead required
for representing even simple music prohibits to show an example here; a rather
large SMDL description can be found in [SN97]. One specific goal of SMDL is the
ability to represent any item found in any other music representation code.
SMDL has not been widely accepted by music software developers so far. One of
the reasons for that may be the fact that it is difficult for potential users and tool-
developers to see how SMDL might apply to their particular application. SMDL’s
stated goal to cover everything found in any other music representation code makes
the format very broad – a rather large overhead is required even when simple music
is represented.

XML based Music Representation

Because of its gaining popularity, XML based formats are being created in many
domains (such as mathematics, chemistry, and music). Recently, a couple of music
representation languages based on XML have been presented [CGR01]. XML by
itself is a meta-format, which mainly defines the syntax of the document. The se-
mantics of any XML document is defined by so called Document Type Definitions
(DTD’s). The main work for any developer of a music representation language is the
creation of a DTD.
25
[SN97], page 470
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 35

One major advantage of XML over other representation formalisms is the fact that a
growing number of software tools exist for validating and creating XML documents.
This does not solve any of the problems found when representing logical aspects of
music or when converting a (logical) music representation into a graphical score;
but it helps in the validating of the documents (the syntax and semantics of the
DTD can be checked without knowledge of the document domain).
At the time of this writing, a dozen different XML-based formats for music represen-
tation have been proposed, some of which are prototypical, others cover almost all
aspects required for general music representation. Because XML is a hierarchical
format, an XML developer has to define which elements of music can be described
by using hierarchies (for example one piece contains many voices, one voice con-
tains many measures, a measure contains chords, a chord contains notes, and so
on). One interesting feature of XML is a grouping construct based on identifiers. An
entity can be made part of group using this mechanism. Some XML-development
tools are able to validate these grouping mechanisms (for example to ensure that all
identifiers are unique). As an example consider the following:

<beam id= "beam1" .../>

<note beamRef= "beam1" .../>

where the beam has a unique identifier, which can be used by notes belonging to the
particular beam group.
As each XML-based music representation language defines a different DTD, there
is no general structure common to these encodings. One thing that is common to
all formalisms is the descriptive richness of the formats. For example, there is a
<note .../> construct in almost any XML-based format; this results in rather
long encodings even for simple pieces.
Because XML is a syntactic rather than a semantic formalism, the representation
of music has no ideal or natural match within XML. To demonstrate that XML per
se (as opposed to one distinct XML-based representation) has no advantage over
G UIDO, a DTD and converters for an XML-based music representation based on
G UIDO, called G UIDOXML, were developed. A G UIDO description can be simply
converted into the one-to-one corresponding G UIDOXML description and vice versa.
Figure 2.15 shows a G UIDO description and the matching G UIDOXML-code. Note,
that both descriptions of Figure 2.15 contain the same information. Because the
conversion in both directions is almost “trivial”, it can be argued that G UIDO itself
is a suitable XML-based music representation formalism.
XML-based music representation languages are still quite new; the future will show,
whether any one of the proposed formats will be accepted and used widely.

2.5.11 Commercial file formats

Most of the commonly used commercial music notation products (the two major
ones being Finale and Sibelius) have internal file formats that are generally not
36 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE guido SYSTEM "guido.dtd">
<guido>
<segment>
<sequence>
<clef s="&#x22;treble&#x22;"/>
<key s="&#x22;B&&#x22;"/>
<meter s="&#x22;3/4&#x22;"/>
<note name="h" octave="0" duration="1/4" accidentals="b"/>
<note name="c" octave="1" duration="1/4"/>
<note name="d" octave="1" duration="1/4"/>
{ [ \clef<"treble">
<note name="e" octave="1" duration="1/4" accidentals="b"/>
\key<"B&">
<note name="f" octave="1" duration="1/4"/>
\meter<"3/4">
<note name="g" octave="1" duration="1/4"/>
b&0/4 c1 d
<note name="a" octave="1" duration="1/4" accidentals="b"/>
e& f g
<note name="h" octave="1" duration="1/2" accidentals="b"/>
a& b&/2 ],
</sequence>
[ \clef<"bass">
<sequence>
\key<"D">
<clef s="&#x22;bass&#x22;"/>
\meter<"4/4">
<key s="&#x22;D&#x22;"/>
d0/8 e f# g
<meter s="&#x22;4/4&#x22;"/>
a h c#1 a0
<note name="d" octave="0" duration="1/8"/>
d1*5/4 ] }
<note name="e" octave="0" duration="1/8"/>
<note name="f" octave="0" duration="1/8" accidentals="#"/>
<note name="g" octave="0" duration="1/8"/>
<note name="a" octave="0" duration="1/8"/>
<note name="h" octave="0" duration="1/8"/>
<note name="c" octave="1" duration="1/8" accidentals="#"/>
<note name="a" octave="0" duration="1/8"/>
<note name="d" octave="1" duration="5/4"/>
</sequence>
</segment>
</guido>

Figure 2.15: G UIDOXML and matching G UIDO description

disclosed to the public and which quite frequently change whenever a new version
of the program is released.26 Finale offers a plugin-interface, which can be used
to extract musical information from a file, but this technique requires a running
version of the program (for which a purchased license is needed). The same holds for
Sibelius. Therefore, the process of converting the files directly requires some degree
of reverse engineering. Most available conversion programs,27 which either write or
read the commercial formats, rely on limited documentation of the file formats and
only extract partial information from the files.
Even though a large number of scores exists, which have been encoded in Finale or
Sibelius, these file formats can not be regarded as general music representation lan-
guages. As long as the underlying formats are not made publicly available, the data
contained within must first be converted into some “open” format before it can be
truly interchanged with other applications. Currently, the producers of commercial
notation software seem to have no interest in an open interchange format.
26
Finale does offer limited information on its format (called Enigma); the information is not com-
plete and changes with every new release.
27
For example, there exists a converter from Finale-files to LilyPond.
2.5. OTHER MUSIC REPRESENTATION LANGUAGES 37

2.5.12 Other representation formats

There are sill many other music representation formalisms found in [SF97a] and
elsewhere, which have not been mentioned in the previous sections. Some of these
formats are either binary formats which often can be read or written only using
certain applications, others focus more on music analysis (as, for example, Hum-
drum/Kern [Hur97]). We believe that the relevant formats, especially the ones con-
cerned primarily with music notation and interchange, have been covered.

2.5.13 Comparison chart

Table 2.1: Comparison chart of Music Representation Languages

Performance, Used as
Logical and/or Supports inter- Conver-
Notational exact for- change Intuitive Easily ex- tible to
Format representation matting format to read tensible G UIDO
MIDIa P no yesb no partially yesc
DARMS N no yes nod no yes
MuseData L&N yes yes nod no yes
SCORE N yes no no no yes
cmn N yes noe yes yes yese
PaE-Codef N no yes nod no yes
MusiXTEX N yes no no no nog
LilyPond Nh yes noi yes yes partiallyi
NIFFa N yes yes no no yes
SMDL L&N yes yes no yes partiallyk
XML L & Nl yesl yes yesl yes yesl
G UIDO L&N yes yes yes yes yes
a
Binary format
b
MIDI is the most used interchange format for score level music
c
Conversion may require additional processing to obtain readable scores
d
Dependent on training
e
cmn descriptions are LISP expressions and require a LISP interpreter
f
Plaine and Easie Code
g
MusiXTEX files contain little information on musical structure
h
If needed, the input file can be coded so that logical information is extractable
i
LilyPond files are first interpreted using a functional programming language (Scheme)
k
SMDL may transport more information than is commonly stored in a G UIDO descrip-
tion
l
Depends on the implemented DTD
Table 2.1 summarizes the properties of the different music representation languages
that where compared to G UIDO in the previous sections. Obviously the table does
not describe any of the properties in detail; it is merely useful as a rough guideline
38 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT

to sum up the features of the compared music representation languages concisely.

2.6 Conclusion
In this chapter, G UIDO Music Notation was described in detail and features and
examples for each of the three layers of G UIDO (Basic, Advanced, and Extended
G UIDO) were given. Then, other music representation languages were compared to
G UIDO and their respective advantages and disadvantages were elucidated. Each
one of the music representation formalisms, which were presented in this chapter,
has a distinct area of application – there is no general format that covers all conceiv-
able aspects of music representation and is easy to use at the same time. Because of
the different descriptional focus – some formalisms represent musical ideas better
than notational ones and vice versa – it is a matter of the task at hand, which music
representation language to use. Many of the above described formalisms concen-
trate strongly on the graphical appearance of a score (e.g. SCORE, MusiXTEX, and
others). These representations are definitely suited for a music notation system,
but they lack the power to completely represent the musical content of a piece. As
SMDL clarified, a score is just one possible view of a piece. Just as different editions
(or extractions) may exists, other views (like performance oriented views) may ex-
ist. Therefore, the focus on notational aspects alone is not sufficient for a general
music representation format. MuseData focuses on the logical domain of music rep-
resentation, while still being able to cover aspects of exact score-formatting. While
this approach is somewhat similiar to G UIDO, it has drawbacks because of the very
strict formatting rules. MuseData is not easily extensible, and it is also focused on
music from the classical and romantic period. Music without a regular measure
structure (either lacking a time signature or having different time signatures for
different voices) can not be easily encoded in MuseData. Nevertheless, MuseData is
a complete music representation formalism.
There are many reasons for choosing G UIDO as the underlying music representa-
tion language for a music notation system. First of all, G UIDO descriptions are easy
to create and parse. Secondly, the possibility to represent exact score-formatting
information within a G UIDO description is of great advantage – all algorithms of
the notation system can be described as G UIDO to G UIDO transformations. But,
as G UIDO is primarily describing musical content, the formatting aspect within a
G UIDO description is just additional information. The fundamental musical struc-
ture of a piece is always closely related to the structure of the G UIDO description.
Additionally, tools for removing all formatting information from a G UIDO descrip-
tion exist. Therefore, the essential musical information can be easily extracted.
Because G UIDO is such a flexible representation language, the conversion of arbi-
trary G UIDO descriptions into conventional scores can be complicated: just consider
non standard note durations being specified (like c*11/14), or a complex piece given
without exact formatting instructions. The algorithms required for converting such
2.6. CONCLUSION 39

G UIDO descriptions into acceptable conventional scores will be presented in the fol-
lowing chapters.
40 CHAPTER 2. THE GUIDO MUSIC NOTATION FORMAT
Chapter 3

A Computer Representation of
G UIDO Music Notation

Introduction
In chapter 2 it was shown that G UIDO is a powerful general music representation
language which is not only suitable for representing musical structure but encodes
notational aspects as well. As G UIDO is a text-based format, applications that
work on G UIDO descriptions require an internal storage format in order to effi-
ciently access the represented musical and notational data.1 This storage format
generally differs depending on the application – a music notation application has
other requirements than a musical analysis tool. In the context of music nota-
tion, great care must be taken when defining the internal representation: as will
be shown in the following chapters, music notation can be defined as transforma-
tions of under-specified G UIDO descriptions into well-defined G UIDO descriptions:
The under-specified G UIDO description does not contain complete score formatting
information, which is automatically added by the music notation system. These
transformations require a powerful internal representation, as many of the notation
algorithms will be carried out on this structural level. A well structured inner rep-
resentation of G UIDO is not only valuable in the context of music notation, but can
be used for a broad range of applications. It should be evident that all notationally
relevant information present in a G UIDO description is encoded in the implemented
inner representation.
The work presented here did not start from scratch. Other applications using
G UIDO have been developed before this thesis was written.2 Nevertheless, most
1
Storing G UIDO descriptions internally as textual representations requires continuous re-parsing
of the strings, which would be inefficient.
2
One major application certainly was the SALIERI-System [HKRH98]; this comprehensive com-
puter music system incorporates a musical programming language, whose musical data type is
closely related to G UIDO. As the definition of G UIDO became more complex, the development of
SALIERI stagnated; therefore the inner representation used in the SALIERI system can not repre-

41
42 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

of these applications are using a task-oriented inner representation that does not
cover all aspects of G UIDO. One common tool being used by almost every G UIDO
compliant application is the G UIDO Parser Kit [Hoo], which includes a complete
lex/yacc-generated parser3 for G UIDO. The G UIDO Parser Kit does not include an
inner representation for G UIDO; it merely offers a collection of hook-functions that
are called whenever a G UIDO-event or tag is recognized in the parsed string. It is
up to the user to build and fill an inner representation from these hooks.
The inner representation for G UIDO descriptions that was developed as part of this
thesis is called “Abstract Representation” (AR). This chapter deals with the object-
oriented design and the structure of the AR. It will further be shown that any G UIDO
description (and its corresponding AR) can be converted into a semantic normal
form; this normal form simplifies the structure of the AR and is also useful for clar-
ifying the semantics of a G UIDO description. In the following, the transformation
of G UIDO descriptions into the AR will be explained. Finally, the requirements and
methods for accessing and manipulating the AR are presented.

3.1 Defining the Abstract Representation (AR)

When an inner representation for G UIDO is defined, certain requirements must be
met. The most important aspect is, that for each G UIDO description there exists a
one-to-one corresponding instance of the inner representation. In this section, the
ideas and requirements that led to the creation of the Abstract Representation (AR)
are presented.

3.1.1 Document View Model

The idea of splitting the process of converting G UIDO descriptions into conventional
music notation into several layers was inspired by the document view model (dvm),
which was first introduced in Smalltalk and made popular in the Microsoft Foun-
dation Class library [msd02]. The dvm is an an abstract model that describes how
an application can encapsulate its data from the actual display and manipulation
of the data. Within the dvm, the document contains the data, which is displayed
and manipulated by different views. Retrieval and change of the data by its views
is done by using only strictly defined interface functions; this ensures that an alter-
ation of the data in one view is reflected immediately in all other views of the same
data. The separation of data and user-interface helps in focusing on the different
requirements for each part. As different users may have different preferences for
the display and manipulation of the data, different views can be implemented.
sent all of G UIDO.
3
Lex and yacc are tools for automatically generating parsers from grammars; the G UIDO Parser
Kit contains a complete grammar for G UIDO.
3.1. DEFINING THE ABSTRACT REPRESENTATION (AR) 43

As an example, consider a word processing application: the document is the ab-

stract internal representation of the collection of words, graphics and formatting
information that the user manipulates thru different views, which could either be a
WYSIWYG4 -view or a non-formatted textual representation of the document (as in
the case of a LATEX-document for example).
In the case of G UIDO Music Notation, the document is the Abstract Representa-
tion (AR) containing all information present in a G UIDO description; a view of this
AR can either be the conventional music notation (the creation of which will be
explained in chapter 4), or it can be a textual representation (which would be the
(textual) G UIDO description itself), or some other (graphical) interpretation (a hi-
erarchical display of a G UIDO score for example). Figure 3.1 shows the AR in the
context of the document view model.

Views
Conventional score:

Document
Textual representation:
[ \clef<"treble"> \key<"D">
Access− and \meter<"4/4"> a1*1/2 b a/4.
g/8 f#/4 g a/2 b a/4. g/8
Abstract Representation manipulation f#/4 g a/2 a b c#2/4 d c#/2
b1 a/1 ]
protocol

Other representation (XML):

one−to−one
correspondence

GUIDO description

Figure 3.1: The Abstract Representation in the Document View Model

The dvm was chosen as the model for the inner representation of G UIDO, because
this design pattern closely matches the structure of G UIDO descriptions with re-
spect to music notation: the musical information contained in a G UIDO description
do not necessarily represent a score. As will be shown in chapter 4, the process
of converting an arbitrary G UIDO description into a conventional score requires a
large number of steps. One graphical score represents only one possible view of the
G UIDO description. Other music notation algorithms may result in another score.
Therefore, the dvm captures the inherent structural properties of G UIDO.
4
WYSIWYG: What You See Is What You Get
44 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

3.1.2 Definition and Requirements

As suggested by the dvm, the Abstract Representation (AR) is the document con-
taining all information present in a G UIDO description. This leads to the following
definition:

Definition (Abstract Representation (AR)):

The Abstract Representation (AR) is a data structure capable of stor-
ing all information contained in a G UIDO description. The AR provides
efficient access and manipulation functions to the stored (musical) infor-
mation.
This definition does not solely focus on music notation, but is valid for all kinds
of applications. The current implementation of the AR has been developed with
conventional music notation in mind, but it can easily be used in other application
areas, where G UIDO is used as the underlying data format.
Several requirements must be met when designing and implementing the AR:
 efficient conversion of G UIDO descriptions into the AR
 efficient conversion of the AR into G UIDO descriptions
 the possibility to easily manipulate the AR for musical and/or notational algo-
rithms
 efficient conversion of the AR into conventional music notation
 portability between different computer platforms and different musical appli-
cations
These requirements lead to a data structure, which is closely tied to the general de-
sign of G UIDO. The data structure and the manipulation functions will be described
in other sections below. Figure 3.2 shows the interactions required of the AR when
a G UIDO descriptions is converted a conventional score.

3.2 G UIDO Semantic Normal Form

The G UIDO specification [HH96] clearly defines the syntax of G UIDO descriptions.
However, there exist numerous ways of expressing a musical and/or notational idea
within G UIDO. In order to be able to handle arbitrary G UIDO descriptions in an un-
ambiguous way, the “G UIDO Semantic Normal Norm” (GSNF) has been developed in
the course of work on this thesis. The notion of this normal form does not mean that
all possible descriptions of a musical and/or notational idea can be mapped onto one
single (and equivalent) normal form, but that semantically equivalent descriptions
have the same normal form.
3.2. GUIDO SEMANTIC NORMAL FORM 45

GUIDO description

parse dump

Manipulation
Abstract
Representation
Manipulation
conversion dump

Graphical
Representation Score

Figure 3.2: Interactions of the Abstract Representation

3.2.1 Semantic equivalence

Syntactically correct G UIDO descriptions contain musical information which is sub-
ject to interpretation by different applications. The syntactical rules for G UIDO
descriptions however leave room for some ambiguity; consider the following two
sequences describing the same musical content (they are musically equivalent):
(1) [ nslur( nclef<"treble"> c d e ) ]
(2) [ nclef<"treble"> nslur( c d e ) ]
In the first sequence, the tagged range of the nslur-tag encompasses the nclef-
tag and the following events, whereas the tagged range of the second sequence only
contains events. In order to define unambiguous semantics for handling the above
examples, a simple rule was introduced in the G UIDO definition:
Tagged ranges only affect the contained events.
This simple rule has far reaching consequences when interpreting G UIDO descrip-
tions:
1. Tagged ranges that do not contain events can be ignored.
2. If tagged ranges begin (or end) with a tag, the beginning (or ending) can be
shifted forward (backward) to the next event.
(In the example above, the first G UIDO description (1) contains the nslur-tag,
which covers a range beginning with the nclef-tag. Therefore, the beginning
of the range can be shifted; the result is the second G UIDO description (2).)
3. When more than one range tag begins or ends at the same event, the order in
which the range tags appear is not significant.
It is therefore possible to reorder these tags in lexicographical order (examples
for this will be shown below).
46 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

No G UIDO description GSNF

1 [ c nslur( ) d ] [ c d ]
2 [ cnslur( nclef<"treble"> ) d ] [ c nclef<"treble"> d ]
3 [ c nslur( nclef<"treble"> d e ) ] [ c nclef<"treble"> nslur( d e ) ]

4 [ nslur( ncresc( c d e ) ) ] [ ncresc( nslur( c d e ) ) ]

5 [ ncresc( nintens<"p"> c d ) ] [ nintens<"p"> ncresc( c d ) ]

Table 3.1: Semantically equivalent G UIDO descriptions

Taken these consequences a step further, it is now possible to define the G UIDO
Semantic Normal Form:

Definition (G UIDO Semantic Normal Form (GSNF)):

A G UIDO description G is in G UIDO Semantic Normal Form (GSNF),

if and only if the following holds:

1. G contains no empty tagged ranges

2. All tagged ranges in G begin and end at events
3. All tagged ranges that begin or end at the same event appear in
alphabetical order

The GSNF can now be used, to easily define the notion of semantical equivalence as
it is needed when interpreting different G UIDO descriptions:

Definition (Semantical Equivalence):

Two G UIDO descriptions are semantically equivalent, if they have the

same GSNF.

Table 3.1 shows semantically equivalent G UIDO descriptions based on the above
rules; each line in the right column of Table 3.1 is the GSNF of the G UIDO de-
scription in the left column. Some of the examples in Table 3.1 give rise to several
questions; for example, there seems to be no possibility, to attach a range tag with
a simple tag (as in example no. 5, where one might interpret the ncresc-tag being
attached to an nintens-tag. If the musical/notational intent is to attach a range
explicitly to a tag (as could be the case in example no. 5), it is however possible,
to define empty events with no duration; the example no. 5 would thus be writ-
ten as [ ncresc( empty*0/1 nintens<"p"> c d ) ]. Different graphical off-
sets could then be applied to the ncresc-Tag, which would be attached to the empty
event, which is not directly shown in the score.
3.2. GUIDO SEMANTIC NORMAL FORM 47

3.2.2 Transforming G UIDO descriptions into GSNF

G UIDO descriptions can be easily transformed into GSNF by shifting the beginning
and ending of tag ranges where needed. The desired effect can be obtained by ap-
plying a simple algorithm:

1. Find all range tags and apply the following tests:

2. If a range does not begin at an event, shift the beginning of the range to the
right until either an event or the range end is reached.5

3. If a range does not end at an event, shift the end of the range to the left until
either an event or the beginning of the range is reached.5

4. Remove empty ranges (and tags belonging to them).

5. If more than one range tag begins or ends at the same event, order them al-
phabetically by their name.

As an example, consider the third row of Table 3.1: By applying rule 1, the beginning
of the slur range is shifted towards the right and the GSNF is obtained.
The GSNF leads towards a data structure for G UIDO sequences that distinguishes
between events, non-range tags, and range tags. Events and non-range tags can
be stored in an ordered list, where the order of elements is taken directly from
the G UIDO description. The time positions of the elements form a monotone rising
function.6 For example, the sequence of elements for the third line of Table 3.1 is [ c
nclef<"treble"> d e ]7 and the respective time positions are 0  41  14  42 .8
The range tags are each split into a begin- and an end-tag, which store a pointer to
the location of their respective events within the element list. Figure 3.3 visualizes
the data structure for the third row of Table 3.1. Note that the range tags are itself
ordered by the position they point to in the element list and also by alphabet, if they
begin or end at the same event.
The described data structure will be discussed in more detail when presenting the
structure of the AR in section 3.3. The advantage of separating the range tags
from non-range tags and events lies in the fact that they can thus be easily added,
removed or exchanged. These operations will be needed for the different notation
algorithms in chapter 4.
5
If another range tag is encountered during the search, it can be ignored.
6
There are some minor exceptions to this rule; consider for example the ncue-tag, which is used to
describe cue notes. All events within the range for the cue tag add their duration to the time position,
but when the range is closed, the time position is reset to the time position of the starting event in
the range. The internal representation deals with this by introducing a completely independent voice
and therefore maintaining the monotone rising time function for each individual voice.
7
Note that the nslur-tag is not present in this list.
8
In G UIDO, the duration for the first event is 14 if nothing else is specified.
48 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

Element list:
Position: 1 2 3 4
Event: c Tag: clef Event: d Event: d

Range tag list:

slurBegin
slurEnd

Figure 3.3: Visualization of the GSNF for example 3 of Table 3.1

3.3 Structure of the Abstract Representation

When looking at a G UIDO description, the notion of “objects” comes quite natu-
rally: a G UIDO-event or a G UIDO-tag can be mapped directly onto an event- or
tag-object. These objects store all relevant data, for example the time position or
the note- or tag-name and tag parameters (if present). Depending on the event type
(an event is either a note, a chord, or a rest), a note-, or chord-, or rest-object can
be build, which inherits from the generalized event-class. As object-oriented de-
sign facilitates software-development, especially when large systems are concerned,
this technique was used for the the development of the AR [Boo91]. For reasons
of efficiency, C++ [Str91] was used as the object-oriented implementation language.
C++ is available for a large number of platforms and offers all features required for
modern object-oriented design (like templates, runtime-type-information, multiple
inheritance, etc.). Naturally, the design of the AR closely resembles the structure of
G UIDO, which greatly simplifies the process of converting G UIDO descriptions into
the AR (see section 3.4).
The two main structural concepts of G UIDO, namely sequences and segments are
also represented in the AR: Sequences are represented by a class called ARMusi-
calVoice and segments are represented by a class called ARMusic. Class ARMusic
is basically a collection of voices, combined with methods for parallel accessing the
contained voices (see section 3.5.2).
Figure 3.4 shows a class diagram in UML9 -Notation [FS00] of the main classes of the
AR (altogether, there are more than 70 classes for the AR). Every class name within
the AR begins with the prefix AR and all but some classes inherit directly or indi-
rectly from class ARMusicalObject, which contains data and function-definitions
required for all musical objects, like for instance the time position, and the duration.
As described in section 3.2, each G UIDO description can be converted into GSNF.
This fact has been used in the design of the AR, so that an efficient conversion from
9
UML: Unified Modeling Language
 ARMusicalObject
is a

contains

ARPositionTag ARMusicalTag ARMusicalEvent

0..n
KF_IPointerList
ARSlur ARClef <ARMusicalObject> ARNote ARRest

KF_IPointerList ARMusicalVoice ARChord

<ARMusicalVoice>
0..n
3.3. STRUCTURE OF THE ABSTRACT REPRESENTATION

1 1

ARMusic KF_IPointerList ARMusicalVoiceState

Figure 3.4: Class diagram for the main classes of the AR

<ARPositionTag>

0..n
49
50 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

and to G UIDO descriptions is possible. When a G UIDO description is converted into

the AR, it is first converted into GSNF before any manipulation algorithm is carried
out. All manipulation algorithms of the AR require the internal representation to
be in GSNF; therefore, when a G UIDO description is extracted from the AR, it will
always be in GSNF.
In the following, the main classes of the AR that store musical information will be
introduced.10

Class ARMusicalObject

All classes within the AR inherit directly or indirectly from class ARMusicalOb-
ject. This class is the base entity for all musical information. Class ARMusicalOb-
ject stores the duration and the time position of the respective instance, as this
information is shared by all musical objects in a G UIDO description. In the case
of tags, the duration is always zero.11 The time position depends on the entities’
position within the G UIDO sequence.
Because almost all classes are descendants of class ARMusicalObject, collections
of events, or tags can be defined as lists containing objects of type ARMusicalOb-
ject. Using the runtime-type-information feature of C++, it is possible to deter-
mine the actual type of an object at runtime.

Class KF IPointerList<class T>

This helper class implements a doubly linked list of pointers to objects of type T;
it is implemented using the template-feature of C++. All functions for traversing
or adding and removing elements are implemented. Class KF IPointerList is in-
tensively used throughout the AR. In the future, class KF IPointerList might be
exchanged with the list class from the Standard Template Library (STL) [Rob98], as
the STL usually offers very efficient data structures. Because of the object oriented
design, such a change would be transparent to the user of the AR.

Class ARMusic

A complete G UIDO description can be represented by one instance of class ARMu-

sic. As class ARMusic directly inherits from class KF IPointerList<ARMusi-
calVoice>, it can be viewed as a list of voices, just as G UIDO descriptions are
collections of sequences. Class ARMusic also directly inherits from class ARMusi-
calEvent, because it has all properties of an event. This feature will be useful for
10
A thorough introduction to all classes of the AR is not possible here because of space restrictions,
but the general concept can be understood by studying the main classes.
11
Events may also have zero duration, but this is mostly needed for sophisticated graphical for-
matting of a score.
3.3. STRUCTURE OF THE ABSTRACT REPRESENTATION 51

the definition of hierarchical scores (see also section 2.3.3): a complete score can be
interpreted as an event contained in another score.12
Class ARMusic defines some notational transformation functions, which will be de-
scribed in detail in chapter 4. Most importantly, class ARMusic offers parallel access
to the contained voices. This feature is important for manipulating the AR when it
is converted into a conventional score.

Class ARMusicalEvent
Class ARMusicalEvent is the base class for all G UIDO events: notes, chords13 and
rests. An event has a duration (which may be zero) and it can be the beginning or
end of a range tags. As G UIDO events can specify durations as fractions in com-
bination with dots (as in [ c1*1/4.. ]); class ARMusicalEvent has a member
variable, which holds the number of dots for an event (which would be two in the
previous example). The actual duration of the event is stored in a member variable
of class ARMusicalObject.

Class ARNote
Class ARNote inherits from class ARMusicalEvent and describes G UIDO note ev-
ents. Class ARNote has member variables for the note name, pitch, octave, inten-
sity,14 and a list of accidentals. When parsing arbitrary G UIDO descriptions, it may
very well be, that the duration of an instance of class ARNote is not displayable
as a single graphical element; these notes will be treated by the music notation
algorithms of chapter 4.

Class ARRest
Class ARRest inherits from class ARMusicalEvent and describes G UIDO rests.
Rests do not store additional information, because they are completely defined thru
their duration, which is already held in class ARMusicalObject.

Class ARMusicalTag
Class ARMusicalTag is the base class for all tag classes. It stores common tag data
and offers common tag functions; class ARMusicalTag stores the following data:

 id: The ID of the tag, if an id was used in the G UIDO description as in

nslurBegin:3
 hasRange: is 1, if the tag has a range (as in [ nslur( c d e ) ])
12
This concept has not yet been realized in the graphical representation.
13
Chords are handled different from notes and rests; see section 3.3.1.
14
The intensity is stored so that the AR can be used for playback-applications.
52 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

 allowRange: is 1, if the tag is allowed to have a range (as for example the
nfermata-tag). This parameter is used during the parsing of GUIDO descrip-
tions: if it is zero, and the parsed tag has a range, the error flag is set and
the tag is ignored.

 assoc: the association of the tag. This flag describes, the direction of the
association that a tag has with respect to events. The assoc flag has one of the
following value: Left-Associated (LA), Right-Associated (RA), Don’t-Care (DC),
Error-Left (EL), Error-Right (ER). If the tag is a begin-tag (like nslurBegin),
the association is always RA, which means that the tag is associated with the
the next event (being on the right hand side in the G UIDO description); if the
tag is an end-tag (like ncrescEnd), the association is always LA, which means
that the tag is associated with the previous event (which is on the left hand
side in the G UIDO description). If the tag is not a range tag, the association is
DC. In the case of an error (error-variable is set), the association is one of ER
or EL.
These parameters will be explained further in section 3.4, when the conversion
of G UIDO descriptions into the AR is presented.

 error: is 1, if an error occurred while handling tag-parameters or tag ranges.

Class ARPositionTag
Class ARPositionTag is one base class for all range tags.15 An instance of class
ARPositionTag stores a pointer to a position in the element list of class ARMusi-
calVoice and also a pointer to the matching ending position tag (which is again an
instance of class ARPositionTag): the begin-tag stores a pointer to its matching
end-tag and vice-versa. One range tag from a G UIDO description is internally bro-
ken into two instances of class ARPositionTag: one begin- and one end-tag. There-
fore, the AR of the two G UIDO sequences [ nslur(c d e) ] and [ nslurBegin c
d e nslurEnd ] is identical.16
A tag, which can occur either as a range tag or as a non range tag (the ntext-tag,
for example) inherits from both class ARMusicalTag and class ARPositionTag so
it can be handled as either one.

Class ARMusicalVoice
Class ARMusicalVoice completely represents a G UIDO sequence. It is used by
class ARMusic to represent a complete voice within a piece. Class ARMusical-
Voice directly inherits from class KF IPointerList<ARMusicalObject>, so it
15
As the AR uses multiple inheritance, a range tag usually has at least two base classes.
Internally, there is a distinction between the nslur-tag with a range and the nslurBegin- and
16

nslurEnd-tag, so that the original structure of the input is not destroyed. Nevertheless, the two
sequences are treated completely alike.
3.3. STRUCTURE OF THE ABSTRACT REPRESENTATION 53

can be interpreted as a container for musical objects. The inherited list stores all
events and non-range tags in the order in which they appear in the G UIDO descrip-
tion. Additionally, class ARMusicalVoice contains a list (class ptaglist), which
holds instances of class ARPositionTag. This list stores all range tags (begin- and
end-tags) ordered by their respective start- end end-positions in the voices element
list. The list-order follows directly out of the definition of the GSNF in section 3.2.
Figure 3.5 visualizes the structure of class ARMusicalVoice for the given G UIDO
sequence.

[ nslurBegin c ncrescBegin ntie( d nslurEnd ncrescEnd d ) ]

Element list:
Position: 1 2 3
Event: c Event: d Event: d

Range tag list:

slurBegin (RA)
crescBegin (RA)
tie (RA)
crescEnd (LA)
slurEnd (LA)
rangeEnd (LA)

Figure 3.5: Structure of ARMusicalVoice for a G UIDO sequence

Class ARMusicalVoice offers all operations required for traversing the voice (see
section 3.5 for details on accessing the AR). The required state information is stored
in the helper class ARMusicalVoiceState.

Class ARMusicalVoiceState
Class ARMusicalVoiceState is needed when a voice is traversed sequentially (see
section 3.5). Class ARMusicalVoiceState stores all state information for an in-
stance of ARMusicalVoice, so that it is possible to resume a position within a
voice exactly. The information stored includes the current time position, the current
position-tags, and the current location within the element- and the position-tag-list.

Class ARSlur
Class ARSlur is included in this list of classes as an example for a range-tag. Class
ARSlur represents the nslur-tag; being a tag, it inherits from class ARMusicalTag.
54 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

Because the nslur-tag is a range-rag, class ARMusicalTag also inherits from class
ARPositionTag.

Class ARClef

Class ARClef is an example of a non-range tag; it represents the nclef-tag in a

G UIDO description. Class ARClef inherits directly from ARMusicalTag and is usu-
ally included in the element list of class ARMusicalVoice. The class stores all in-
formation required for representing a clef: a name (“treble”, “bass”, etc.), the octave,
the base-line-number, etc.

3.3.1 Representing chords in the AR

The class ARChord in Figure 3.4 is shaded in gray, because it is not present in the
current implementation of the AR. The representation of chords within the AR is
rather complex issue, which will be elucidated in this section.

Chords as single events

The first approach for handling chords in the AR treated chords like other events
(notes and rests). This approach worked quite well at first, because chords were
treated as single entities that had no additional markup. This changed when it
became clear, that tags within individual chord notes are required for musical and
notational markup.17 Figure 3.6 shows a G UIDO description together with an in-
ner representation, in which chords are stored as single musical events (containing
other events). Because the chord is stored at one single position in the event list,
range tags can only point to this one single location. In the example of Figure 3.6
the ntieBegin-tag points to the second position of the event list. As can be seen
from this example, the chord must “redirect” the tag to its correct location within
the chord. This redirection must be handled by some mechanism within the data
structure – this shows that a chord cannot be regarded as a simple event. Repre-
senting chords as single events is also difficult when considering G UIDO Semantic
Normal Form: if a chord is a single event, a tag can only affect the whole event.
There is no mechanism for “partial” tags in the GSNF. Additionally, the conversion
of this inner representation into a conventional score has to deal with chords in a
specialized way, introducing an additional layer of complexity for dealing with tags
within chords. Therefore, a new solution was developed:
17
Think of partial ties, for example, that begin at a single note within a chord and end somewhere
later.
3.3. STRUCTURE OF THE ABSTRACT REPRESENTATION 55

[ c { c, \tieBegin e, g } e \tieEnd ]

Event: g
Event: e
Event: c Event: c Event: e
Position: 1 2 3

Range tag list:

tieBegin (RA)
tieEnd (LA)
Figure 3.6: Chords as single events in the Abstract Representation

Splitting chords into a series of events

The idea for a suitable inner representation of chords came while looking at the
graphical representation of a chord in a score: A chord is an entity, where several
noteheads share a common stem, or at least a common horizontal position. Using
this observation, the idea of “graphical equivalence” was created: instead of repre-
senting a chord as a special form of an event, it can be represented by a series of
events combined with some formatting information. The implemented inner rep-
resentation of chords handles chords as graphical entities, which share a common
stem. Using this representation, all aspects of the GSNF (see section 3.2) can be
maintained. Figure 3.7 shows how the same example as presented in Figure 3.6 is
currently represented in the AR. The G UIDO description

[ c f c, ntieBegin e, g g e ntieEnd ]

is internally converted into the G UIDO description

[ c nchordBegin ndisplayDurationBegin<1,4,0>
nshareStemBegin empty*1/4 nchordComma ntieBegin e*0
nchordComma g*0 ndisplayDurationEnd nshareStemEnd
nchordComma empty*0 nchordEnd e*1/4 ntieEnd ]
At first, this transformation might seem exaggerated, but using this formalism, all
issues concerning tags within chords can be resolved. Four new internal18 tags are
used:
18
Internal tags are non-standard G UIDO tags that are used within the developed notation system.
They are not part of the G UIDO specification.
56 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

 nchord: This tag groups all events and tags of a chord together. The musi-
cal duration of the chord is encoded in the first (empty) event of the nchord-
tag range, which is added automatically during the conversion. All the other
events in the nchord-tag range get a musical duration of zero. This is impor-
tant, because otherwise, the musical time of the voice would not match the
musical time of the original G UIDO description. In the example above, the mu-
sical duration of the chord (and therefore of the first empty event within the
nchord-tag range) is a quarter note.
 ndisplayDuration: This tag enforces a specific visible duration to be used
when creating the notes and rests within its range. Instead of using the mu-
sical duration (as given in the G UIDO description) for creating the notation
symbols, the tag parameters are used to create note heads and rests. In the
example above, the displayed duration is 14 without dots (the last parameter
is zero). Therefore, all events within the tag-range are displayed as quarter
notes, even though their musical duration is zero.

 nshareStem: All notes within the tag range share a common stem.
 nchordComma: This tag groups the individual voices of the chord. Using the
nchordComma-tag in the transformed chord representation is mandatory, be-
cause otherwise the inner chord representation could not be re-converted into
the equivalent G UIDO description.19

The current chord representation has more consequences than might be first ex-
pected: when traversing a voice, an event-mode and a chord-mode must be distin-
guished. In event-mode, everything within the voice is iterated sequentially. This
mode is used when converting the abstract representation of a voice into a conven-
tional score. In chord-mode, all events that are part of a chord are read in one step.
This mode is used for many manipulating routines, which will be described later in
this chapter.

3.4 Transforming G UIDO descriptions into the AR

Because the design of the Abstract Representation closely follows the G UIDO design,
the creation of one specific AR for a given G UIDO description is a straightforward
process. Following the notion of the “factory design pattern” [GHJV94], the class
ARFactory was implemented. A “factory” is an object that “builds” other objects. In
our case, class ARFactory constructs all objects of the AR depending on the given
G UIDO description. Class ARFactory serves as the link between the G UIDO parser
19
Without the nchordComma-tag one could not distinguish between
[ f c nintens<"p"> , e g ] and [ f c, nintens<"p"> e g ].
 [ c { c, \tieBegin e, g } e \tieEnd ]

c*1/4 em pty*1/4 \chordCom m a c*0 \chordCom m a e*0 \chordCom m a g*0 \chordCom m a em pty*0 e*1/4

chordBegin

displayDurationBegin

shareStem Begin

tieBegin

shareStem End
3.4. TRANSFORMING GUIDO DESCRIPTIONS INTO THE AR

displayDurationE nd

chordEnd

Figure 3.7: Chords as a Series of Events in the Abstract Representation

tieEnd
57
58 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

kit [Hoo] and the AR. During the parse, the hook-functions of the G UIDO parser kit
successively call the routines of class ARFactory, which then builds the AR.
Class ARFactory is responsible for the following tasks:

 Creating one instance of ARMusic that is a container for instances of class

ARMusicalVoice

 Creating one instance of ARMusicalVoice for each sequence in the G UIDO

description and ensuring that each voice is in GSNF.

 Creating events (notes and rests) and handling the given parameters (dura-
tion, accidentals, pitch, and octave)

 Creating range and non-range tags and handling tag-parameters

 Checking that arbitrary pairs of begin- and end-tags are correctly matched.

 Creating the inner chord representation, which was introduced in section 3.3.1.

After the G UIDO description has been parsed, each voice is transformed into G UIDO
Semantic Normal Form. This is important, because all further manipulation func-
tions on the AR require the input to be in GSNF; they “guarantee” (contract-model)
the output to be in GSNF as well.

Generic Handling of Tag Parameters

As was shown in section 2.2, Advanced G UIDO allows different types of tag pa-
rameters: one may use named tag parameters, or tag-parameters are assigned by
their position in the tag-parameter list. There is also a distinction between optional
and required parameters. As each tag has unique parameter names and values, a
generic handling of tag parameters was implemented in the notation system. Each
tag stores a parameter-string that defines names, types, and default values for the
parameters. As an example for such a string consider the parameter string for the
nclef-tag:
"S,type,treble,r;S,color,black,o;U,dx,0,o;U,dy,0,o;F,size,1.0,o"
Each tag parameter is defined by four entries: the first entry is a single character
that defines the type of the value. Allowed types are “S” for string, “U” for unit-
parameter (the value can be followed by a unit-parameter like “cm”, “hs”, etc.), “F”
for a floating point number, or “I” for an integer number. The second entry defines
the name of the tag-parameter. The third entry is the default-value for the tag-
parameter. The fourth (and last) entry defines, whether the entry is required (“r”)
or optional (“o”). For the example above, there are five possible tag-parameters: the
first is a required (“r”) string (“S”) with the name “type” and a default value of “tre-
ble”. The second parameter is an optional (“o”) string (“S”) with the name “color”
and a default value of “black”. The third parameter is an optional (“o”) unit-value
3.5. ACCESSING THE AR 59

(“U”) with name “dx”, default value “0”. The fourth parameter is similar to the
third; the fifth parameter is an optional (“o”) float-value (“F”) with name “size” and
a default value of “1.0”. A G UIDO description may contain the following nclef-tag:
[ nclef<type="bass",size=0.75,color="blue"> ] which defines a bass-clef
with 75 % of the regular size and a blue color.
It is possible to define more than one parameter-value string for each tag, so that
different parameter-constellations may be used in parallel. Class ARFactory uses
some helper classes to ensure that a tag in the given G UIDO description is checked
against all tag-parameter-lists. Using this mechanism, it is quite easy to implement
arbitrary parameter names and values for any of the defined G UIDO tags.

3.5 Accessing the AR

The conversion of a G UIDO description into the AR can be accomplished quite eas-
ily, as could be seen in the previous section. When dealing with music notation
algorithms (or algorithms from other domains) it is necessary to access the data con-
tained in the AR. As G UIDO descriptions usually are collections of G UIDO sequences,
the access mostly concentrates on the voices (class ARMusicalVoice). Some algo-
rithms (as will be seen in chapter 4) also require the parallel access to all voices. In
this section, the different modes of accessing the AR will be introduced.

3.5.1 Accessing class ARMusicalVoice

Class ARMusicalVoice was introduced in section 3.3; as it was described there,
class ARMusicalVoice is a container for other objects of type ARMusicalObject.
The realized container type is a doubly linked list; therefore all access functions
to information contained in the voice operate are commonly known list functions.
The current state of an iteration of class ARMusicalVoice is stored in an instance
of class ARMusicalVoiceState. All functions that access class ARMusicalVoice
therefore require one instance of class ARMusicalVoiceState. This class stores all
currently active state-tags,20 all currently active range-tags, and also information
about the current (time-)position within a measure, if a meter is specified for the
voice. As indicated in section 3.3.1, two different access-modes exist for accessing
an instance of class ARMusicalVoice: event-mode and chord-mode. In event-mode,
all events are iterated sequentially. In chord-mode, all events that belong to one
chord are iterated in one step. The following four functions are used for sequential
access:

1. GetHeadPosition(ARMusicalVoiceState &curvst): This function is

used to start a new iteration on the current voice. The function returns the
20
State-tags are tags that define the musical state of a voice; these include clef, key, or meter and
information.
60 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

start position of the element list and resets the voice state information in
curvst.

2. GetNext(POSITION pos,ARMusicalVoiceState &curvst): This func-

tion iterates to the next position in the element list and updates the state
information in curvst. The object at the current position of the element list
is returned.

3. GetAt(POSITION pos): This function just returns the object at the current
position of the element list.

4. GetPrev(POSITION pos,ARMusicalVoiceState &curvst): This func-

tion iterates to the previous position in the element list and updates the state
information in curvst. This function may only be called, if the element at the
current position of the element list is an event (and not a tag). Otherwise it
may be that the state information in curvst is not be updated accurately.

By storing all iteration-relevant information in one instance of class ARMusical-

VoiceState, it is possible to completely save the state of a voice. This is very
helpful, when multiple iterations on the same voice are carried out in parallel.

3.5.2 Parallel Access

Parallel access to all voices contained in an instance of class ARMusic is sometimes
necessary. To simplify this iteration process, a helper class called ARVoiceManager
was developed. For each voice in the current instance of class ARMusic, one instance
of class ARVoiceManager is created. When iterating thru all voices in parallel,
all the instances of class ARVoiceManager are used; they do not only return the
elements contained in the voice, but also information on the current time-position
and the current state of a voice (for example, if the next entry in the element list is
an event or a tag). This information is important for ensuring that the iteration is
truly a parallel access. To give an example for a parallel access, Figure 3.8 shows
a G UIDO description and the matching score. The order in which the elements are
iterated when doing parallel access is documented by the numbers in the G UIDO
description and the graphical score of Figure 3.8. Note that for a given time position,
first all tags are read. Only after all tags at the time position have been read, the
events at the time position are processed.

3.6 Manipulation of the AR

The definition of the AR in section 3.1.2 included efficient manipulation functions.
In order to define algorithms for music notation as transformations of the AR, some
generic operations on the AR are required, which will be described in this section.
3.6. MANIPULATION OF THE AR 61

{ 1 3 6 9 10 12 14
[ \clef<"treble"> \meter<"3/4"> c2/4. h1/8 | c2/2 _/4 ],

2 4 5 7 8 11 13
[ \clef<"bass"> \key<"D"> \meter<"3/4"> { d0/4, f# } { c, e } | c/2. ]
}

1 3 10 12
6 14
9

2 4 5 7 8 11

13

Figure 3.8: Parallel access to the AR

Note that all operations described here require the AR to be in GSNF and likewise
ensure that the returned AR is in GSNF as well.

3.6.1 Operations on range tags

Operations on range tags exclusively modify the list of position tags (internally
called ptaglist; in Figure 3.5 the list is called “Range tag list”) of class ARMu-
sicalVoice. All of the manipulation routines must ensure that the correct or-
der of the ptaglist is maintained. The ptagpos-pointer, which remembers the
current position within the ptaglist for an iteration, of class ARMusicalVoice-
State must also be set correctly. This position depends on the current position in
the element-list. The following manipulation routines for range tags are present in
the AR.

Removing range tags There are situations, where range tags need to be removed
from the AR. Removing one tag actually removes two entries from the ptaglist,
as there is always a begin- and a matching end-tag. The removal-operation can be
carried out in a straightforward way: the begin- and end-tags are removed from the
ptaglist and the ptagpos is set accordingly: if the current position within the
ptaglist was set on a position-tag that is being removed, the position is set to the
following position-tag. If there is no following tag, the position is set to NULL, which
62 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

is interpreted as a traversal beyond the end of the list. Reading Figure 3.9 from top
to bottom visualizes the removal of a the ncresc-tag.

Element list:
Position: 1 2 3 4
current position
Event: c Tag: clef Event: d Event: e

Range tag list:

(A) Before removal:
(B) After insertion: crescBegin
slurBegin
crescEnd
slurEnd

Element list:
Position: 1 2 3 4
Event: c Tag: clef Event: d Event: e
(A) After removal:
Range tag list:
(B) Before insertion:
slurBegin
slurEnd

Figure 3.9: Visualization of range tag removal (A) and range tag insertion (B)

Inserting range tags When inserting range tags (like for example a ntie-tag),
the begin- and end-position of the range in the element list is needed, so that the
correct location in the ptaglist can be found. The actual insertion of the two
instances of ARPositionTag – the begin- and the end-tag – can then be done easily.
Some care has to be taken, if there are no previous range tags present in the AR, in
which case the ptaglist must be created. Reading Figure 3.9 from bottom to top
visualizes the insertion of a ncresc-tag.

Changing the start and end positions This operation is mainly required, when
events in the element list are being removed or split. Because the position tags in
the ptaglist store pointers to locations in the element list, all position tags point-
ing to such events must be updated to match the new position in the element list. As
long as the order of the ptaglist is not disturbed, the re-pointering is a straight-
forward process. Otherwise, the order of the elements in the ptaglist must be
changed to match the new situation. Figure 3.10 shows the effect of changing the
positions within the ptaglist in order match the situation in the element list: be-
fore the change, the nslur and the nbeam-tag both ended at the same event. After
3.6. MANIPULATION OF THE AR 63

the change, the nslur-tag now ends before the nbeam-tag. The order within the
ptaglist is changed.

Element list:
Position: 1 2
current position Event: c Event: d

Before change
Range tag list:
beamBegin
slurBegin
beamEnd
slurEnd

Element list:
Position: 1 2 3
After change Event: c Event: d Event: d

Range tag list:

beamBegin
slurBegin
slurEnd
beamEnd

Figure 3.10: Changing the order within the range tag list

3.6.2 Operations on events and non-range tags

The operations on events and non-range tags modify the element list and, in some
cases, also the position tag list (ptaglist) of ARMusicalVoice. When manipulat-
ing events and non-range tags, the operations must assert that the correct (time)
order of the elements in the element list is maintained and always forms a mono-
tone rising time function. The following manipulation functions are included in the
AR:

Inserting and removing non-range tags Sometimes, non-range tags have to

be inserted into the AR. This happens, for example, when nclef- or nkey-tags are
automatically added after a nnewSystem- or nnewPage-tag. As non-range tags are
never associated with range-tags, and therefore are never pointed to be any entry
in the ptaglist, the process of inserting and removing non-range tags can be done
directly by inserting or removing the new tag in the element list at the appropriate
time position.
64 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

Splitting events When dealing with automatically inserted bar lines or nnew-
System- or nnewPage-tags, it is sometimes necessary to split one event into two
events. This happens, if the new bar-line has to be inserted at a time position that
lies within the duration of an event. If an event is split, the resulting events need to
be joined by a ntie-tag, so that the musical idea remains the same. Splitting events
is a manipulation that is required often, especially when a time signature is set and
automatic bar lines are inserted. To split an event, the duration of the resulting
two events must be known. If the original event has duration d, then d = d1 + d2
must hold, where d1 and d2 are the durations of the two resulting events. First,
the original event changes its duration to d1 . Then a new event with duration d2
is inserted (using the routine described below). Finally, the position tags must be
“repointered”. Depending on the tag-type, tags that began at the original event can
now either begin at e1 or at e2 . Figure 3.11 shows an example of splitting an event
because of a nbar-tag.

\bar

Voice 1: c*1/4 c*1/4 c*1/4

Voice 2: c*1/4 c*3/8 c*1/8

Voice 1: c*1/4 c*1/4 c*1/4

Voice 2: c*1/4 c*1/4 c*1/8 c*1/8

tieBegin

tieEnd

Figure 3.11: Splitting an event

Because of the special inner representation of chords (see section 3.3.1), the process
of splitting a chord into two chords is much more complicated. In this case, all
elements of the chord must be copied and joined by ntie-tags. Because some tags
within the chord may alter the state of the voice (for example a nstaff-tag, that
changes the staff on which the voice is displayed), the state of the voice at the first
element of the original chord must be saved. This saved state information must be
restored before the second chord is inserted. Figure 3.12 shows a chord containing
3.6. MANIPULATION OF THE AR 65

a nstaff-tag and the implications for splitting this chord. All added or changed
information is displayed in bold type. Note that a new nstaff-tag is inserted at
the beginning of the second chord. In order to focus on the main points, the Figure
does not show the inner representation but uses the equivalent G UIDO descriptions
instead. Internally, the inner chord representation of section 3.3.1 is used.

{ [ \staff<1> { c/2, \staff<2> e } ]

[ \staff<2> c/4 e ] }

{ [ \staff<1> \meter<"1/4"> { c/2, \staff<2> e } ],

[ \staff<2> \meter<"1/4"> c/4 e ] }

{ [ \staff<1> \meter<"1/4">
{ \tieBegin:1 c/4,
\staff<2> \tieBegin:2 e }
\bar
{ \staff<1> c/4 \tieEnd:1,
\staff<2> e \tieEnd:2 } ],
[ \staff<2> \meter<"1/4">
c/4 \bar e ] }

Figure 3.12: Splitting a chord

Inserting Events The insertion of new events into the AR can be accomplished
rather easily. Once the location for inserting the event into the doubly linked el-
ement list has been found, it can be easily inserted. Because all elements of the
list store their time position, all elements following the inserted event must in-
crease their time position by the duration of the inserted event. Because the event
is stored at a new position within the element list, the range tags are not affected
by this change.

Removing Events The case of removing events is a little bit more complicated
than the insertion of events, because the range tags may have to be considered as
well. At first, the same premises as in the insertion case hold. The event that is
about to be removed has a position in the doubly linked list. When it is removed,
the following elements have to update their time position. Then it has to be checked,
whether any range tag begins or ends at the removed event. Depending on the tag,
66 CHAPTER 3. AN INNER REPRESENTATION OF GUIDO

it can either be removed from the position tag list, or its position can be changed to
either the previous or the following event. This depends on the type of the tag and
can not be generalized. As an example consider the G UIDO description
[ ncresc( c d e ) f ].
If the e is removed, the resulting G UIDO description looks like
[ ncresc( c d ) f ].
In this case, the ncresc-tag updates its range to the previous event.

3.7 Conclusion
In this chapter an application-oriented inner representation for G UIDO descriptions
called Abstract Representation (AR) was introduced. It was shown that the AR can
be regarded as the document in the context of the Document-View-Model, a design
pattern that helps in encapsulating the data from a concrete type of display or ma-
nipulation. In order to facilitate the handling of G UIDO descriptions, the G UIDO Se-
mantic Normal Form (GSNF) was identified and the conversion of arbitrary G UIDO
descriptions into GSNF was described. The GSNF is a normal form that leads to
a clear distinction of G UIDO elements: events, non-range tags, and range-tags. In
the following, the object oriented design and the structure of the AR was described
in some detail. The main classes of the AR were presented, and it was shown, how
G UIDO descriptions are converted into the AR. The final section of this chapter dealt
with access and manipulation of the AR. All of the described routines are required
by the notation algorithms, which will be described in the following chapter.
Generally, applications dealing with any form of music representation need a suit-
able inner representation. In this chapter, it was shown that the AR offers such
a flexible and powerful representation for G UIDO descriptions. As already stated
above, the AR can not only be used for music notation purposes, but is a complete
inner representation for arbitrary G UIDO descriptions. The contained manipulation
functions and routines make it useful for a whole range of computer music systems.
Chapter 4

Converting Arbitrary G UIDO

Descriptions Into Conventional
Scores

Introduction
The conversion of an arbitrary G UIDO description into a conventional score is a
process requiring a multitude of music-notation algorithms which will be described
in detail in this chapter. As was shown in the previous chapter, there is a one-to-
one correspondence between G UIDO descriptions and the Abstract Representation
(AR). Because the AR is a powerful data structure, which was developed to allow di-
rect and efficient manipulations, many of the notation algorithms described in this
chapter work directly on the AR. Basically, all conversions needed to convert the
AR into a conventional score can be described as G UIDO to G UIDO transformations:
Beginning with an arbitrary G UIDO description and its corresponding AR, a series
of algorithms add notationally relevant information to the AR (like for example au-
tomatically creating bar lines, if a time signature has been encoded in the G UIDO
description). After these transformations, the AR is converted into the so called
“Graphical Representation” (GR), which is an object oriented class structure whose
classes closely correspond to the visible elements of a graphical score. Similar to the
AR, the GR and all necessary algorithms have been developed as part of this thesis.
The conversion of the AR into the GR is a two step procedure: first, the graphical
elements are created from the data contained in the AR, then another set of mu-
sic notation algorithms is responsible for finally placing the notational elements on
lines and pages.
This chapter is structured as follows. First, the notion of G UIDO to G UIDO transfor-
mations is explained in detail. Then, generic music notation algorithms are classi-
fied and their scope – which structural representation level they use – is identified;
the implemented algorithms are presented. After that, the Graphical Representa-

67
68 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

tion (GR) is introduced, and it is shown, how the AR is converted into the GR. The
conversion process automatically determines all information that is necessary to
build conventional score. Finally, conventional and newly developed algorithms for
spacing, line breaking, and page-filling are explained in detail. Where appropriate,
similarities to text processing are mentioned.

4.1 Music Notation as G UIDO to G UIDO Transforma-

tions
Arbitrary G UIDO descriptions contain musical entities (like notes, rests, and musi-
cal and graphical markup) that are not necessarily closely related to one single ele-
ment of a graphical score. When creating a visual score representation from an ar-
bitrary G UIDO description, the entities of the AR are modified (split, copied, added)
to more closely represent single graphical elements present in the visual score. Fig-
ure 4.1 shows an example of how the G UIDO description (a) can be transformed into
the G UIDO description (b), which much more closely resembles the actual graphi-
cal appearance (c). In this example the nmeter-tag forces bar lines to appear in the
score; the bar lines split musical notes into two graphical notes, joined by a tie. Even
though the musical information of descriptions (a) and (b) is similar, description (b)
can be used far more easily to create the graphical elements of the score.

(a) [ nmeter<"4/4"> c*3/4 d e ]

+
=
(b) [ nclef<"treble"> nmeter<"4/4">
c*3/4 ntie( d*1/4 nbar d*2/4 )
ntie( e*2/4 nbar e*1/4 ) ]
(c)
Figure 4.1: Simple G UIDO to G UIDO transformation

The notation system, which was developed as part of this thesis, was implemented
in such a way that a G UIDO description is first converted into a corresponding Ab-
stract Representation (AR).1 Then, a number of notation algorithms, which will be
described in detail in the next section, manipulate the AR. These algorithms are all
G UIDO to G UIDO transformations: they get a G UIDO description as their input and
return an enhanced or modified G UIDO description as their output. Each algorithm
only manipulates a strictly defined musical or notational aspect of a score. Then the
AR is converted into the Graphical Representation (GR). All elements of the GR are
1
As indicated before, this correspondence is a one-to-one relationship.
4.1. MUSIC NOTATION AS GUIDO TO GUIDO TRANSFORMATIONS 69

directly connected to elements of the AR; this is important so that all further algo-
rithms, which directly manipulate the GR, can still be described as G UIDO to G UIDO
transformations: the manipulation of an element of the GR is directly reflected in
the corresponding element of the AR.
Figure 4.2 shows, how a G UIDO description is first converted into the AR, which is
then manipulated through a set of notation algorithms. Afterwards, the AR is con-
verted into the GR, where it is again manipulated through another set of algorithms.
The GR can then be used to directly render a score – either within an application or
as a graphics file. The results of all notation algorithms are stored within param-
eters of the AR; the corresponding enhanced G UIDO description contains a textual
representation of the completely formatted score.

Input: GUIDO description

Abstract Notation
Representation Algorithms I
(GUIDO to GUIDO
transform ations)

Graphical Notation
Representation Algorithms II

enhanced
GUIDO description

Output:

Score

Figure 4.2: General approach for G UIDO to G UIDO transformations

Because each notation algorithm deals only with strictly defined musical or nota-
tional aspects of a score, it is possible to exchange some of the algorithms to get a dif-
ferent score. As an example, consider the algorithm that decides on automatic beam
groups: the “standard” algorithm uses the current meter to decide on beam groups.
Another algorithm may use a Neural Network approach to find beam groups.
The musical information present in the original G UIDO description is not changed
by the notational transformations. The original information is rather intensively
used to to derive graphical “knowledge” that is added to the original description. In
conjunction with built in notational knowledge (spacing, line-breaking, etc.), the col-
lection of G UIDO to G UIDO transformations build the core of the notation renderer.
70 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

The concept of describing the creation of a conventional score as a sequence of

G UIDO to G UIDO transformations distinguishes the presented implementation from
other notation software: the contained notational knowledge can be extracted by
studying the results of individual transformation routines. Because every transfor-
mation routine returns a graphically enhanced and valid G UIDO description (or at
least the equivalent internal representation of it), no explicit knowledge of the in-
ternal representation is required to understand the single transformational steps.
It is also possible to exchange only some of the transformation algorithms to change
the overall appearance of the score. When all notation algorithms have dealt with a
given G UIDO description, the notation system finally outputs a completely format-
ted Advanced G UIDO description. If the original description already was a complete
Advanced G UIDO description, the algorithms within the notation system will not
add or change any information.
In the next section, the different music notation algorithm will be described as
G UIDO to G UIDO transformations.

4.2 Music Notation Algorithms

The process involved in music setting has been classified by Don Byrd [Byr84] as
involving three distinct steps:2

1. Selecting: deciding what symbols to print.

2. Positioning: deciding where to print the symbols

3. Printing the symbols

These three steps have to be performed in any music processor that converts musi-
cal information into a printed score. When considering interactive music notation
systems, some of these steps are not clearly defined: an interactive system may
not require the first step, because in this case, the user directly decides on the
symbols.3 Also, in interactive systems, the positioning of symbols is usually done
semi-automatically: the system applies internal notational knowledge to place the
symbols first; then the user can manually adjust their graphical positions if needed.
The printing process has vastly improved since 1984 (when Don Byrd wrote his
thesis); today, high resolution laser printers are available at little cost even for home
users. Nevertheless, there are still issues of device-independent output that have to
be considered – especially if the notation system is used on screen and for printing.
The music notation algorithms, which will be discussed in this section, may be clas-
sified according to the three steps from above. One class of algorithm deals mainly
2
Pages 74–75
3
Sometimes it is still required to break one musical note into several graphical entities as in the
case of automatically added bar lines.
4.2. MUSIC NOTATION ALGORITHMS 71

with the selection process: this relates to the first step mentioned above. These algo-
rithms work on the inner representation only; they can thus be described as AR to
AR transformations. As an example for this class consider the algorithm, which de-
cides upon which notes to group together for beaming (the group selection depends
mainly on the current meter). Another class of algorithm deals with the positioning
of symbols: this relates to the second step from above. These algorithms require
knowledge of the graphical environment (for example the width and height of the
page, the width and height of a staff-line, of a note, etc.). These algorithms mainly
work on the graphical representation. In the following, the notation algorithms on
the AR level are explained. The algorithms that manipulate the Graphical Repre-
sentation will be presented in sections 4.4 and 4.5.

Music Notation Algorithms on the AR level

In the following, the music notation algorithms, which manipulate the AR are pre-
sented. These algorithms perform a sort of pre-processing of the musical data given
in the original G UIDO description. The intent of all algorithms is to ensure a strong
coupling of the Abstract Representation with the notation elements of the conven-
tional score. Most algorithms on the AR level deal only with a single voice (G UIDO
sequences), one algorithm deals with the whole piece (G UIDO segments). The order
in which the algorithms are carried out is crucial, because implicit dependencies
are present: some algorithms depend on the output of other algorithms. Figure 4.3
shows, which algorithms have to be performed before others. This is denoted by the
arrows: an arrow pointing from algorithm a to algorithm b means that a has to be
computed before b.

 AutoDispatchLyrics This algorithm goes through a single voice and dis-

patches the lyrics of a nlyrics-tag onto the events within the tag range. It is
essential that this step is performed before any event is modified (which may
happen in the AutoBarlines routine), because the nlyrics-tag is closely tied
to the original G UIDO description.
Example:4 The G UIDO description:
[ nlyrics<"The brown fox jumps o-ver the la-zy dog."> ( c1/4 d e f g g g f d c/2 ) ]
with the matching score

— — —— —— —— —
& _——XÛ— ——XÛ ——XÛ —XÛ —XÛ —XÛ —XÛ —XÛ ——XÛ _——EÛ—
==================== =\
The brown fox jumps o- ver the la- zy dog.

4
All examples in this section are given using G UIDO descriptions. In the actual implementation
all algorithms of this section work directly with the (inner) Abstract Representation. For a better
understanding of the functionality of the algorithms, the equivalent G UIDO descriptions are used.
72 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

AutoDispatchLyrics

AutoBarlines

AutoBreaks

AutoKeys

AutoCheckStaffState

AutoDisplayCheck

AutoBeaming
AutoTies

Figure 4.3: Dependencies of music notation algorithms

is converted to
[ ntext<"The">( c1/4 ) ntext<"brown">( d ) ntext<"fox">( e ) ntext<"jumps">( f )
ntext<"o-">( g ) ntext<"ver">( g ) ntext<"the’>( g ) ntext<"la-">( f )
ntext<"zy">( d ) ntext<"dog.">( c/2 ) ]
 AutoKeys This routine iterates through a voice and checks for changes in key-
signature. This is done, because if the key-signature changes in a score, the old
key-signature must be naturalized. This is done by placing a ARNaturalKey-
object before the changed key, which will later be used to create the corre-
sponding graphical naturalization elements in the score. This routine does not
depend on any other routine.
Example: The G UIDO description:
[ nkey<"E"> e1/4 f# g# nkey<"F"> h& a g f ]
#### nn
is converted to —— ——XÛ— ——XÛ n n b XÚ–– ——XÛ ——XÛ ——XÛ—
XÛ
==============
& – \
[ nkey<"E"> e1/4 f# g# nnatkey nkey<"F"> h& a g f ]
5

 AutoBarlines This is a very important routine that iterates through a voice

and automatically inserts bar lines based on the current meter. The algorithm
looks for meter changes and also for explicitly specified bar lines in the original
The nnatkey-tag is an internal tag which is not part of the official G UIDO specification. It is only
5

used internally to create the graphical elements for the naturalization key in the score.
4.2. MUSIC NOTATION ALGORITHMS 73

G UIDO description. If a time position tp for a new automatic bar line has been
determined, the algorithm must check, whether an event is currently active:
if the onset time of the current event is earlier than tp and the end time of
the current event is later than tp, the event must be split into two events, and
an additional ntie-tag must be added to graphically join the split notes. The
algorithm makes use of all manipulation functions provided by the AR, which
are described in section 3.6 on page 60.
An example for the AutoBarline routine can be seen in Figure 4.1 on page 68.
All of the following algorithms depend directly or indirectly on the output of
this algorithm.

 AutoBreaks This is the only one of the notation algorithms, which requires
a parallel sequential access of all voices contained in the AR as it is described
in section 3.5.2. The AutoBreaks-algorithm does two things: first, it “multi-
plies” nnewSystem- and nnewPage-tags; this means that if a nnewSystem- or
a nnewPage-tag is encountered in one voice, a similar tag is added at the same
time position in all other voices, if no explicit break tag is already present
there. This may result in events being split (similar to the AutoBarlines al-
gorithm from above) in some voices. The second task this algorithm performs,
is to determine “possible break locations”: when traversing the voices in par-
allel, the algorithm looks for possible break positions, which are vertical cuts
through all voices of a line of music that can later be used as line break po-
sitions. For conventional scores, good possible break locations usually are
the common bar lines of all voices. In order to work for all kinds of music,
the AutoBreaks-algorithm does not rely solely on bar lines but evaluates how
“good” a specific time position within a specific voice is suited as a break po-
sition. The “goodness” of a break position for a voice is returned as a floating
point number that is calculated within each voice by taking into account the
current measure position6 – a time position at the very end of a measure is
better suited than a time position within a measure – and checking, whether
an event is active at the given time position. By adding the results for all
voices for a given time position, it can be determined, if the time position is
a suitable possible break location. If such a location is found, a npbreak-tag
(short for potential break) is inserted in all of the voices;7 sometimes, an event
must be split using the manipulation routines of the AR, because of an added
potential break. For conventional scores that have common time signatures
for all voices, this algorithm returns very good results. Nevertheless, problems
arise, if music that has no common time signatures (or no time signatures at
all) is converted into a conventional score. One can easily construct music that
6
Note that each voice may have a different time signature. Even though this is not very common,
it is easily possible to specify such music in G UIDO.
7
The npbreak-tag is again an internal tag that is only used within the described notation system;
it is not part of the official G UIDO specification.
74 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

contains no “natural” break locations. Consider the following (partial) G UIDO

description and the matching score. In this case, the two voices have no com-
mon onset times, because all notes overlap each other.
—— ——— ——— ———
& EÛ—
========= EÛ EÛ EÛ =

«
f [ g/2 g g g : : : ] ,
...

[ g/4 g/2 g g g : : : g ] —— —— —— ——
& XÛ— EÛ—
========= EÛ— EÛ— ... =

In this case, there are no good possible break locations. One solution for the
AutoBreaks-algorithm is to simply leave the issue to the user: no automatic
line breaks would be calculated. Another solution is to simply add npbreak-
tags, if for a certain amount of musical time no “natural” breaks were added
to the music. This sometimes leads to falsely split events, because events are
split at time positions that are later not used as real line break positions; at
least, this solution returns a readable score. The current implementation uses
the second approach.

 AutoCheckStaffStateTags This algorithm iterates through a voice and does

two things: first, it checks, if a nclef-tag is present at the very beginning of
the voice. If not, a nclef is added, because conventional score display is not
possible without a clef that determines the pitch of the notes being displayed.
The algorithm also sorts the clef, key, and meter symbols at the beginning of
a voice; this feature can be turned of by an explicit flag. The second task, the
algorithm performs, is to check, whether nnewSystem- and nnewPage-tags are
followed by correct clef- and key-signatures. If no nclef or nkey-tag is found,
they are automatically added to the voice using the previous valid clef and
key-signature of the voice. This is important because the line-break algorithm
requires the first line after an explicit nnewSystem- or nnewPage-tag to con-
tain complete clef and key information.
This algorithm obviously depends on the AutoBreaks algorithm, because it
looks for nnewSystem- and nnewPage-tags, which might have been added in
the AutoBreaks routine.
Example: the G UIDO description
[ nclef<"treble"> nkey<"F"> c d e nnewSystem f g ]
is converted to
[ nclef<"treble"> nkey<"F"> c d e nnewSystem nclef<"treble"> nkey<"F"> f g ]

 AutoDisplayCheck This algorithm iterates through a voice and checks, if the

events in the voice are displayable as single graphical elements, which means
that there is a one-to-one correspondence between one abstract event and one
notational element of the conventional score.
4.2. MUSIC NOTATION ALGORITHMS 75

There are two reasons for an event not be-

ing directly displayable: either the duration
has a non-regular duration, which means that
the denominator in the events duration is not
take next event
a multiple of two, or the events duration re-
quires more than one graphical element, be-
cause the numerator of the events-duration is
not equal to one, three or seven (if it is three, or duration fits
no (new base is returned)

seven, dots can be used to display the event). cur. ddb?

As an example for these two cases, consider

the following table, where the original G UIDO yes
no
description and the resulting conversions are cur. ddb = 1?

shown. close cur. tuplet

yes
Input Output
[ c*5/8 ] [ ntie( c*1/2 c*1/8 ) ]
open new tuplet
[ e*1/6 f/12 ] [ ntuplet<2,3>( e*1/6 f/12 ) ] and set ddb
to new base
[ e*11/37 ] [ ntuplet<22,37>( e*11/37 ) ]

In order to be able to display irregular du-

rations, a parameter called display-duration-
base (ddb) was introduced. Usually, notes or
rel. duration
displayable no
as single
rests in the graphical score have durations, element ?

which are fractions of multitudes of 2 k (with break event

0  k < 8) as in 12 , 14 , 18 , 161 , etc. The ddb is

(f irst part is
yes displayable)

used as a multiplication factor to determine

the display-duration for an irregular duration.
Let dev be the (irregular) duration of an event.
Then the display duration ddisp of the graphical ddb = 1?
no

note (or rest) is determined by

ddisp = ddb
dev

add duration to cur.
yes tuplet duration

The ddb is set by the ntuplet-tag. Initially,

the ddb is set to one. As an example consider a
no
cur. tuplet

regular triplet: here, the ddb is set to 32 , so that

complete?

the display duration for the event c*1/12 is yes

calculated as
close cur. tuplet

3 1 1
and set ddb := 1

= = ddisp
2 12 8
take next
which means that the event is displayed as an event

eighth-note. This mechanism works for any

event duration: it is just a matter of setting
the ddb to convert the events duration into a Figure 4.4: Flowchart
displayable regular note. The algorithms flow- AutoDisplayCheck
chart is shown in Figure 4.4 on the right.
76 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

 AutoBeaming This algorithm iterates through the events of a voice and de-
termines, which notes can be part of a beam-group. The algorithm strongly
depends on the current meter and also respects explicitly specified beams.
4 j j j
— j
— ——— j
j —— XÚ
Example: the G UIDO description
& 4 _—XÛ —XÛ XÛ— XÛ XÛ XÛ XÚ–––J –––J =
—
========= — — —
[ nmeter<"4/4"> c1/8 d e f g a h c2 ]
is converted to
nmeter<"4/4"> nbeam( 4 — —— —— —— ——— ———XÛ ———XÛ ——XÛ
& 4 _——XÛ —XÛ —XÛ XÛ XÛ
[ c1/8 d e f )
nbeam( g a h c2 ) ] ========= =

 AutoTies This algorithm iterates through a voice and looks for ntie-tags.
As many of the previous algorithms automatically split events and join them
using ntie-tags, this algorithm has to be computed very late. The algorithm
breaks all ntie-tags, which cover more than two events into a series of ntie-
Begin- and ntieEnd-tags that cover two events each. After the algorithm has
been computed, any ntie-tag found in the AR can be represented by one single
graphical tie in the score.
Example: the G UIDO description
[ ntie( c/4 c c ) ] & _——XÛ _——XÛ _——XÛ=\
=====
is converted to
[ ntieBegin:1 c/4 ntieBegin:2 c ntieEnd:1 c ntieEnd:2 ] Corresponding Score

Music Notation Algorithms on the GR level As indicated in Figure 4.2, an-

other set of music notation algorithms manipulates the Graphical Representation
(GR). In order to describe these algorithms, it is essential to first introduce the GR.
Afterwards, the other algorithms are described in detail (see sections 4.4 and 4.5).

4.3 The Graphical Representation (GR)

The Graphical Representation (GR) is an objected oriented class hierarchy, in which
individual classes actually represent graphical entities seen on the pages of the
conventional score. The GR is closely tied to the AR, but there exist quite a number
of classes in the GR for which no direct match exists in the AR: the classes GRStaff,
GRSystem, GRPage, for example, have no counterpart in the AR. This is not really
surprising because an Abstract Representation may consist of a single sequence of
events or markup, which needs to be broken into several systems on different pages
when it is displayed as a conventional score. The GR does not only contain objects
that can be seen on a score but also includes helper (or manager) classes that are
needed during the conversion of the AR into the matching GR, and also during the
manipulation of the GR.
One important aspect during the design of the Graphical Representation was plat-
form independence. As the implemented notation system should be usable on dif-
4.3. THE GRAPHICAL REPRESENTATION (GR) 77

ferent computers using different operating systems, the function calls that produce
graphical output are encapsulated in a small module, which can be adopted for dif-
ferent graphical operating systems without changing the overall layout of the struc-
ture. This issue is not trivial, as each graphical operating system requires different
methods to access information regarding for example the width and height of font
symbols, or offers different capabilities with respect to virtual coordinate spaces
being mapped onto a screen or a printer.
In the following, the graphical requirements for any (conventional) music notation
system will be exemplified. Then, the major classes of the GR will be presented.

4.3.1 Graphical Requirements for Conventional Music Nota-

tion Systems
Regardless of the underlying data structure, certain requirements are common to
all conventional music notation systems. Usually, a conventional score is printed
on several pages, containing lines of music (which are sometimes called “systems”),
which contain one or more staves. A line of music can be vertically sliced into so
called system slices: these slices are important for line breaking, as will be shown
later. Notational elements, like notes, rests, or musical markup are put on top of the
staves. Figure 4.5 shows one page of a conventional score together with a description
of the used notational elements.
When placing a notational element on a page of a score, it is essential to decide on
its frame of reference. In most cases, the frame of reference is the staff on which
a notational element (like for example a note) is placed. Then, the position of the
notational element is specified with reference to the staff it belongs to. A single staff
has the containing system as its frame of reference, therefore the position of a staff
will be specified with respect to the containing system. A system (or line of mu-
sic) will have the page coordinate system as its reference frame on which it will be
placed. Therefore, moving a staff, or a system just requires one explicit change in
position, because all underlying elements are then automatically moved. An essen-
tial requirement for a conventional music notation system is its ability to reflect the
hierarchical order of the relevant notational elements. When dealing with object-
oriented terminology, this idea is reflected in the usage of so called containers, which
are capable of storing other elements.

4.3.2 Structure of the GR

After the graphical requirements have been elucidated in the previous section, we
can now introduce the object-oriented structure of the Graphical Representation.
The developed GR closely follows the requirements shown in the previous section;
especially, the hierarchical order for all notation elements are reflected in the de-
sign of the GR. Figure 4.6 shows a UML diagram for the major classes of the GR;
78 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

One Page of a Score

Pagetext

Staff

System
Slice

Slur split
by line−
break

Line
(System)

Notational Element (Slur)

3
End of Notational
broken Element
slur (Beam)

Notational
Element
Notational
(Tie)
Elements

Figure 4.5: Elements of one page of a conventional score

4.3. THE GRAPHICAL REPRESENTATION (GR) 79

as the current implementation has more than 90 classes, this overview covers only
the most important classes. Almost all of the classes in the GR directly or indirectly
inherit from class GObject, which contains the data and functionality required for
any visible element. The data of GObject includes, for example, a (graphical) posi-
tion and a bounding box.

 Class GRMusic can be found on the bottom left of Figure 4.6. One instance
of this class is created for every score that is being created from a G UIDO de-
scription. As can be deduced from the diagram, GRMusic contains one or more
instances of class GRPage, which represent the pages of the score. To create
the pages and lines of a score, GRMusic “employs” a class GRStaffManager,
which is not shown in the diagram but will be explained below, when the con-
version of the AR into the GR is discussed in detail.

 Class GRPage contains one or more instances of class GRSystem. An instance

of class GRPage knows about its height and width and also about the size of
its margins. Some graphical elements of the score, like for instance the visible
title and composer of a piece are also controlled by class GRPage. Class GRPage
contains one or more instances of class GRSystem.

 Class GRSystem represents a line of music in the score. It is made up from

one or more instances of class GRSystemSlice. When the line breaking al-
gorithm has decided, which slices belong to a system, class GRSystem must
adjust the spacing of the notation elements, and must also adjust its extent
to match the desired line width (spacing and line breaking is dealt with in
sections 4.5.1 and 4.5.2).


—— —XÛ—
Class GRSystemSlice is a part of a single line of music. A
set of GRSystemSlices build a GRSystem. For a simple un- XÛ
derstanding, it is convenient to think of system slices as mea- & XÚ––– =
===
sures of a score. Class GRSystemSlice contains one or more
——
instances of class GRStaff. Class GRSystemSlice is also re-
XÛ—
sponsible for graphical elements that belong to several staves;
this might be, for example, a beam that begins and ends in === Ú
X
& ––– =
different staves, as it is shown on the right.
 Class GRStaff represents a part of a single staff of a line of music. The time
position and duration of the part being represented by an instance of class
GRStaff is directly determined by the containing GRSystemSlice. Class
GRStaff directly inherits from class GRCompositeNotationElement, which
is capable of storing an arbitrary number of instances of class GRNotation-
Element. Using this storage, class GRStaff stores graphical elements being
placed upon it. This might be musical markup, like for example an instance of
class GRClef or a musical event like an instance of class GRNote.
 80

GObject GRTag
is a

contains

0..n
GRNotationElement 2
GRPositionTag
0..n

GRCompositeNotationElement GRARNotationElement GRNoteHead 1

GRStaff GRARCompositeNotationElement GRTagARNotationElement GRPTagARNotationElement

0..n

GRVoice GREvent GRClef GRMeter GRBar GRBeam GRBowing

GRMusic GRSystem GRSystemSlice GRPage GRNote GRSlur GRTie

1..n 1..n 1..n

Figure 4.6: Major classes of the Graphical Representation

CHAPTER 4. CREATING THE CONVENTIONAL SCORE
4.3. THE GRAPHICAL REPRESENTATION (GR) 81

 Class GRTag is the base class for all G UIDO-tags. As can be seen in Fig-
ure 4.6, a G UIDO-tag either inherits directly from class GRTagARNotation-
Element, or it inherits directly from class GRPTagARNotationElement. This
mechanism is used to distinguish between range- and non-range tags (see sec-
tion 3.2.2 on page 47 for a detailed description). As a range tag has a start-
and end-element, class GRPositionTag contains two pointers to instances
of class GRNotationElement. These are used to determine the start- and
end-point for a range tag; for example, the beginning and ending note of a
slur for class GRSlur. Because all tags use multiple inheritance to inherit
not only from class GRTag but also from class GRARNotationElement, all
tags can be contained in one of the composite classes (either GRARComposite-
NotationElement or GRCompositeNotationElement) or their derivatives
(like, for example, GRStaff, or GRSystem, or GRPage).

 Class GRPositionTag is the base class for representing range-tags (as ex-
plained in the previous paragraph). The issue of line breaking is crucial when
dealing with range-tags within the GR: if both the begin- and end-event of a
range-tag are located on one line of music, the graphical object (like, for exam-
ple, a slur) can be created directly. If the begin- and end-event of a range-tag
are located on different lines, then the graphical object must be split into sev-
eral graphical objects. This case can be seen in Figure 4.5, where a slur begins
in the last slice of the second voice in the second line and ends in the following
line: here, the slur, which is represented by only one object in the Abstract
Representation, is broken into two graphical objects. A mechanism within
class GRPositionTag has been implemented to deal with these cases.

 Class GRARNotationElement is the base class for all graphical objects that
have a direct counterpart in the Abstract Representation (which is shown by
using “AR” as part of the name). Consider, for example, class GRClef, which
inherits indirectly from class GRTag and from class GRARNotationElement.
This reflects, that the graphical “clef ” object has a direct counterpart in the AR
(which obviously is an instance of the class ARClef). An example for a class
that does not inherit from class GRARNotationElement is class GRStaff:
there is no class called ARStaff in the AR, because a staff is a purely graph-
ical entity, which is not directly reflected in the underlying abstract represen-
tation.8

The complete set of classes of the GR is too huge to be discussed in detail here. It
should be clear that any visible element of a score has a matching class in the GR.
8
Note that there is a nstaff-tag in G UIDO, which can be used to define the staff on which a voice
is being displayed. Nevertheless, there is no one-to-one correspondence of the graphical staff and the
nstaff-tag.
82 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

4.4 Converting the AR into the GR

Before the AR is converted into the GR, it has been prepared by a multitude of algo-
rithms (see section 4.2), which ensure that the contained abstract music representa-
tion can be easily converted into a conventional score. The actual conversion of the
AR into the GR is a process that is performed by so called Manager-classes: class
GRStaffManager is responsible for creating a set of system slices, which where
introduced in Figure 4.5. A single system slice contains a number of staves, on
which the notation elements (like notes, rests, and musical markup) are placed.
The staves of one system slice are subsequently filled by GRVoiceManager-classes
(one instance of class GRVoiceManager for each voice of the AR), which iterate
through ARMusicalVoice-classes and are also responsible for the creation of the
corresponding graphical elements.
The overall process when converting the AR into GR is depicted in Figure 4.7:
the AR is converted by GRStaffManager and its helper classes GRVoiceManager.
There is one instance of GRVoiceManager for each voice in the AR. The graphical
elements for each voice are created and distributed into the instances of GRStaff,
which are contained in instances of GRSystemSlice. Class GRStaffManager cre-
ates a set of system slices which are finally converted into the Graphical Represen-
tation by another set of music notation algorithms, which are mainly responsible for
spacing, line-breaking and page-filling.

4.4.1 Manager-Classes
The two manager-classes, which play an important role when converting the AR
into the GR, will be presented in more detail in the following.

Class GRStaffManager
An instance of class GRStaffManager is used by class GRMusic to read the data
from the AR and to create a set of GRSystemSlice-classes. GRStaffManager uses
instances of class GRVoiceManager to read the data from the individual voices;
all voices are traversed in parallel, so that notational elements, which need to be
synchronized horizontally, are created in parallel. GRStaffManager is responsible
for the following tasks:

 Creating instances of GRVoiceManager-classes.

 Traversing the voices of the AR in parallel (using the GRVoiceManager-clas-

ses).

 Creation of springs and rods for the spring-rod-model, which will later be used
for spacing and line breaking; details of this model are described in section 4.5.
4.4. CONVERTING THE AR INTO THE GR 83

Abstract Representation:
Class GRStaff
reads
ARMusicalVoice Class GRVoiceManager
Class GRStaff
...... ...... Class GRStaff
reads
ARMusicalVoice Class GRVoiceManager
Class GRStaff ......
Class GRStaff
......
Class ARMusic
Class GRStaffManager
Class GRStaff
Class GRSystemSlice
creates set of
Class GRSystemSlice

Notation Algorithms II
(Spacing, Line Breaking)
Graphical Representation:

GRPage
Class GRStaff GRSysSlice

Class GRStaff GRSytem GRPage

GRSysSlice
Class GRStaff
GRPage
GRSysSlice
Class GRSystemSlice GRSytem
GRPage
Class GRSystem

GRPage
Class GRPage

Class GRMusic

Figure 4.7: Converting the AR into the GR

84 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

 Assigning a spring to each notational element, which is created by the GR-

VoiceManager-classes; this task includes determining, which graphical el-
ements are connected to the same spring. This is required to horizontally
synchronize elements at equal time positions (like for example clefs or note
heads).

Class GRVoiceManager

As indicated above, class GRStaffManager creates a set of instances of class GR-

VoiceManager. Each instance of GRVoiceManager iterates through one class AR-
MusicalVoice. For each event or tag that is found in the voice, an equivalent
graphical element is created by class GRVoiceManager. The graphical elements
are sent to class GRStaffManager, which is responsible for placing the elements on
the staff. Because every event or tag is contained in a voice – there is no external or
global header in G UIDO – all tags that have global relevance, like for example the
npageFormat-tag, is directly sent to class GRStaffManager, which is then respon-
sible for processing the information.

4.4.2 Other helper classes

Some other classes, which have no direct graphical counterpart, are used during
the conversions from the AR into the GR. Class GRSpaceForceFunction, class
GRSpring, class GRRod, and class GRPossibleBreakPosition are mainly used
for spacing and line-breaking. The details of this will be explained in sections 4.5.1
and 4.5.2. An instance of class GRPossibleBreakState is created every time a
npbreak-tag is encountered in a voice (see section 4.2). This object saves the com-
plete state of all staves at the current time position; if the position is later used as a
line-break location, the saved information is used to create the graphical elements
at the beginnings of the staves in the next line. The required information is mainly
the current clef, the current key signature and the current time signature. It is also
essential to remember, which tagged ranges are currently active. In the case of a
slur or a tie, the correct endings and beginnings have to be created.
Another class, which saves state information is class GRStaffState. It stores the
current state of an instance of class GRStaff. Because different voices can be writ-
ten on the same staff, it is essential that the current state of a staff is always acces-
sible. The information of class GRStaffState is for example used, to determine the
vertical position of notes by comparing the pitch and register information with the
current clef. Class GRStaffState keeps also track of the current position within a
measure (which depends on the current meter), and the current key signature.
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 85

4.5 Spacing, Line Breaking, and Page Filling

Even though music is perceived as a continuous stream of musical events, a tradi-
tional score is not printed on a continuous roll of paper, but is rather printed like
a book. A score is usually printed on several pages, which contain multiple lines
(which are sometimes called systems in the context of music notation), which in
turn are made up from one or more staves. The decision where to introduce line
breaks in music scores is analogous to line breaking in traditional text processing.
It might seem that the problem of optimum line breaking in text and optimum line
breaking in music is similar; unfortunately, the issues involved in music typesetting
are more complex than in plain text formatting, as will be shown in the following
section. Therefore, many of the elegant principles used in text setting can not di-
rectly be used when dealing with musical scores.
Three essential tasks must be performed when setting music:
1. Deciding where to break the lines of a score. This is called line breaking.
2. Distributing the space between graphical elements of a single line of music.
This is called spacing.
3. Connected to line breaking is the task of distributing the lines of a score in
such a way that all printed pages are full. A traditional score usually ends at
the end of the last page. The problem of finding line breaks so that all pages
are full is called page filling.
While the first of these tasks has a somewhat strong connection to text formatting,
the second task is far more complicated when dealing with music and the third task
is usually not needed when setting text. In standard text formatting, a single line of
text is stretched or shrunk so that its width fits the desired paragraph width. This
is accomplished by stretching or shrinking the white-space between the words in
a uniform way.9 In music typesetting, the space between notational events (notes,
rests, markup etc.) is primarily determined by the duration of the respective event:
a half note is followed by more space than a sixteenth note, for example. Addi-
tionally, simultaneous events in different voices must be printed vertically aligned,
something that usually only occurs when formatting tables in standard text for-
matting. When setting music, special attention has to be given to detecting and
preventing collisions of different notational elements: in some music, there is more
than one voice being displayed on a single staff. In this case, collision detection and
prevention can be very complicated.
In the following section, spacing of a single line of music and line breaking will be
explained in detail. Furthermore, it is shown how optimal page fill can be realized.
Wherever appropriate, a comparison to standard text formatting will be made.
9
In TEX, white-space after punctuation marks is treated differently than white-space between
words. In general, the parameters required for stretching and shrinking can be calculated fairly
easily.
86 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

4.5.1 Spacing
When typesetting music, the issue of distributing leftover space in between the
graphical elements of a line is fundamental for obtaining good and esthetically
pleasing results. In the following, approaches for human and automatic spacing
are described. An improved algorithm for spacing, which was developed as part of
this thesis, is presented.
In order to estimate, how “good” a spacing algorithm performs its task, it is essential
to define, what constitutes good spacing. Helene Wanske defines the requirements
for spacing as follows [Wan88]:

1. Spacing should follow the rhythmical structure of the music.

2. The rhythmical interaction of multiple voices must be clearly recognizable in

the score.

3. The line up of notational symbols shall be optically balanced.10

4. The disposition of notational symbols depends on printing requirements: a

certain amount of music has to be put on one page and respectively on one line
of music; the lines of music shall be justified.

5. The overall impression of a score page shall be smooth; there shall be no “black
clusters” nor “white wholes”. Any “surprise-effects” shall be prevented. Nev-
ertheless, the disposition of notational elements on one page shall follow eco-
nomic considerations.

These rules are ranked according to their importance for music notation. They are
definitely “fuzzy”, and it is generally not clearly decidable, whether a line of music
is “good” or “better” spaced than another one. During the work on this thesis, the
primary goal was the automatic calculation of spacing as it is found in “real” scores,
which have been produced by human engravers. In most cases, different editions
of one piece of music can be found. Often, these editions differ in the used musical
font and almost certainly in differences in spacing. Therefore, a secondary goal was
the ability to adjust the spacing algorithm to suit the users need. One thing that
needs to be kept in mind is that different readers may require different scores: it
is probably much easier for a professional musician to read a tightly spaced score,
whereas someone learning to read music notation clearly is better off with loosely
spaced music.
In conventional music notation, the space after a notehead (or a rest) depends pri-
marily on the duration of the event. Traditionally, these relationships are specified
with respect to the note durations of 16 1
: 18 : 41 : 12 . Different engravers have used
10
Wanske gives several examples where a spacing, which is calculated strictly according to the
given rhythmical structure, may lead to lines that appear to be unequally spaced. A line of music is
“optically balanced”, if equal note durations are perceived to be equally spaced by a human reader.
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 87

slightly different relationships between note duration and space. Helene Wanske,
who gives a thorough11 overview on (human) spacing, specifies a relationship of
1 : 1:4 : 1:8 : 2:2 meaning that an eighth note is followed by 1:4 times more space
than a sixteenth note [Wan88]. When calculating the values for a fixed distance of
5mm for the space after a sixteenth note, the resulting music notation can be seen
in Figure 4.8. These values give only a rough guideline for the actual engraving of
music: in most cases, additional symbols (like for example accidentals) or the need
of vertically aligning different voices leads to different amounts of white space af-
ter noteheads or rests. Additionally, when spacing different voices with unorthodox
note durations (for example a triplet versus a quintuplet) the individual tuplet-
groups should be spaced evenly (this is a consequence of Wanske’s third spacing
rule).

Figure 4.8: Spacing with Wanske relationship

Automatically spacing a line of music has been discussed quite often in the past
[Byr84, Gou87, BH91, HB95, Gie01]. The most important contribution to the prob-
lem was given by Gourlay in 1987. His spacing model, which in turn was inspired by
Donald Knuth’s work on TEX [Knu98], seemingly builds the basis for a large number
of the currently implemented notation systems.12 His model can be described as a
spring-rod-model:13 a line of music is interpreted as a collection of springs with some
spring constants on which a force is exerted to stretch or shrink the line to a desired
length. Rods are introduced to ensure that noteheads and musical markup (like for
example accidentals) do not collide, especially when spacing is tight. The rods are
used to pre-stretch the springs to have a guaranteed minimal extent. In contrast to
formatting text, the issues found in formatting music are more complex. Because si-
multaneous voices must be vertically aligned, a spacing algorithm must be capable
of handling overlapping note durations in different voices while still maintaining a
spacing that closely follows individual note durations.
11
The section on spacing covers 46 pages! (pages 107-153)
12
Obviously, it is not really possible to detect the implemented spacing algorithm for software that
is distributed without the source code.
13
The original article by Gourlay does not use the word “springs” but speaks of boxes and glue,
which in turn was inspired by TEX. We find that the term “spring” more closely corresponds to the
physical model being used.
88 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

——XÛXj
——— —— b ÚX ——— ————
& Û XÛ ––– b XÛ=
==== # XÛEÛ—
Force 0
—— Xj
——Û —— b Ú–X b ——XÛ —— ——
Û
X
======
& XÛ –– # XÛ —EÛ
Force 350
——— Xj
—— —— b XÚ —— —— —
& XÛ Û —XÛ ––– b XÛ # —XÛ —EÛ =
=========
Force 690
——XÛ j
——— —— b ÚX ——— —— ——
ÛX XÛ ––– b XÛ # XÛ EÛ— =
===========
&
Force 850

Table 4.1: Demonstrating the effect of applying different forces

The basic idea of Gourlays’ algorithm can be summarized as follows: a single line
of a score is interpreted as a list of onset times, which is sorted by time position; an
onset time occurs whenever a note or rest begins in one of the voices. In order to de-
termine the correct amount of space to put in between the onset times, springs are
inserted between successive onset times. In order to stretch (or shrink) the line to
its desired length, a force is exerted on the whole collection of springs. Each spring
is then stretched (or shrunk) depending on the external force and the individual
spring constant, which mainly depends on the spring duration14 and on the dura-
tion of notes (or rests) being present at the time position of the spring. Hooks’ Law
describes, how a force F , an extent x and a spring constant c are related: F = c
x.
To avoid collisions of noteheads, accidentals, and other musical markup, rods are
introduced, which determine the minimum stretch for one or more springs. The
spring-rod-model generally agrees very well with Wanske’s spacing-rules, which
were defined at the beginning of this section. Almost all essential requirements
for spacing are automatically fulfilled, when the model is used.
Table 4.1 shows a short musical example together with the associated springs and
rods. The springs are shown above the line of music, the rods are shown below. It is
demonstrated, how different forces are applied to the same line of music. When the
applied force is zero, the rods prevent the notated symbols to collide horizontally.
As the force increases, more and more springs are stretched further than the extent
14
The “spring duration” is the temporal distance of the two onset times in between which the spring
is placed.
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 89

of the rods. At Force 690, all springs are stretched further than the pre-stretch
induced by the rods.
—— ——— The spring-rod-model also works very well for multi-

& XÛ ## =
—XÛX voiced music: because rods are created separately for
=== each voice (or staff), notational elements of different
voices/staves may overlap horizontally, as long as ex-
tent of the combined springs is at least as wide as

& XÚ––– XÚ––– =

XÚ–– XÚ–– the rod extent. Figure 4.9 shows, how two voices are
=== – – spaced using the spring-rod-model. The accidentals of
the chord in the first voice have the same horizontal
position as the second eighth note of the second voice.
Figure 4.9: Overlap of This exactly matches common rules for music nota-
notational elements tion.
It will be shown later in this chapter, how the individual spring constants for a
given line of music are calculated. In order to better understand the workings of
the underlying physical model, lets assume that the spring constants have already
been calculated. Then, a line of music can be spaced by exerting a force on the
(sequential) collection of springs. Because in musical scores, all lines are usually
justified, an algorithm is required, which calculates the force required to stretch a
line of music to a given width.
To calculate how springs in series react to a certain force, an overall spring constant
is determined using this formula:
1
c= P
n (4.1)
1
ci
i=1
The overall spring constant can then be used in Hooks’ Law as before: x = Fc . Fig-
ure 4.10 shows an example of three springs with three different spring constants.
The applied force is f = 15, stretching the series of springs to an overall extent of
10cm. When the three springs are replaced by one spring and the same force of
f = 15 is applied, then the new spring constant must be c = 10 15
= 1:5, which is
exactly what equation (4.1) evaluates to for the 3 individual springs.
When dealing with the springs in a line of music, an additional fact has to be taken
into account: as was shown before, springs can be pre-stretched by rods. In this
case, a spring has a pre-stored extent and a pre-stored force. For example, consider a
spring s with spring constant c that is pre-stretched to length xp . Then the resulting
pre-stretching force Fp is computed as
Fp = c
xp
If an external force Fe is applied to the spring s, the new extent can be calculated
as: 
x(Fe ) = xFp if Fe  Fp
e
c if Fe > Fp
90 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

b b b b

x1 = 5cm x2 = 3cm x3 = 2cm

c1 = 3 c2 = 5 c3 = 7:5
f = 15 f = 15 f = 15
b b

x = 10cm
c = 1 + 11 + 1 = 1:5
1 2 3
c c c

f = 15
Figure 4.10: Connected springs

This means that the spring will only be stretched further by an external force Fe , if
Fe is greater than the pre-stretching force Fp. Otherwise, the extent will just be the
pre-stretched extent xp .
Therefore, when dealing with a series of springs from a line of music, the overall
spring-constant depends on the applied force and the pre-stretched springs: only
those springs are further stretched, whose saved force is smaller than the applied
force, and therefore, the overall spring constant must be computed using only these
springs. The other springs just add their pre-stretched extent.

The Space-Force-Function
To efficiently compute the force required to stretch a line of music a so called space-
force-function was defined and implemented during work on this thesis. This func-
tion calculates the force required to stretch a line of music to a given extent. Evi-
dently, the pre-stretching of springs is taken into account. The space-force function
being introduced here, is extensively used in line breaking and page filling, which
will be described at the end of this chapter.
Given a set of springs S = (s1 ; : : : ; sn ) with respective spring constants ci and pre-
stretch xi for 1  i  n, the space-force-function s : extent ! force calculates the
required force to stretch the springs to a given extent:

x xmin 1 X
s (x) = =f with c = P and xmin = xi (4.2)
c 1
ci in
1in
1

ci
xi f c
x >f
i i

It is obvious that s in equation (4.2) cannot be computed directly, because the exact
values for c and xmin , which are required to calculate s can only be determined
when the overall result for s has already been computed. In order to compute the
function, a pre-processing step is performed, which sorts the set of springs by their
respective pre-stretching forces. Additionally, the sum of all pre-stretched spring
extents is computed. Then, the calculation of s simply requires a traversal of the
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 91

ordered set: Let S = (s1 ; : : : ; sn ) be a set of springs with their respective spring
constants ci and pre-stretching force fi and pre-stretching extent xi = fc (for 1  i 
i

n). Let S be ordered, so that for all i  j we have fi  fj . Algorithm 1 computes the
i

required force for a given extent.

Algorithm 1 s : Determining the required force for a given extent

Require: x > 0 fx is the extentg
Require: 9c = (c1 ; : : : ; cn ) spring constants
Require: 9x = (x1 ; : : : ; xn ) spring extents
Require: 8 i; j; 1  i  j  n : xi
ci  xj
cj
fPre-calculate the minimum extent:g
fThis is the sum of all pre-stretched springsg
Pn
xmin := xi
i=1
if x  xmin then fThe extent is smaller than the pre-stretched springs;g
return 0; fTherefore, the required force is 0g
end if
fInitialize the spring-constantg
c := c1 ;
for i := 1 to n do fEach spring is taken from the ordered setg
xmin := xmin xi ; fThe pre-stretched extent is subtractedg
f := x xcmin ; fThe force is calculated using the current spring-constantg
if i = n or f  fi+1 then fWe are at the very last spring or the force ofg
return f; fthe next spring is bigger than the required forceg
end if
fAdjust the spring constant for the next cycleg
c := 1 + 1 1 ;
c ci+1
end for

The space-force-function is a strictly monotonic rising, piece-wise linear function.

Figure 4.11 shows a sample space-force-function for a short line of music, which
is stretched using three different forces. In the graph of the s , it can be clearly
seen how the individual notes have differing pre-stretching forces, depending on the
spring-constant. The smaller valued notes have bigger spring constants, therefore,
pre-stretching these notes requires more force than pre-stretching the notes with
longer durations. When a force of 400 is applied (first line of music in Figure 4.11),
the 16th-notes are just stretched marginally, while the 32nd-notes are not stretched
at all. The 32nd-notes do not overlap only because of the existing rods.
The inverse function of the space-force-function, which determines an extent for
a given force, can be calculated similar to the above procedure. In this case, the
(ordered) set of springs is traversed until the line-segment of the s is found, that
matches the given force. Then, the concrete value is calculated using the spring
constant for this section.
92 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

4000
f=1200

3000

1/32 f=800

Extent
1/16
2000
1/8

f=400
1000

0
0 200 400 600 800 1.000 1.200
Force

Force: 400 Extent: 1687,48

Force: 800 Extent: 3048,84

Force: 1200 Extent: 4419,76

Figure 4.11: The Space-Force-Function

Gourlays’ Algorithm for Spacing

This section gives a brief overview of Gourlays’ algorithm for spacing a line of music
[Gou87] and briefly discusses additional publications and notation systems based
on it. Obviously, some of the details of Gourlays’ algorithm are omitted to focus on
the relevant issues being improved later.
Calculation of spring constants: The calculation of spring constants in Gour-
lays’ algorithm, which will be modified by our improved algorithm, needs to be ex-
amined more closely. Basically, the space placed after a note (or rest) solely depends
on the duration of the event: there is generally less space placed after a sixteenth
note than after a whole note. A suitable way to calculate the actual amount of space
for a given duration d is given by the formula
 
d
space(d) = (d)
space(dmin ) where (d) = 1 + a
log2 (4.3)
dmin
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 93

where a is some constant (usually in the range of 0:4 and 0:6), and dmin is some
smallest duration for which the required space is predefined. In current notation
software (like, for instance in Finale, LilyPond, etc.) quite a number of minor vari-
ations of this scheme are actually implemented (see for example [Gie01]), but the
general principle of using a logarithmic function for calculating the required space
is agreed upon widely. Tweaking the parameters for a and dmin results in slightly
different spacing and it is usually a matter of personal (or publishers) taste, which
values to use.
The formula for (d) is also used to determine the spring constants for a given line of
a score: Let s be a spring between two successive onset times o1 and o2 . The resulting
spring duration ds is simply ds = timeposition(o2 ) timeposition(o1 ). Let di be the
shortest duration of all notes (or rests) beginning or continuing at timeposition(o1 ).
Then the spring constant c is calculated as
di 1
c=

ds (di )
space(dmin)
(4.4)

Gourlay introduced this formula in order to get optimal spacing even when rhyth-
mically complex structures (like tuplets versus triplets) are present. In the case of
monophonic pieces, the formula simplifies to
1
csimple = 1

(ds )
space(dmin)
because di = ds . Using this simple spring constant and putting it into Hooks’ Law
with a force F = 1 and a duration of ds equal to dmin stretches the spring to the
extent
F
x = = 1
(dmin)
space(dmin) = space(dmin)
c
which is exactly the expected result.
As indicated above, a number of variations of Gourlays’ algorithm have been pro-
posed. The newest publication on spacing a line of music is by Haken and Blostein
[HB95]. They were the first to actually use the terms “springs” and “rods”. Even
though their terminology is different, the general ideas of Gourlay are present. The
only significant difference lies in the handling of rods, which are called “blocking
widths” by Gourlay. Haken/Blostein introduced an elegant way to pre-stretch the
springs using a two-step process: first, only those rods are considered that only
stretch one spring. Then the remaining rods (which all span more than one spring)
are checked. In this phase, the required force to stretch a chain of springs to the de-
sired rod length is calculated. The rod requiring the maximum force is applied first;
other rods stretching the same springs can be discarded. This procedure is more effi-
cient than Gourlays’ original algorithm, which just iterates through all rods without
pre-sorting.
GNU LilyPond, a musical typesetting system based on TEX [NN01], is also using
Gourlays’ algorithm for spacing a line of music. One interesting detail of LilyPond’s
94 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

spacing is the fact that the value for dmin in equation (4.3) is determined separately
for each measure. This sometimes leads to an uneven spacing of measures, which
might be musically misleading as shown in Figure 4.12, where the general rhythm
of measures one and two is quite similar, but the spacing is very uneven.15

Figure 4.12: LilyPond spacing problem

A recently published dissertation on the automatic generation of scores [Gie01] uses

the following formula
1
c= (4.5)
maxf ds
d
(d)g
space(dmin)
Where d is the duration of any note (or rest) beginning or continuing at the spring.
When using the standard formula for , the maximum for the term in equation (4.5)
always occurs for the shortest duration (the term di in equation (4.4)). Therefore,
equation (4.5) is similar to Gourlays’ original proposal.
The spacing algorithms used by commercial notation
software are usually not disclosed: therefore, a small
number of spacing tests were performed with the
two most popular systems Finale and Sibelius.16 In
the case of Finale, it seems like some variation of
Gourlays’ algorithm is used: the obtained spacing for
rhythmically complex pieces is generally very good.
Sibelius, on the other hand, created awkward spacing
even for some rather simple examples. It seems like
the used algorithm does not allow noteheads to over-
lap horizontally, even if they are in completely inde- Figure 4.13: Spacing in
pendent voices. Figure 4.13 shows, how Sibelius fails Sibelius
to space a rhythmically complex measure in an accept-
able way: the spacing of the individual voices is com-
pletely irregular.

Spacing Problems in Gourlays’ Algorithm

Gourlays’ algorithm for spacing a line of music calculates good spacing on a large
body of musical scores. Because of its wide spread use, it was therefore somewhat
15
Obviously, it can be argued, whether a spacing like this is desirable or not.
16
For our tests we used Finale 2001b and Sibelius 1.4
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 95

surprising to detect that Gourlays’ algorithm (and therefore all of its direct descen-
dants) fails to produce good spacing in certain situations. The reason for these de-
ficiencies stems from the fact that sequential individual notes with equal duration
might be spaced unevenly because of simultaneous notes in other voices. As stated
above, the coupling of note duration and spacing is very strong, therefore notes with
equal duration should be spaced equally whenever possible.17 Because these cases
do occur in real scores (and also in computer generated music), a solution to the
problem was searched for and found. This solution led to an improved algorithm
for optimally spacing a line of music that automatically detects and corrects the
above mentioned spacing errors. First, groups of notes with equal duration are de-
termined in the score. Then, for each such group it is checked, whether the original
Gourlay algorithm creates spacing errors. If this is the case, an alternate spacing is
calculated and applied, if certain tolerance conditions are met.
Figure 4.14 shows, how the improved spacing algorithm (b) compares to Gourlays’
original algorithm (a): The spacing of the triplet in the first voice is exactly equal
when the improved algorithm is used. This effect is highly desirable, because the
graphical appearance of the triplet now directly conveys that each individual triplet
note has equal duration. When using the original spacing algorithm (a), the space
between the first and the second note of the triplet is significantly greater than
between the second and the third note, even though their duration is equal. We call
this error a “neighborhood spacing error”.

(a) (b)
Figure 4.14: Gourlays’ original algorithm (a) compared to the improved spacing
algorithm (b)

The reason for the unequal spacing can be seen rather easily: Figure 4.15 shows a
rhythmically simpler example together with the created springs and their respec-
tive calculated spring constants. In Figure 4.15 (a) the first triplet note spans two
1 1
springs (s1 and s2 ) with spring constants c1 = 161
(11 ) = (11 ) and c2 = 121
(11 ) =
16 16 16 48 12
4
1 . When combining s1 and s2 into a combined spring s1;2 the spring constant c1;2
(12)

17
This can be directly derived from Wanske’s third spacing rule of section 4.5.1 on page 86. When
dealing with scores that contain rhythmic complexity, this rule may have a rather low priority. Nev-
ertheless, it should be applied wherever possible.
96 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

Springnumber 1 2 3 4 Springnumber 1 2 3 4 5 6
Springduration (d s) 1/16 1/48 1/12 1/12 Springduration (d s) 1/16 1/48 1/24 1/24 1/48 1/16
Smallest duration (d i)1/16 1/12 Smallest duration (d i) 1/16 1/16 1/16 1/16 1/16 1/16
1/12 1/12 Springextent 4.33 1.45 2.89 2.89 1.45 4.33
Springextent 4.45 1.25 5.0 5.0
3
3

5.7 5 5

(a) (b)
Figure 4.15: Spacing of Gourlays’ algorithm including springs

is calculated using equation (4.1) as

1 1
c1;2 = = 1
c1 + c2 ( 16 ) + 14 ( 121 )
1 1

It is obvious, that the spring constant c1;2 is not equal to c3 = c4 = (11 ) . Therefore,
12
when a force F stretches the line, the springs s1 and s2 are stretched to the extent
x1;2 = Fc = F
( ( 161 ) + 14 ( 121 )) and the springs s3 and s4 are both stretched equally
to x3 = x4 = F
( 12 1
). Clearly, x1;2 and x3 (and x4 ) are not equal.
To understand, why this error does not occur in the standard 3 against 4 case (see
Figure 4.15 (b)), one must understand how the fraction dd in equation (4.4) is sup- i
s

posed to work: consider Figure 4.15 (b), which differs from (a) by replacing the
second voice with four sixteenth notes. Now, the value of di for each of the springs is
1
16
, so that each spring is stretched as a partial of a sixteenth-note spring. To clarify
this, consider springs s2 and s3 of Figure 4.15 (b). The respective spring-constants
1 1
are c2 = 161
(11 ) = 31
(11 ) and c3 = 161
(11 ) = 32
(11 ) . When combining springs s2
48 16 16 24 16 16
and s3 the spring constant is
1 1
c2;3 = = 1
1
3
( ) + 3 ( 16 )
1
16
2 1
( 16 )
The result is, that the springs s2 and s3 are stretched so that their sequential com-
bination behaves just as a single spring for one sixteenth note. The same is true
for springs 4 and 5. Subsequently, the springs s1 , s2;3 , s4;5 , and s6 all have a spring
constant of (11 ) so that the sixteenth notes of the second voice of Figure 4.15 (b)
16
are spaced evenly. Regarding the first voice of Figure 4.15 (b), the respective spring
constants c1;2 , c3;4 , and c5;6 are all equal to 34
(11 ) , so each note gets the same amount
16
of space.
One other spacing problem of Gourlays’ algorithm concerns lines of music that are
spaced very loosely. Consider Figure 4.16, where a single line of music has been
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 97

stretched rather heavily. In this case, Gourlays’ algorithm (a) results in unequal
spacing of the eighth-notes in the second voice: because of the 32nd notes in the
first voice, the first eighth-note of the second voice is followed by much more space
than the following ones, which are all spaced equally. The improved algorithm (b)
distributes the space evenly.

(a)

(b)

Figure 4.16: Loose spacing: Gourlay algorithm (a) and improved algorithm (b)

An Improved Spacing Algorithm

It can be deduced from the last section that, for solving the neighborhood spacing
problem, an algorithm must automatically detect those regions of springs, where
spacing errors might occur and then set an appropriate value for di only for the
relevant regions. This is exactly what our proposed improved spacing algorithm
does, which is now described in detail:
1. The original algorithm of Gourlay for the given line of music is carried out.
For each spring, the value d1 from equation (4.4) is saved, instead of directly
i

calculating and saving the spring constants.

2. For each voice the location of neighborhoods of notes with the same duration
are determined.
3. Each of the calculated neighborhoods from step (2) is checked for neighborhood
spacing errors. This is done by averaging over the values di for each spring
covering a note in the neighborhood. If the average value differs for any note
of the neighborhood, a spacing error is detected.
4. For all error regions of step (3), it is checked to see whether any other neighbor-
hood reaches into it; if this is the case, then the boundary of the error-region
98 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

is extended to also cover the new neighborhood. This step is necessary so that
the fixing a spacing error in one of the error-regions does not introduce a new
spacing error in another voice.
5. For the finally determined error-regions of step (4), three spring constants are
calculated: the spring constant for the original Gourlay algorithm, the spring
constant for using an average of the di , and a spring constant which uses the
minimum di for the whole region.
6. The difference of the original Gourlay constant and the average constant is
determined. If it is within a tolerance band (less than 0.05), then the average
value for di is taken for the region. Otherwise, the difference of the origi-
nal constant and the minimum-di -constant is calculated. If this difference is
within another tolerance band (less than 0.17), then the minimum duration of
the region is chosen as di . Otherwise the original Gourlay value for di is chosen
for the region.
7. Before a line is finally spaced, an additional step is performed to avoid the
wrong spacing of loosely spaced lines. This is done by determining, whether
any note with the smallest note duration of the whole line is followed by more
than two noteheads of white space using the calculated spring constant. If this
is the case, the smallest note duration for the whole line is taken as a value for
di and the spring constants for the line are recalculated accordingly.18
The values for the tolerance bands for step 6 of the algorithm have been chosen
through various experiments. Figure 4.17 shows an example for taking the average
(a), the minimum (b) and the original Gourlay value (c). Although the neighborhood
spacing error in the first voice is removed in cases (a) and (b), choosing the average
value results in too little space for the short notes in the beginning of the second
voice. Choosing the minimum duration (b) results in a spacing, which is too wide.
In this example, the original Gourlay algorithm (c) gives the best result, although
the neighborhood spacing error in the first voice is clearly visible. The tolerance
bands are indications, when to tolerate a neighborhood spacing error so that the
overall spacing remains acceptable.
To see, how the algorithm solves the neighborhood spacing problem of the last sec-
tion (see Figure 4.15 (a)), we give a trace of the improved algorithm.
1. The original Gourlay algorithm is used to determine the values d1 for each
spring: 16; 12; 12; 12. These values can be found in Figure 4.15 (a).
i

2. The first voice has a neighborhood list of (1; 3; 4; 5) which means, that the notes
covering springs 1 up to 3 (not including the last value) and 3 to 4 and 4 to 5 are
1
successive notes having the same duration (in our example this is 12 ). There is
no neighborhood list for the second voice.
18
This step was performed to obtain the result of Figure 4.16 (b).
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 99

(a) (b) (c)

Figure 4.17: Showing the effect of choosing different relative duration values

3. The neighborhood list (1; 3; 4; 5) is checked for spacing errors: the average for
the first note (going from springs 1 up to 3) is 16+12
2
= 14, the average for the
second and third note is both 12. Therefore, a spacing error is detected.
4. Because there are no more neighborhoods, the error region reaches from spring
1 up until spring 5.
5. The three spring-constants are calculated: sgourlay = 1:81665, sminimum = 1:60325,
saverage = 1:81631.
6. The difference jsgourlay saverage j = 0:00034 is within the tolerance band. There-
fore, the average value for d1 = 16+12+12+12
i 4
= 13 is chosen. Spacing is done, as
if the smallest duration is a 13th note.
The resulting spacing can be seen in Figure 4.18 (a) and (b), which also shows a
comparison to the old Gourlay algorithm (c).
Springnumber 1 2 3 4
Springduration (ds) 1/16 1/48 1/12 1/12
Average duration (di)1/13 1/13 1/13 1/13
Springextent 3.93 1.31 5.24 5.24

(a) Improved (b) Improved (c) Gourlay

algorithm with algorithm algorithm
springs
Figure 4.18: Correction of neighborhood spacing errors by the improved algorithm

To show that the algorithm not only concerns somewhat constructed examples, Fig-
ure 4.19 shows a two-measure excerpt from a fugue by J.S.Bach (BWV 856) as it is
spaced by Finale (a), the improved algorithm (b) and in the Henle Urtext edition
(c), which has been spaced by an expert human engraver [vI70]. It is clearly visible,
that (b) and (c) strongly emphasize on the equal spacing of the eighth-notes in the
bass voice of the second measure, whereas the spacing algorithm of Finale19 spaces
19
Finale spaces this example similar to Gourlays’ algorithm.
100 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

the first eighth note tighter than the following two. Of course it can be argued,
whether the spacing of (b) and (c) is better than the spacing in (a); it is surely a mat-
ter of personal taste and also of musical semantics which spacing is preferred. The
point made here is that any spacing algorithm should be adjustable to accommodate
personal preferences.

0,9cm 0,9cm
0,71cm
0,9cm 0,9cm
0,91cm
(b) (c)
(a)
Figure 4.19: Bach fugue BWV 856: Finale (a), improved algorithm (b), hand en-
graver (c)

4.5.2 Line breaking

Line breaking is the process of determining the optimum positions where to break
the lines of music so that the resulting score looks esthetically pleasing, which de-
pends largely on the following:
1. The individual lines of the score are neither spaced too tight nor too lose.

2. If the piece covers more than 1 page, the individual lines should be created so
that the score covers all pages (including the last one) completely.

3. The locations where page turns occur are musically sensible: positions with
less activity should be preferred over passages where a lot of notes are being
played.
While the last of these points is far from being solved by any automatic system for
music notation, the other two can be tackled. As Hegazy and Gourlay have pointed
out in [HG87], the process of optimal line breaking in music is strongly related to
line breaking in conventional text typesetting. The most relevant research in this
area has been carried out by Donald Knuth [Knu98] and its results are part of the
TEX typesetting system. In music typesetting the work of Hegazy and Gourlay is the
first to cover the issue. Their ideas are derived from Knuth, but as will be shown
in the following section, the problem is a little more complex in music typesetting
than it is when setting text. Although the issue of page filling (second item from
the above list) is related to optimal line breaking, there exists no publication on the
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 101

subject, even though the music notation system SCORE by Leland Smith [Smi97]
contains an (unpublished) optimal page fill algorithm. While working on this thesis,
an algorithm for optimal page fill was developed. Because it is an extension to the
optimal line breaking algorithm proposed by Hegazy and Gourlay, we will first give
an overview of Knuths’ original algorithm for line breaking in text, then the Hegazy-
Gourlay algorithm for optimal line breaking in music is being presented. The new
optimal page fill algorithm will be presented in a separate section below.

Line Breaking in Text Paragraphs or Learning from TEX

Because the ideas of finding the optimum line breaks in text form the basis for
deciding on the optimum line breaks in music, this section gives a short overview of
the fundamental ideas applied there. First, a (simplified) mathematical description
of the problem is given; then, the basic steps to solve the stated problem are shown.
The actual algorithm given by Knuth is more complex, because it has been fine-
tuned to cover a great variety of problems found in setting texts. For understanding
the basic ideas, the following description should be sufficient.
A paragraph may be seen as a sequence of n words (n > 0), fw1 ; : : : ; wn g. Each
word wi has a (natural) length li > 0. Each word is separated from the next by
white-space. To get justified output, the space between words can be stretched or
compressed.20 For simplicity reasons, we assume that all lines of the paragraph
ought to have equal length given by D . The task is to find a sequence of indices
B = fb0 ; b1 ; : : : ; bk g that determine which word ends on which line: wb1 is the last
word of the first line, wb2 is the last word of the second line, and so on. b0 is always
equal to zero and bk is always equal to n (this means, that the last word of the last
line is the last word of the paragraph). It should be clear that for all i with 0  i < k
we have bi < bi+1 (B is a strictly monotone rising, ordered list) and that for all i with
1  i  k we have bi 2 f1; : : : ; ng. The sequence B breaks the lines of the paragraph
in an optimal way, if the amount of stretching or compression of the space between
words is minimized.
Let s be the natural amount of space between Pj words. Let Li;j be the sum of the
lengths of the words from wi up to wj : Li;j = k=i lk . Putting the words wi to wj in
one line with natural word spacing requires a length of Li;j + (j i)s. In order to
evaluate how much stretching or compression of the natural space s is needed to set
the words wi until wj in one line, a penalty function Pi;j is defined as follows:

Pi;j = jD Li;j (j i)sj D  Li;j
1 D < Li;j (4.6)

The penalty is zero, if the words can be set without stretching or compression of s.
The penalty becomes 1, if there is no space left between the words of the line.21
20
Knuth’s algorithm deals with stretching and compression of space differently. His algorithms
also obviously deals with hyphenation.
21
Knuths’ penalty function is more complex; for reasons of simplicity, the above definition suffices.
102 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

The objective is to find a break sequence Bmin = fb0 ; b1 ; : : : ; bk g so that the sum of
penalties of all k lines of the paragraph is minimized:
k 1
X
8B; B is Break Sequence : P (B min ) = Pb +1;b +1  P (B )
i i

i=0

Given n words there are 2n 1 possible ways to break them into a paragraph.22 It is
therefore prohibitive to simply check all possible combinations. In reality, only a few
break sequences give good results, meaning that they have a low overall penalty.
Note that it is not sufficient to solve the problem by simply using a first-fit algo-
rithm, which would simply begin at the first line and makes choices as it sets each
line: this approach can easily lead to line breaks that do not result in an overall
minimum penalty; sometimes it is essential to set some earlier lines with a higher
penalty so that later lines can be set with a lower penalty and thus reducing the
overall penalty of the paragraph.
For the algorithm, Knuth introduced the concept of “feasible breakpoints”; a “feasi-
ble breakpoint” is a possible entry bi in the final sequence Bmin with the restriction
that there exists a way, to set the paragraph from the very beginning to the word
wb so that the individual penalties of all the individual lines of the thus created
i

subparagraph are within an allowed penalty range. When the algorithm runs, a
list of “active breakpoints” (called active list) is maintained: this list contains those
feasible breakpoints that might be chosen for future breaks.
Algorithm 2 shows a pseudo-code for Knuths’ original optimal line break algorithm.
The algorithm commences by adding the very beginning of the paragraph to the
active list.23 Then, subsequently all potential breakpoints (for our simplified case,
these are just the breaks between words) are checked with respect to each breakpo-
sition in the active list. If there exists a way to set the line from an active breakpoint
a to a potential breakpoint b so that the penalty of that line is within the allowed
range, b is added to the active list. The algorithm also remembers, which of the pos-
sibly multible existing active breakpoints a gives the lowest overall penalty when
setting the paragraph up to wb using one active breakpoint a. The best predeces-
sor is remembered so that the break sequence can be retrieved later. If a potential
breakpoint b is encountered, for which an entry a in the active list returns an infi-
nite penalty (this means, that the words from a to b can not be placed on one line),
then a is removed from the active list.
The algorithm finishes by chosing the feasible breakpoint for the last word of the
paragraph that has the lowest overall penalty. Because for each feasible breakpoint
the predecessor is known, all previous breakpoints can be subsequently accessed.


22
For a fixed number of lines k , there are n k 1 ways to break the sequence of words. If the number
Pn 1

of lines can vary from 1 to n, the resulting formula is k=0 n k 1 = 2n 1 (according to the binominal
theorem).
23
This location is not really a breakpoint; it is treated as a breakpoint so that the rest of the
algorithm must not deal with the first line as a special case.
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 103

Algorithm 2 Optimal line breaks in text

Require: n  1 fNumber of wordsg
activelist := new list<Entry>;
feasiblebreaks := new array<list<Entry>>;
Entry := new Entry;
Entry.pos := 0;
Entry.penalty := 0;
Entry.predecessor := -1;
activelist.Add(Entry);
fWe go through all wordsg
for i := 1 to n do
feasiblebreaks[i] := LIST();
for all a 2 activelist do
penalty := Pa:pos+1;i + a.penalty; fusing penalty function (4.6)g
fif the penalty gets too high, remove a from active listg
if penalty = 1 then
activelist.Remove(a);
end if
if penalty < penaltyrange then
Entry := new Entry;
Entry.pos := i;
Entry.penalty := penalty;
Entry.predecessor := a.pos;
feasiblebreaks[i].Add(Entry);
end if
end for
fWe only save the best entryg
feasiblebreaks[i].RemoveAllButBestEntry();
activelist.Add(feasiblebreaks[i].First());
end for
fNow we can construct the optimal break sequence Bg
fThe sequence is created backwardsg
B := new list<int>;
fTake the last entry added to the active listg
a := activelist.Last();
while a.predecessor > 0 do
B.AddHead(a.pos);
a := feasiblebreaks[a.predecessor].First();
end while
B.AddHead(0);
return B;
104 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

The algorithm makes use of the principle of Dynamic Programming [Bel57, Pre00],
which solves an optimization problem by solving a series of carefully devised sub-
problems. Each solution is subsequently obtained by combining the solutions of one
or more of the previously solved subproblems. There are two places, where Dynamic
Programming is applied in the line breaking algorithm: first, the calculation of Li;j
(the length of a subsequence of words) does not need to be recalculated for every
combination of an active breakpoint a and a potential breakpoint j . It is sufficient
to just maintain a global variable L1;j that stores the length of all words from the
beginning up until wj . For each active breakpoint a, the length L1;a is stored. Then
La;j can be easily calculated as La;j = L1;j L1;a . The second place, where Dynamic
Programming is applied, is where the best previous breakpoint a is remembered
when a feasible breakpoint is added to the active list. This can be done, because the
subparagraph from the beginning up until wb using the breakpoint a has the small-
est total penalty. The line breaking of the remaing words (the lines after wb ) does not
affect the previous subparagraph. Knuth puts it into the following words: “The opti-
mum breakpoints for a paragraph are always optimum for the subparagraphs they
create”. This is even true if there is a way to set the paragraph from the beginning
to wb with a different number of lines using only feasible breakpoints. In this case,
only one previous active breakpoint a gives the lowest overall penalty – the number
of lines for the subparagraph is automatically chosen so that the global optimum is
maintained. This very fact is very important when comparing text setting to music
setting: if the number of lines of a paragraph must be variable, active breakpoints
must be stored for each different line number therfore increasing running time and
storage space. Also, even if the total number of lines does not matter, the described
mechanism only works if the remaining lines all have the same width. Otherwise, it
might be important which breakpoint occurs on which line in order to get the global
minimum penalty. The running time of Knuths’ algorithm is O (n
), where is the
maximum number of entries in the active list, which is just the maximum number
of words in one line of text. As indicated above (and also described in Knuth), the
running time increases, if the total number of lines needs to be adjustable and also
if the individual lines of the paragraph have differing widths.

Optimal Line Breaking in Music Scores

Finding optimal line breaks in music has been previously discussed by [HG87].
Their work is very closely related to Knuths’ algorithm, which has been described
in the previous section. In order to adapt Knuths’ algorithm to be usable for music,
some specific musical issues must be considered. Instead of dealing with a collection
of words, we now deal with a collection of system slices. A system slice (or slice for
short) is a horizontal area of the score which cannot be further broken appart. For
a first understanding of the problem, it is sufficient to treat system slices simply
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 105

as the measures of a score.24 For each system slice, a separate space-force-function

exists, which desribes, how this particular system slice will react to a stretching-
force. Assuming that there exists a “natural” or “optimum” force fopt , which results
in esthetically pleasing lines of music, we can determine the “natural” extent for
each slice by computing the respective space-force-function using the optimum force
as the input. In order to determine the overall penalty for a line made up from a
collection of system slices (compare to equation (4.6)), the space-force-functions for
the participating system slices must be merged. Then the force required to stretch
the merged space-force-functions to the given line length must be computed and the
deviation with respect to the optimum force must be determined.
Let S = (s1 ; : : : ; sn ) be an ordered set of slices. A penalty function  : N  N ! R takes
two numbers i and j and calculates the badness of the line beginning at location si+1
going to sj . The objective is to find a sequence Bmin = (b0 ; b1 ; : : : ; bm ) for which the
value:
m
X1
P (Bmin) := (sb ; sb +1 )
i i

i=0
is minimal. Note that b0 = 0 for every sequence B . The resulting number of lines is
then m.
In order to calculate the sequence Bmin that minimizes P , Algorithm 3, which is an
adaption of Knuths’ original algorithm, is used.
Algorithm 3 is quite similar to Knuths’ algorithm. Instead of maintaining an active
list, an entry is stored for each slice, which saves the optimum predecessor and the
overall penalty of breaking at that particular slice. The algorithm automatically
leads to justified lines (including the last one), because the penalty function returns
smaller penalties for full lines.
Just as the text break algorithm, the line break algorithm for music makes use of
the principles of Dynamic Programming [Bel57], because for each slice, only the best
way to break the previous slices is remembered. The running time of the algorithm
is bound by the number of slices (n, the first loop), and the maximum number of
slices per line (the maximum value for j i, where (i; j ) 6= 1). We denote this
parameter . For all practical purposes, we can probably assume that < 10 for
most scores. Because the algorithm does not contain an explicit value for , it works
for any value found in real scores. The overall running time is then O (n

Time()).
This shows that the running time of  is a crucial part of the optimal line break
algorithm.
The actually implemented algorithm has to deal with certain musical aspects: when
a line of music is broken, the following line gets a clef and a key-signature. It is
therefore important to leave room (horizontal space) for these notation elements.
24
As there are instances in music notation, where line breaks do occur at positions which are
within a measure, or there are even scores with no measure information, the general algorithm just
deals with measure-independent slices.
106 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

Algorithm 3 Optimal line breaks in music

E := new array<Entry>;
E[0].penalty := 0;
E[0].predecessor = 0;
for i = 1 to n do
E[i].penalty := 1;
E[i].predecessor = -1;
end for
for i = 0 to n 1 do
if E[i].penalty < 1 then
prevpenalty := E[i].penalty;
for j = i to n do
newpenalty := (i; j ); fUsing equation (4.7)g
if newpenalty + prevpenalty < E[j].penalty then
E[j].penalty := newpenalty+ prevpenalty;
E[j].predecessor := i;
end if
if newpenalty  1 then
break; fEnd the inner loopg
end if
end for
end if
end for
fNow we can retrieve the Break Sequenceg
B := new list<int>;
int k := n;
while E[k].predecessor > 0 do
B.AddHead(k);
k := E[k].predecessor;
end while
B.AddHead(0);
return B;
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 107

Because the clef and the key-signature can change within a piece, a pointer to the
current clef and key has to be stored with each potential break location.
The penalty function  is calculated as follows:

(si ; sj ) = j s si ;sj (lineextent) fopt j (4.7)

where s s ;s is just the merger of all s ’s from slice si+1 up to slice sj , lineextent is the
i j

desired width of a line and fopt is a constant value set by the user (and dependent on
personal taste). Merging the s ’s is a somewhat expensive operation: the merging
of two space-force-functions s 1 and s 2 has a running time of O (maxfj s 1 j; j s 2 jg),
where j s j is the number of springs in the space-force-function. If slices are
merged, each containing a maximum of springs, the overall cost is O (( 1)
).
Together with the formula from above, we get a running time for Algorithm 3 of
O(n


). Because most of the lines will later not be used, and a complete merger
of the s ’s is so expensive, a quicker (and less exact) mechanism was actually im-
plemented: Because a s is a piece-wise linear function, it is possible to identify a
slope for each linear section. This slope directly corresponds to the added spring
constants of those springs that are active at the respective force interval. In order
to efficiently approximate the merger of different s ’s, the spring-constant for the
linear segment at the optimum force is saved. This saved spring-constant approxi-
mates the function in the neighborhood of the optimum force. An approximate merg-
ing of different s ’s is then possible by just determining the overall spring-constant
using equation (4.1), which then just requires multiplications. Figure 4.20 demon-
strates, how this optimization compares to the exact merging of s ’s. The upper part
of Figure 4.20 shows three measures of a Bach piece. Each measure is treated as a
separate slice with its own s . The spring constants at the optimum force are shown
below the scores. For the approximation, the individual spring constants are simply
multiplied using equation (4.1). To determine the approximated force required to
stretch the three measures to a desired width of 4280, Hooks’ Law is used with the
approximated values. This results in an approximated force of 533:43. The lower
part of Figure 4.20 shows the actual merged space force function for the complete
three measure line. The actual force required to stretch the system is 536:3, so the
difference from the approximate value is less than one percent! For all practical pur-
poses, it is therefore sufficient to work with the approximated values. The running
time of  is thus reduced to multiplications and additions.
To finally demonstrate, how the optimal line break algorithm works on a 27 mea-
sure long Bach fugue, consider Figures 4.21 and 4.22. The 27 measures are bro-
ken into 12 lines covering two and a half pages. The individual lines are spaced
evenly and the overall appearance is quite good. The overall penalty for all lines
is 1777.37, which gives an average penalty of 1777:37=12 = 148:11 for each line.
The user-selected optimum force for this particular calculation was set to 800. Fig-
ure 4.22 shows the calculated array of entries. The nodes in the graph represent
ends of measures together with the overall penalty, where a line break may occur.
108 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

—— ———— —
# # c a X——Û X—Û— _—XÛ n X———Û X———Û— X——Û X——Û X—Û— X———Û— —— ———XÛ X——Û X——Û ——— ——— X——Û X——Û X———Û ——— _X—Û _X—Û X—Û—
5

X——Û X——Û X———Û ——XÛ X——Û X——Û X——Û # X—Û— _X—Û XÚ– XÚ– X—ÚÛ––
4 1 3
3 2 2

XÛ
5

=‹ X—Û======= X—Û X—Û a –– –– – nXÚ–– ‹

2

&
========= =‹ = =‹ =‹ ========
=

«
‹ ‹ ‹ ‹ ‹
X_Ú–– ‹ ‹ ‹ ‹ _XÚ–– _XÚ–– X–Ú XÚ– # XÚ XÚ– X–Ú _XÚ–– _XÚ–– _XÚ–– X–Ú ‹
2

## c – a XÚ––– XÚ––– a XÚ–– ‹‹ ‹ XÚ– XÚ–– XÚ– XÚ– ‹ ‹ XÚ– –– –– –– – –– – –– – –– – –– ‹

a X Ú
– – – –
– ––– XÚ– =‹‹ –– – – – – – –
?
========= J 3
J– =‹ =‹‹ – =======
= J
––
2– – – =‹‹ –– ========
= 1
‹‹
3 1

3500 3500 3500

3000 3000 3000

2500 2500 2500

Extent

Extent

Extent
2000 2000 2000

1500 1500 1500

1000 1000 1000

500 500 500

0 0 0
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500

Force Force Force

copt = 0:488976 copt = 0:427088 copt = 0:379205

xopt = 533 xopt = 0 xopt = 0

capp = 1 1 1
1
= 0:142363
0:488976 + 0:427088 + 379205
xapp = = 533
Force required for width 4280: (4280 533)
0:142353 = 533:43

——— — ——— — — — — — — —— — —— —— ——— ——

# # c a X—Û X—Û _XÛ— n X———Û X———Û X——Û X—Û X—Û X———Û ——— ——XÛ X——Û X—Û ——— —— X—Û X——Û X——Û X———Û _X—Û _XÛ— X—Û X—Û X——Û X——Û ——XÛ X—Û X——Û X—Û # X—Û _XÛ— XÚ– XÚ– X—Ú–Û–
5
4 1 3
3 2 2
5

=‹ X—Û======= X—Û X—Û a –– –– – nXÚ–– ‹

2

&
========= =‹ ========

«
‹ ‹ ‹
_XÚ–– ‹ ‹ X Ú XÚ – – XÚ ‹X
Ú
2

XÚ _ – _X Ú
– XÚ _
X Ú _
– _
X
Ú
## c a XÚ––– XÚ––– a XÚ–– ‹‹ XÚ––– a XÚ–– ––– XÚ––– XÚ–––– XÚ ‹‹ XÚ–– –––– –––– –––– XÚ––– # XÚ––– XÚ––– –––– –– –– –– ––– ‹‹
?
========= J J– =‹ =======
3 J– –– ––– =‹ – ========‹ 2 1 3 1

10000

9000

8000

7000

6000
Extent

5000

4000

3000

2000

1000

0
0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500

Force
copt = 0:145318
xopt = 534
Force required for width 4280: s (4280) = 536:3

Figure 4.20: Exact and approximate merging of s ’s

4.5. SPACING, LINE BREAKING, AND PAGE FILLING 109

The edges in the graph depict penalties associated with a line beginning at the end
of the measure in node 1 and ending at the end of measure of node 2. As an ex-
ample consider the lines beginning at the very bottom of Figure 4.22: The first line
of the piece begins at end of measure 0 and goes to the end of measure 2 (penalty:
188:106) or measure 3 (penalty: 291:758) or measure 4 (penalty: 835:235). Figure 4.22
shows the optimum path and the first fit path, which is not the same: in order to
demonstrate that the first fit algorithm leads to a bigger overall penalty, the entries
for measure 25 and 27 are each shown twice. The actual algorithm only saves the
entries for the optimum line breaking path. Additionally, when calculating the op-
timal line break, only one predecessor is saved for each node. Figure 4.22 shows
more then one predecessor to demonstrate that the algorithm tries different break
combinations before the optimum solution is determined. To determine the break-
ing sequence, the algorithm begins at the top of Figure 4.22 in the node labeled
“27/1777.37”. The dashed edges are subsequently followed to produce the sequence
27; 25; 22; 20; 18; 16; 13; 11; 9; 7; 5; 3; 0. Reversing this sequence shows, which measures
are endings of lines.

4.5.3 Optimal Page Fill in Music

As indicated before, music is usually printed so that a complete piece completely
fills the pages it is being printed on. This is different in book printing for example,
where the last paragraph may end almost anywhere on the page. Even though one
professional music notation program (SCORE by Leland Smith) has an integrated
page fill algorithm, nothing on this subject has been published so far. The most
popular notation programs (such as Finale, or Sibelius) do not even offer an optimal
line breaking algorithm, although the results published by Hegazy and Gourlay are
fairly easy to implement. During the work on this thesis, an optimal page filling
algorithm was developed. This new algorithm is an extension of the optimal line
breaking algorithm of the previous section. It computes optimally filled pages with
lines of music that are esthetically pleasing. The new algorithm is also scalable so
that it can be adopted to either run with maximum speed or to produce optimum
output.
A definition of the problem can be given similar to before: Let S = (s1 ; : : : ; sn ) be a set
of ordered (system) slices. Each slice has an associated height hi , which determines,
how much vertical space the slice requires on a page. The height function is defined
as follows:
height(i; j ) := maxfheight(sk ) j i < k  j g (4.8)
Where height(sk ) is simply the height of slice sk .25 A slice also has an associated
s (just as in the case of optimal line breaks). The objective is to find a break se-
25
In certain (rare) situations, equation (4.8) might lead to false results: there might be scores,
where multiple staves require different heights within one line of music. As a first estimation for the
algorithm, equation 4.8 is sufficient.
 110

FUGA I
J.S.Bach BWV 846
— — — — —— —— —— —— — — j — j — j — — —— ——— ——— —— — — —
c — — —— —— . X——Û X———Û X———Û— XÛ— X——Û— X———Û X———Û XÛ— X———Û X———Û
X
Ú
– X
Ú
–
X——Û XÚ– XX——ÚÛ– # XX——Û—Ú —XÛ— X———Û X——Û— X——Û— X——Û ———— X——Û— X———Û ——XÛ— X——Û— XX——Û—Ú XX——ÚÛ– # XÚ XXÛ—Ú– XÚ– XÛ—XÚ XX——ÛÚ XÚ– XX——Ú–Û X——Û X——Û— X——Û— . X—Û—
– – – – – X
——Û————
. X ——Û X——Ûj
— ——— X—Û — X——Û— X——Û XÚ X——Û— b X——Û— j
— X
—Û— X——Û X
X
——ÚÛ b XX——Ú–Û . X—Û— XÚ– XÚ– XX—Û—Ú XÚ–– X—Û— _XÛ XXÛÚ– X—Û— XX—Û—Ú– XX—Û—Ú–– XX—Û—Ú– XX———Ú–Û
========= # X
Ú
– –
XÚ–– XÚ–– XÚ––– XÚ–– XÚ–– XÚ–a XÚ–– XX——Ú–Û XÚ– XÛ—— XÚ– XÛ— =‹ XÛ=======
& a _XÚ– XÚ–– XÚ–– XÚ––– . XÚ––– XÚ––– XÚ–– XÚ–––– ‹ XÚ–– ======== – X Ú
– X
Ú
– X Ú
– ==
& XÚ––– =============
–– –– ––– # XÚ–– n XÚ–– XÚ– # XÛ XÚ– Ú
X X
Ú
– X Ú
– – ‹ – –
===========
– – – # X
Ú
– – – ‹ ==
& XÚ–– XÛ======== XÚ–– XXÚÛ–– XÛ XXÚÛ–– XÛ— XÛ— =‹ XÚ–– ======= –– XÚ– XÚ– XÚ– XÚ– –– ‹ – ======== –– – –– – XÚ– –– –– – –– = –– ‹
–– – – – – ‹ – –– – – – –– – –– –– _XÚ––– –– _XÚ––– _XÚ––– ‹ __XÚ–– –––– – – –– –– –– XÚ––– =‹‹ – – –– –– ––– –– –– – ‹ – – – – –– – – J–– a ¥ ‹ – – – – ‹ J– – J–– –– –– –– – ‹ – – – – – –– – ‹
‹ ‹– ‹ ‹ ‹ ‹ — — ‹ — — — — — — — ‹
‹ ‹ ‹ — — —
— —
— —
— —
— — — — — — j j
— ‹ XÚ
– —
— —
— — — — — — — — — — — — — — — — — — — — —
‹ ‹ ‹ — —
a —— # XÛ— # XÛ— XÛ . n XÚ XÛ XÛ XÛ— — — — — — _
X Û ‹ —— —— —— _XÛ— —— —— —— ——
‹ # —
X
Û X
Û Û
X X Û X
Û n # —
X
Û X
Ú X
Û —
—
X
Û ‹ X
Ú X Û Û
Ú
X ‹ XÛ— —— —— —— —— . XÛ— —— —— XÛ— ‹ —— XÛ— XÛ— XÛ— XÛ— —— —— —— —— —— XÛ— XÛ— b XÛ XÛ— ‹
‹ w XÛ— XÛ— XÛ XÛ XÛ XÛ ‹ XÛ—w XÛ XÛ XÛ— XÛ XÛ ‹
c XÚ––Û XÚ–– XÚ–– ‹ ==
X––Ú –– –– X––Ú XÚ– XÚ– XÚ XÚ XÚ XÚ– XÚ– X––Ú ––
? – ======== =‹
=========
? ‹‹ ======== =‹‹ ======= =‹‹ ==
? XÚ––– ============= – XÚ–– XÚ–– –––
–J J– J –
‹ XÚ XÚ––
‹ J–––=========== – J –
––– XÚ–– XÚ–– XÚ––
– – – ‹
– – – –– –– ––– –– –– –– –– –– ––– XÚ– =‹ =======‹ ========
– – ––
J
« — —— —— —
« «
— —— — —— _E————Û
——— ———— X——Û— X——Û— X——Û X——Û— X———Û X———Û X—Û— X———Û X—Û— # XÛ— XÛ X———Û— X——Û X——Û— X———Û X——Û ——XÛ— X——Û— ——— — — — ——— a ——— —— —— —— ——— ——— ——— ——— ——— ——— _X—Û— .
== XÛ XÚ–– XÚ– XÚ
& XXÛ–Ú–– ============ a ‹ XÚ–– ===========
a XÚ––– = XÚ– XÚ– XÚ– XÛ ‹
XÛXÚ–– . XÚ–– XÚ– X——Û XX——ÚÛ– X—Û— X——Û = — ¥ —— —— —— ——— X—Û—
X
Û
—— . — X———Û X———Û X——— XX——Û— X———ÛXÛ— X—Û—— n XX—Û—Û— . XÛ— XÛ X—Û—
# X
Û n X
Û Ú
X
–
EÛ b XÚ– XÚ– XÚ– XÚ XÚ– XÚ @ X
——Û— X——Û— n X——Û X———Û XÛ— XÛ— XÛ XÚ XÛ X——Û XÛ— XÛ— XÛ XÛ XÚ–– XÚ– _XÛ— _
Ú
X
– – – EEÚ–Û–
– –– ––– _XÚ––– J ‹ – –– –– –– – – –– –– ‹ ==
& XÛ—a======= X
Ú X Ú
– X
Û . X
Û X—
Û . X
Ú = ‹ X
——Û—========
——XÚ–XÛ X———Û —XÛ— XXÚ——Û X——Û j X
—Û—XÚ XX——Û— # XXX———ÚÛ XX———Û ‹ XÛX——Û======== # X
Û X
Ú
– XÚ =‹ ==
& –– ==============–– –– –– ––– –– ––– XÚ–– XÚ– XÚ–– . ––– ‹ –– ========= @ – – =\
J ‹ ‹ _XÚ–– ––– ––
–
_XÚ–– –– _XÚ–– ‹ _XÚ– –– __XÚ– –– ––– ––– ‹ _XÚ––– –– –– ‹ – –– – ‹
— — — — —
— ‹ — — —
— —
— —
— — — — — — ‹ – – – ‹ –– –– –– – ‹ J– ‹ ‹
— — — — — — — — — — — — — — — — — ‹ a ‹ ‹ _w
a —
—XÛ X——Û XÛ— _XÛ—. _XÛ _XÛ— XÛ— __XÛ ‹‹ X——Û _XÛ _XÛ __XÛ _XÛ _XÛ— XÛ— _XÛ— _XÛ— b XÛ— ‹‹
X Ú —X—Û— a j —XÛ— X——Û— X——Û ‹ —
—
‹ ——
‹ XÛ— ¥ ‹
——— ——— —— —— ———— X——Û— _X——Û— ———— E—Û—
XÛ XÛ— XÛ— XÛ XÛ XÛ ‹
X
Û ‹ ‹‹ w
==
? ============ =
‹‹ =========== a XÚ––– X––Ú– –– =‹‹ == ¥ =
‹a
‹ ======== XÚ– ‹ XÚ–– XÚ–– XÚ–– XÚ–– XÚ– X–Ú b X–Ú
– – – – – – – X
Ú
– X
Ú
– = ‹ ==
? w============== ==========\
? XÚ––– ======= XÚ–– XÚ––– X––Ú– XÚ–– . XÚ–––– XÚ––– X––Ú– ––– ‹ XÚ––– ========
– – – – –– ––
—
« «
——— a —— X——Û— X——Û X———Û . X—Û— ———XÛ X———Û _X—Û—
XÛ —— — ——— ——— —— — —— —— —— — —— b X——Û— — —— — —— —— —— — — —— —— —— ———
X ——Û X——Û— XX———ÚÛ X———Û E—Û— XÚ– XÚ XÚ X
X Û
Ú
– XÚ
–
==
& _XÚ–============ – = ‹ –– =========== ¥ =‹ XX—Û—–Ú . _XÛ— XÚ–– X–Ú XX–Ú—Û— XX—Ú–Û– XX—ÛÚ _XÛ— XXÚ––—Û X—Û X—Û—XÚ–– XÚ–– _XXÛ—Ú–– X–Ú XX—Û—–Ú _XÚ––– #_XXÛ—–Ú XX—ÚÛ–– X—Û XX—Ú–Û– X—Û XX—Û–Ú X—Û— XX—ÚÛ–– X—Û XX—Ú–Û– X—Û X—Û
–
–– ––– @ –– ––– XÚ––– ––– XÚ–– ––
– ‹ ‹ ==
& – ============ –– –– –– – –– –– – – – – ‹ –– ============ –– – – – – – – ‹
‹ ‹ ‹ ‹
— — — —
— ‹ j — — —
— —— ‹ —— ‹
— —
— —
— — _
X
—Û— ——— ——— n_X——Û— ‹‹ ——— _X—Û— _X——Û— _X——Û— _X——Û— ——— j
_ X
Û
_ n_XÛ _ — _ _ _ _ _ X
Û # _ —
—
X
Û a ¥ ‹
—XX—ÚÛ . _XÛ— XÚ– XÚ X——Û— _XXÛ——–Ú @ X——Û ——XÛXÚ– _XÛ— _XXÚ–Û— X–Ú XÚ– XÚ ‹‹ X——Û— XÚ
–
a X——Û— X——Û X——Û _XXÛ—–Ú . # XÚ _XÛ— _XÛ— ‹‹ a XÛ—— XÛ— #_XÛ _XÛ.
X
Ú X
Ú
– ‹ X
XÛ
Ú
– . X
Ú
– X
Ú
– X
Ú
– b X
Ú
–
– X
Ú X
Ú
– X
Ú
– X
Ú
–
– X
Ú
– X
Ú
– ‹
==
? –– ============ –– ––– X–Ú– ––– XÚ––– –– – –– –– ––– = XÚ ––– X–Ú– XÚ–– XÚ– XÚ–– XÚ– XÚ– XÚ XÚ––
‹‹ –– =========== –––– –––– =‹‹ # XÚ–– X––Ú XÚ– XÚ– –
–– –– – – –
– – –– – –– – – – – – – – –
– – ‹‹
« – – –– – –– –– ––– –– « == ––
? XÚ––– ============ ––– –– –– ‹‹ – ============
— — — — —— — —
— —— —— —— —— —— —— —— —— X——Û ——— —— —
X——Û XÛ— XÛ— _XÛ XÛ— XÛ— X——Û _XÛ _XÛ _ _XÛ XÛ— EÛ— X——Û . # XXÛ—Ú–– XÚ– XXÛ—Ú– XÚ–– _X—Û— ——— ——— X———Û X——Û— . —— j
# X—Û XÛ XÛ X—Û— a ¥—— —— —— — X——Û —— —— ¥—— X——Û —— —— a j
==
& ============ ‹ a=========== X–Ú– X–Ú–– XÚ––– XÚ––– . –– –– –– –– =‹ == X Ú
–
& –– =========== XÛ XÛ XÛ XÛ— XÚ– XÚ– X—Û— ‹
‹ ‹ J
a a XÚ–– # XÚ–– XÚ––– XÚ–– X–Ú n_XXÛ—Ú– . XÚ–– XÛ XÛ— =
–J – –– –– –– – ‹ –– ––––
XÚ # X——ÛXÚ–– XÚ–– XÚ–– XÚ– _EÚ–
‹ _XXÛ—Ú ============
– – – – –– – – XÚ–– = XÚ–– ‹
‹ ‹
———— __X——Û ————— _X———Û— _X——Û— __X——Û _X——Û— n_X——Û— ———— __X——Û ‹‹ __X——Û _XÚ _XÚ– _X——Û—_XÚ —_X—ÚÛ— ———— _—XÛ— ——— __X——Û _X——Û— _X——Û— ——— ‹‹
XÛ ‹ — ‹ ‹
XX–ÚÛ X–Ú– b X–Ú–– X–Ú– XÛ X–Ú X–Ú– n XXÛÚ ‹ X–Ú –XÚ– ––– –– –– X–Ú– X–Ú –XÚ –– XÛ XÛ
– – – – – J a
a — ——— #_X——Û _XÛ—— .
—
X
Û X
Û XÚ
– ‹ ‹
==
? – ============ # XÚ–– ––
–
–– ‹‹ – =========== ¥ =‹‹ XÚ–– XÚ–– XÚ–– XÚ– –– –– EÚ– X
Ú ‹ XÚ– XÚ– XÚ– XÚ X
Ú
– # X
Ú
–
– X
Ú
–
– ‹
==
? – =========== – –– –– –– = ‹‹ –– ============
–– –– –– XÚ–– XÚ– XÚ– # XÚ –– –– –– =‹‹
« — — —
« – – –– –– ––– _XÚ–– –– –– –
–
X——Û XÚ– # XXÚ–——Û XÚ– XÚ– X——Û n X——Û X——Û— X——Û— ——— X—Û— ——— ——— ——— ——— ——— ——— j a — — — ——
X Ú
– – – –
– – X
Ú
–
– X XÛ # XÛ XÛ— X——ÛÚ– . XÚ– XÚ– @XÚ X——Û X—Ú–Û– X——Û— # X———Û XXÛ—Ú– —
== –– – – – Ú––– a XÛa XÛ–XÚ XÛ =
& –– ============ ‹ XÚ
–
XXÛ—Ú– ===========
– – –
– – –
– — — — — —— —— ———— — — — —— —— —— —— —— — — —
J –– – – – – – –– ––– XÚ––– ––– =‹‹ ——— ——— X—Û— .
XÛ X—Û— X—Û— X—Û—— XÚ– X——Û X———Û X—Û— XÚ– X—Û— X——Û X—Û— X—Û— X—Û—— XX—Û—Ú– b XX—ÚÛ—– X——Û XXÛ—Ú–– XÛ— _XÛ XÛ— XXÛ—Ú–– X——Û X—Û— X—Û—
J ‹‹ – ‹ ==
& _X—ÛXÚ–XÛ——============ – X
Ú
– X
Ú
– X
Ú X
Ú
– XÚ
– – = ‹ XÚ
– =========== XÚ
– –
–– – – – – –– XÚ––– =‹
—_XÛ— ——— ——— _X—Û— _X——Û— _X—Û— ——— ——— — ‹ ‹ –– XÚ––
–
XÚ–– –– ––– –– ––– ––– –– –– ‹ ––
– – ‹
XÛ XÛ XÛ XÛ X—Û— ¥ ‹ ‹ ‹ — — — — — — ———— ‹
a Ú
X ‹ XÚ– . X Ú
– XÚ
– X Ú Ú
X
– X Ú
– X Ú
– X
Ú
– XÚ
– X
Ú
– ‹ — — ‹
==
? ============ XÚ–– XÚ––– ––– = ‹ –– =========== ––– –– ––– –– XÚ–– ––– –– –– –– =
–
–– ‹ _X—Û— _XX—Û—Ú– —XÛ—— X———Û ———— X——Û —— ——— X—Û—— _X—Û— _X—Û— ‹ __X—Û . _
_XÛ—— __X——Û _X——Û— ___XÛ— _X——Û— __XÛ—— __XXÚ–Û—— ___XÛ— __XXÛ——Ú– __X——Û ‹‹
– XÚ–– –– XÚ–– # XÚ–– XÛ XÚ– XÛ— EXÚ–Û– ‹ EÚ–– XÚ––
– –– –– ‹
–
« « ==
? – ============ – – –– = ‹‹ – =========== =‹‹
(c) Kai Renz, musical data taken from MuseData database and automatically converted to GUIDO

Figure 4.21: A Bach fugue broken with the optimal line fill algorithm
CHAPTER 4. CREATING THE CONVENTIONAL SCORE
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 111

27/1955.95 27/1777.37
20
26 3.
3. 25
20 3 7
70
1.
70
25/1752.69 229. 25/1574.11
091
0
23/1523.60 81

20
126 7.
75

2.
.39
4

66
0
877.163 21/1397.21 816.47
3
22/1371.45
8
98

3
.1

20
2

91
97 .80
452

.7

1.
83

02
7
19/1300.01 20/1287.73 151.378

401
18/1136.35
.40 1
0 50
1 24.
145.716

0
51

.36
3 .0
41

371
16/1011.85 125.310

182.172 15/972.124
17/1154.30 25 0
700.
384 2 80. 16
1.
21
13/886.540 1
127
129.

12/810.913
862.211

93.1106
11/757.413
844.
286

070
107.

10/717.802
9/650.127 45
3.
02
153 5
480.
6

7
35

99.573
.3

816
96

.47
3

7/553.791

8/618.229
934.614

127.726
37
112

6/490.502 6.
84
899.685

2
.28

0
40
4.
2

118. 44
894
37
804.247

7.

4/371.609
41

5/441.509
2

149.752

3
51
4 .50
. 183
2 74
5
23

3/291.758
5.

2/188.106
83

29
188 1.
.10 75
6 8

0/0

Figure 4.22: Partial calculation graph for the optimal line break of the Bach fugue
112 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

quence Bmin = (b0 ; b1 ; : : : ; bm ) where each bi contains three parameters: a slice num-
ber (referred to as bi :pos below), a position on a page (referred to as bi :height below),
and a flag, which is set, if the slice is the location of a page break (referred to as
bi :pagebreak); as before, Bmin should minimize the penalty function P
k 1
X
8B; B is Break Sequence : P (B min )= Pb :pos+1;b +1 :pos  P (B )
i i

i=0
and additionally the following four conditions must be met:
1. 81  i < m and bi :pagebreak = false :
bi+1 :height = bi :height + height(bi :pos; bi+1 :pos)
2. 81  i < m and bi :pagebreak = true :
bi+1 :height = height(bi :pos; bi+1 :pos)
3. 81  i < m : bi :pagebreak = true ,
bi :height + height(bi :pos; bi+1 :pos) > pageheight
4. bm :height  0:75
pageheight
The first condition means that the height of each break location increases as long as
no page break is encountered. The second condition means that the height is reset
if a page break is encountered. The third condition states that a page break may
only occur, if the following line does not fit on the current page. The last condition
requires the final measure to end on the last 75 percent of the page.
The algorithm works by dividing a page into a distinct number of “page areas”,
which are called slots. Figure 4.23 shows an example page that is divided into 12
different slots. There are three allowed ways to break the first eight measures of the
Bach fugue (BWV 846) into lines. This means that each breaking sequence of Fig-
ure 4.23 contains only lines of music whose individual penalties are within the (user
defined) penalty range. On the bottom of Figure 4.23, only two lines are required to
set the eight measures. Here, measure eight ends in slot 5. The overall penalty of
the two lines is 1734:92, which is a very high penalty, which is not surprising con-
sidering how tight the two lines are spaced. In the middle of Figure 4.23, the end of
measure eight ends in slot 7. The penalty associated with this particular breaking
sequence is 796:896. At the top of Figure 4.23 the end of measure eight ends in slot 9.
The penalty associated with this setting is 618:229. When dealing with optimal page
fill, it is important to remember each one of the different possibilities to break the
music together with the associated slot. To meet this goal, the algorithm needs to
deal with the height of slices and lines. Using the required height of a collection
of slices, the output slot can be computed. For each slot only the best way break
sequence is saved – this is where Dynamic Programming is used again.
The maximum number of slots, which is denoted , directly determines how fast the
algorithm runs. The running time is bound by O (n

). Essentially, the algorithm
 FUGA I FUGA I FUGA I
J.S.Bach BWV 846 J.S.Bach BWV 846 J.S.Bach BWV 846
— — —
— ———— —— — — —— —— —— — — — — — —— —— —— —— —— ——— — — —— X—Û— —— ——— X—Û— —— —— ——— —XÛ— ——— X———Û
&
c a
======================== X
Ú . X
Ú
– X
Ú X
Ú
– X
Ú
– X
Ú
– X
Ú
– X
Ú
– X
Ú
a X——Û— X——Û— X——Û X——Û . XÛ—X——ÛXX——ÚÛ XÛ— X——Û—XÚ XÛ— XÛ— XÛ— XÛ— X——Û ——XÚXÛ X——Û— X——Û— X——Û X——Û X——Û X——Û XÛ— XÛ— XÛ— XÛ— # XÛ XÛ XXÚ——Û
X
Ú # X
Ú – – X
Ú X Ú – X Ú a a= –– ‹ &
c a
======================== XÚ XÚ– XÚ XÚ XÚ– XÚ a X—Û— X—Û— X—Û X—Û . X—Û XX—ÚÛ X—Û—XÚ–– XXÛÚ–– XÚ– XXÛÚ–– XXÛÚ– = &
c a
======================== XÚ XÚ– XÚ XÚ XÚ– XÚ a X—Û— X——Û— X——Û
‹
_XÚ–– XÚ–– XÚ––– ––– ––– ––– XÚ––– ––– ‹‹ XÚ––– ––– –– –– –– ––– XÚ––– ––– XÚ––– XÚ––– _XÚ–– XÚ–– _XÚ–– _XÚ– ‹‹ __XÚ– ––– –– ––– ––– XÚ––– –––– XÚ––– ‹‹ –– ––– XÚ––– XÚ––– _XÚ––
– – J– ‹ _XÚ–– XÚ––– XÚ––– XÚ––– . –––– XÚ––– XÚ––– ––– ‹‹ XÚ––– –––– ––– –– ––– XÚ––– XÚ––– XÚ––– XÚ––– XÚ––– _XÚ–– XÚ–– _XÚ–– _XÚ– ‹‹ __XÚ– # XÚ––– –––
– – –
– – – –– ‹‹ _XÚ–– XÚ––– XÚ––– XÚ––– . –––– XÚ––– XÚ––– ––– ‹‹ XÚ––– –––– ––– –– ––– XÚ––– XÚ––– XÚ––– XÚ––– XÚ––– _XÚ–– XÚ––– _XÚ–– _=
– –
‹ – – – – ‹ –– –– ‹ J– ‹ ‹ – – – – ‹ –– –– ‹ ‹ – XÚ––– ‹‹
‹ ‹ ‹ ‹ ‹ ‹ ‹ ‹ ‹
‹ ‹ ‹ — — —— —— . X———Û ——— ——— _X—Û—— ‹ ‹ ‹ ‹ ‹ ‹
‹ ‹ ‹ X——Û XÛ— XÛ— _XÛ __XÛXÛ— _ ‹ c ‹ ‹ ‹ c ‹‹ ‹
c ‹ ‹‹ ‹‹ a ‹ ========================
? ‹ ‹ =‹ ========================
? =‹
========================
? ‹ =‹
« « ——— —
— ——— — — — — ——— — —— —— —— — — — — — —— —— —— —— X———Û ——— — — — — — — — — ——— X——Û ——— —— —— — — —— — —— —— ——— X——Û ——— X———Û # X———Û X—Û— ————
—— — — — — — a — —— —— —— X——Û———— _XÛ— X——Û— X——Û X——Û_XÛ—X——ÛX——ÛX——Û— _XÛ— _XÛ—_XÛ—_XÛ—X——Û X
X ——— X—Û— . X—Û— X—Û— XX—Û——Ú– X—Û X———ÛXÚ– XX—Û—Ú XÛ XÛ XÛ— XXÛ—Ú X——Û— X——Û XÛ— XÛ— XÛ— XÛ— XÛ XÛ
a
———Ú–Û X——Û— XX——ÚÛ— X———Û XÛ—— X——Û XÛ—— XÛ— XÛ— XÛ— XÛ—a # XÛ a XXÚ–——Û XXÛ——Ú– XX——ÚÛ— XXÛ—Ú XÛ—— X——Û X——Û— X—Û—XÚ. XÚ X—Û— X—Û—— ——— X—Û—— X—Û— X——Û— X——Û— XX——ÚÛ— X———Û EÛ—— XÚ– XÚ XÚ
=========================
& –– –– XÚ–– XÚ– _X–Ú – ‹ –– –– XÚ–– –– =========================
& _ # XÚ––– –– XÚ–– ‹ ––– XÚ––
– XÚ–– a XXÚ–––Û—=‹
XXÛ——Ú– XX——ÚÛ— XXÛ—Ú XÛ—— X——Û X——Û—X—Û—XÚ. XÚ X—Û—X—Û—— —— X—Û——X—Û— X——Û—X——Û—XX——ÚÛ—X——Û EÛ——XÚ–XÚ XÚ XX——ÛÚ– XÚ– XÛ—— XÛ— XÛ— XÛ . XÛXÛ—
========================= — ‹ =‹ – – – –– J– ‹ – – –
–– –– XÚ–– XÚ– XÛ ‹ _X–Ú –– @ –– –– XÚ–– –– XÚ– XXÛÚ––– =‹
–– – – ‹ –– – – – – – ‹ _XÚ–– –– –– ––– XÚ––– XÚ–––
– ‹ – XÚ–– _XÚ––
– – J ‹
& –– ––– XÚ–– –––
–
––– ––– XÚ–– XÚ–– XÛ ‹_XÚ– ––– @–– ––– XÚ–– ––– XÚ–– –– ‹ –– ¥
– – ‹ –– – – – – – ‹ ‹ ‹ J ‹ ‹ ‹ – ‹ J ‹
‹ ‹ ‹ — — — —— ‹ — — — —— — — ‹ — — ‹ ‹ — — — —
— — —
— —
— ‹ — —
— —
— —— — — — — — — ‹‹
— — — — — — ‹ —— ‹‹
—— X——Û— X——Û— _X——Û X——Û— ——— —— —— —— —— ‹‹ — XÛ— — —— ———— —— X——Û— ‹‹ — j
a
—X—Û— ——XÛ X———Û _X—Û— . _X—Û— _X—Û— X———Û __XÛ ‹‹ X——Û _X—Û— _X—Û— __XÛ_X—Û— _X—Û— X———Û _X—Û— _X—Û— b X———Û ‹‹ XX——ÚÛ . _XÛ— XÚ– XÚ X——Û— _XXÛ——Ú– @ X——Û XX———ÛÚ– _X—Û— _XX—Û—Ú– XÚ– XÚ– XÚ ‹‹ ‹ a X—Û— X——Û— X——Û _X——Û . _XÛ— ‹
_XÛ— _X——Û X——Û _
—XÛ_ ____XÛX—Û _XÛ _XÛ b X—Û ‹ XX—ÚÛ ._XÚ–XÚX—Û— _XXÛÚ– @X—ÛXX—ÛÚ– _XÛ_XÚ– XÚ–XÚ–XÚ ‹ X—Û—XÚ a X——Û— X———Û X——Û _XXÛ—Ú– . # XÚ_XÛ—_XÛ— ‹‹ XX——Ú–ÛXÚ– b__XXÛÚ–– XÚ– X——Û _XÛ— _XXÛ—Ú– __XÛ_XÛ— n_XÛ— n X——Û __XÛ ‹‹
?
========================= ‹
‹ a X Ú
– XÚ
–
– XÚ–– ‹‹ ––– –– ––– XÚ–– ––– XÚ–– –– –– –– –– ––– ‹‹
– – = ‹ ‹
?
========================= a X–Ú– X–Ú–– X–Ú–– ‹‹ ––– –– ––– X–Ú– ––– X–Ú–– ––– –– ––– –– ––– ‹‹ X–Ú– –––– –XÚ–– X–Ú–– X–Ú– X–Ú–– X–Ú– XÚ–– X–Ú– X–Ú–– –––– –––– ‹‹ –– –– –– –– # X–Ú– X–Ú–– –– X–Ú–
=‹‹ – – – – – ?
========================= ‹ =‹
––
— —— — —— ——— —— —— —— ——— ——— X——Û ——— —— —
a —— X——Û— X——Û X———Û . X—Û— X———Û X———Û _X—Û—
XÛ X—Û— XÛ— XÛ— _XÛ XÛ— X—Û X—Û _XÛ _XÛ _ _XÛ XÛ— X——Û —— X——Û X——Û ——— —— —— —— — — —— —— — —— —— ——— E——Û ———
=========================
& XÚ––– ¥ ‹ =‹ =========================
& X–Ú–– XXÛ—–Ú– XÚ–– X–Ú– XÛ XÛ— X—ÛX–Ú– . X–Ú– X–Ú– X—Û XX—ÚÛ–– X—Û— X—Û X—Û ‹ _XXÛ—Ú– X—Û XXÛ—–Ú– XÛ @ X–Ú–– X–Ú– X–Ú– X–Ú– XÚ–– XXÛ–Ú–– =‹
‹ ‹ – – – ‹ –– – – – – ‹
— — ‹ ‹
j — — — — — ‹ —— —— ——— ——— —— —— —— —— —— —— ‹
— — — — — — ‹ — ‹
—XXÚ—Û XÚ– XÚ a X——Û X——Û XÛ—— _XXÛ—Ú–– . # XÚ– _XÛ— _XÛ— ‹‹ XXÛ——Ú– XÚ–– b__XXÚÛ–– XÚ– X——Û _XÛ— _XXÛ—Ú–– __XÛ _XÛ— n_XÛ— n XXÛ——Ú __XÛ ‹‹ —X—Û— _X——Û _X——Û __XÛ— _X——Û _X——Û X——Û— _X——Û _X——Û b X——Û— ‹ X—Û— _X—Û ——— _XX—ÚÛ @ X——Û— X——Û— _X——Û _X——Û XÚ ‹
–– X Ú XÚ
– ‹ X Ú
– . Ú
X
–
– X
Ú
– X
X Û
Ú
– –
– X Ú X Ú
–
– X Ú
–
– –
– X
Ú
–
– X
Ú
– ‹
=========================
? –– –– ––– XÚ––– XÚ––– XÚ––– XÚ––– XÚ––– XÚ–– XÚ–––– ––– ––– ‹‹ – – – – # XÚ–– XÚ–– –
– – =‹‹ ?
========================= X Ú
a –– –– –– – ‹
‹ – – – –
–– – –– – –– –– – – = – – –
– ‹‹
–
« ——— — — —— —— ——— —— —— —— ——— ——— X—Û— ——— ——
a ——— X—Û— X——Û— X——Û . X——Û X——Û X——Û— _XÛ——
XÛ X—Û— X—Û X—Û _XÛ X—Û X—Û X—Û— _XÛ _XÛ _ _XÛ X—Û
X Ú
=========================
& ––– ¥ ‹ =‹
‹ ‹
—XÛ— j — —
— —
— ——— . X—Û— ——— ‹‹ ——— _X——Û— ———— X——Û— X——Û— _X——Û— X——Û— ——— ——— _X——Û— ‹‹
X
Ú
XÚ – XÚ–
a XÛ— XÛ— XÛ _XXÚ–Û # XÚ _ _XÛ ‹ XXÚ–Û XÚ– b_XÚ–– XÚ– XÛ— _ _XÚ– _ _ n_XÛ n XÛ _ ‹
––– ––– XÚ––
« =========================
? ––– –– –– XÚ––– XÚ––– XÚ––– XÚ––– XÚ––– XÚ––– XÚ–––– –
‹‹ –– –– –– –– # XÚ–– XÚ–– –
– – – =‹‹
4.5. SPACING, LINE BREAKING, AND PAGE FILLING

Figure 4.23: A page divided into 12 slots

(c) Kai Renz, musical data taken from MuseData database and automatically converted to GUIDO (c) Kai Renz, musical data taken from MuseData database and automatically converted to GUIDO (c) Kai Renz, musical data taken from MuseData database and automatically converted to GUIDO
113
114 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

carries out the optimum line fill algorithm times. To determine the optimum
break sequence that also fills the last page completely, the algorithm simply picks
a small overall penalty value from the last slice which ends on the lower part of
the page. Going backwards from this entry reveals the locations for line- and page
breaks. Note, that the algorithm determines the number of pages automatically;
this is similar to the optimal line break algorithm, which determines the number of
lines automatically.

The user can manipulate the algorithm by numerous ways: either by specifying di-
rect line- or page-breaks and by discouraging or encouraging certain breaks. These
flags are directly used by the penalty function and result in optimum break se-
quences, which also consider user input.

Algorithm 4 is an extension of Algorithm 3. For each slice, there are now slots re-
served for entries that save the predecessor (slice and slot), the accumulated penalty
and the accumulated height. The algorithm iterates through all slices (loop for i = 0
to n 1). For each slice, all entries (loop for j = 0 to ) are taken as a starting point
for future lines. This is quite similar to the optimal line breaking algorithm. The
optimal page fill algorithm does not only compute the penalty of a potential line be-
ginning at end of slice i and going up until slice k , but it also computes the required
height. If the accumulated height of the previous ending slice (this is called prev-
height in the algorithm) added to the height of the current line is bigger than the
page height, then the new line is placed on a new page. The accumulated height is
used to determine in which slot the calculated break position should be placed. Only
if the calculated penalty is smaller than the slots’ current value, the new value re-
places the old calculation; this is again an application of Dynamic Programming. If
the penalty of the potential lines becomes too large, the next slot of the current slice
is calculated. When the algorithm has finished, the calculated entry array is used
to retrieve the page break sequence that fills all pages. The procedure to retrieve
the sequence is shown in Algorithm 5. The algorithm first looks at the lower part
of the last slice: it finds the minimum penalty for the lowest quarter of the page. If
no value is found (this mostly happens, if less than one page of music is being set),
then the lowest overall penalty is determined – this entry is similar to the optimal
line break algorithm. Finally, the break sequence is determined by going backwards
from the last entry.

In order to demonstrate, how the optimum page fill algorithm works, Figure 4.24
shows the Bach fugue (BWV 846) of the previous section automatically being set on
exactly two pages. Figure 4.25 shows the calculated entryarray grid. The measures
of the finally chosen path are highlighted. Note that the optimum line break path
of the previous section (requiring 3 pages) is also present in the calculated array.
Figure 4.25 also shows that the first fit approach leads to a bigger overall penalty
than the optimal line break algorithm.
4.5. SPACING, LINE BREAKING, AND PAGE FILLING 115

Algorithm 4 Optimal page fill algorithm

entryarray := new array<Entry>[n+1][ + 1]; fCreate Entry arrayg
entryarray[0][0].penalty := 0;
entryarray[0][0].predecessorslice := 0;
entryarray[0][0].predecessorslot := 0;
for i := 1 to n do
for j := 0 to do
entryarray[i][j].penalty := 1;
entryarray[i][j].predecessorslice := -1;
entryarray[i][j].predecessorslot := -1;
entryarray[i][j].height := -1;
end for
end for
for i := 0 to n 1 do
for j := 0 to do
if entryarray[i][j].penalty < 1 then
prevpenalty := entryarray[i][j].penalty;
prevheight := entryarray[i][j].height;
for k := i to n do
ispagebreak := 0;
newpenalty := (i; k ); fUsing equation (4.7)g
newheight := height(i; k );
if prevheight + newheight > pageheight then
prevheight := 0;
ispagebreak := 1;
end if  
newslot := (int) (prevheight +newheight)
pageheight
;
if newpenalty + prevpenalty < entryarray[k][newslot].penalty then
entryarray[k][newslot].penalty := newpenalty + prevpenalty;
entryarray[k][newslot].predecessorslice := i;
entryarray[k][newslot].predecessorslot := j;
entryarray[k][newslot].height = newheight + prevheight;
entryarray[k][newslot].ispagebreak := ispagebreak;
end if
if newpenalty > 1 then
break; fBreak the inner loopg
end if
end forffor k := i to ng
end iffif entryarray[i][j].penalty < 1g
end forffor j := 0 to g
end forffor i := 0 to n 1g
return entryarray;
116 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

Algorithm 5 Retrieval of the page break sequence

Require: n = number of slices;
Require: = number of slots;
Require: entryarray[n][ ] calculated by algorithm 4
kminpage := +1; fDetermine minimum penalty for lower part of the pageg
minpagepenalty := 1;
for j := (int) (0:75
) to do
if entryarray[n][j].penalty < minpenalty then
kminpage := i;
minpagepenalty := entryarray[n][i].penalty;
end if
end for
if kminpage > then fThere is no entry at the end of the pageg
kmin := + 1; fDetermine the minimum penaltyg
minpenalty := 1;
for j := 0 to do
if entryarray[n][j].penalty < minpenalty then
kmin := j;
minpenalty := entryarray[n][j].penalty;
end if
end for
index := kmin;
else
index := kminpage;
end if
B := new list<int>;
k := n;
while entryarray[k][index].predecessorslice > 0 do
B.AddHead(k);
prevslice := entryarray[k][index].predecessorslice;
index := entryarray[k][index].predecessorslot;
k := prevslice;
end while
B.AddHead(0);
return B;
 FUGA I
J.S.Bach BWV 846
— — — — — —— —
c a XÚ X Ú
– X Ú a —
— X—
—— X——Û X——Û . X——Û— X———Û X———Û X—Û ——— X——Û— X——Û— X—Û X——Û— X———Û
Û X Û X
X——ÚÛ– # XÚ– XX—ÛÚ– XÚ–– XX—ÛÚ– XX—Û—Ú– XÚ– XX—Û—Ú–– X——Û X——Û X——Û . X——Û— X——Û— ¥ —— X—Û —— ——— X——Û— —— X——Û X——Û X—Û— X——Û ——— j —
a — —— ——
&
========= # XÚ XÚ–
XÚ–– XÚ–– ––– XÚ–– XÚ–– XÚ– XÚ–– XXÛÚ– XÚ– XÚ– =‹ ======= XÚ–– XÚ–– XÚ– XÚ–– XÚ–=‹ ==
& =–– ========= #
–– –– – –– ––– –– –– J–XÚ a a XÛ . X
Û — — XÚ–– _ X
Û — — X— XX—Û ‹
XÚ–– XÛXÚ–– XX—Û # XXÛ—Ú–– =
_XÚ–– XÚ––– XÚ––– XÚ––– . –––– XÚ––– XÚ––– ––– ‹‹ XÚ––– ========
– –– – – – – – –– –– _XÚ–– –– _XÚ––– _X–Ú– ‹ __XÚ–– ––––– –– – – – – –– ‹ ¥ ‹‹ ======= _XÚ–– XÚ––– XÚ––– _XXÛÚ–– . XÚ––– _XÚ–– =‹‹ _XXÛÚ–– ======= – _X
Ú
– – ‹
‹ – ‹– ‹ — ‹ – – – – ‹ – –– –– –– – ‹
‹ ‹ ‹ — — ‹— a j — ‹ — ‹
c ‹ ‹ ‹ —— X——Û X——Û _X——Û— X———Û —— j
X
Û n # —
—
X
ÛX
Ú
—— j — ‹ — —
—
X
Û
—— X——Û
XÛ ‹ —
—
X
Û ‹
========= ‹
‹ ======== =‹
‹ ======= = ‹‹ # X—ÛXÚ–– XÚ– XÚ
–
– –
–
XXÛÚ– XÚ– X—Û ‹ XÛ
– X
Ú
– – ‹ XÚ X
Ú
– . X
Ú
– X
Ú
– X
Ú X
Ú
–
– ‹
? ==
? =J–========= –– J– – – –– – ‹ X–Ú–– ======= ¥ =‹ a======= XÚ–– X–Ú–– ––– – ––– –– –– = –– ‹
–
« — — — — —— ——
«
—X——Û ——— X——Û X———Û X——Û X———Û X——Û X——Û X—Û— X——Û X—Û— # X—Û —XÛ X———Û X——Û X———Û X——Û X——Û X———Û X———Û ——— ——— — — —— ——— X——Û ——— X——Û ———XÛ E——Û — — — — — — —— — — — — — — — — — — — — — — ——
== XÛ XÚ–– XÚ– XÚ
& XÚ––– ======== a a XÚ
–
– =‹ X
Ú
–
– ======= X
Ú
– X
Ú
– X
Ú
– X
ÛX
Ú
– X
Û
. XÚ– XÚ– XÛ XX—ÚÛ —XÛ X—Û XÛ=‹ ======== XÚ
– @ X
Ú
–
– XÚ
– XÚ
– XÚ
– Ú
X
XX——ÛÚ– —— X———Û —— — —— X———Û X——Û n X——Û . X—Û— X——Û X——Û _X—Û XÚ X———Û —XÛ—XÚ– X—Û— _X—Û XX—Û—Ú X——Û X———ÛXÚ XÚ– _XX—ÛÚ X———Û b_XX—ÚÛ–– _X—Û XX—Û—Ú X———Û XX—Û—Ú– X——Û X—Û— X———Û ———XÛXÚ X—Û— XX—Û—Ú– X——Û X—Û—
– –– ––– _XÚ–– J– ‹ – –– –– –– –– –– –– ––– ‹ _XÚ––– ––– – –– –– –– ––– –– =‹‹
==
XÛ . —— XÛ # XX—Û XX—Û XÛ— n X—Û X—Û XÛ— XÚ–– . ––– XÚ–– XÚ–– –– XÚ– –––
XÚ =‹ – ======== – – –
––– –– ––– XÚ–– XÚ–– –– # XÚ–– ––– –– XÚ–– ––– ––
–=‹ – ======== – – – – =‹
J ‹ ‹ ‹ & _XX—ÛÚ– ======= # XÛ XÚ––
– –
– ‹
– –– –
‹ – ‹
— — — ——— —— —— _X——Û ‹‹ —— ——— ——— _X——Û ——— —— — — — — ‹‹ — — — — — — — ——— ‹ –– J– ‹
—X—Û X—Û— X—Û _X—Û . _XÛ_X—Û —XÛ _ ‹ X—Û— _XÛ _XÛ__XÛ_X—Û X—Û _X—Û _X—Û b X—Û ‹ X—Û— _XÛ XÚ X——Û _XX—ÚÛ– @ X—Û— —XÛXÚ _X—Û _XXÛÚ XÚ– XÚ ‹‹ a ¥
‹ — — — —— —— —— —— —— ‹ —— —— —— —— —— —— j
X_Û ‹ X—Û— _ _ X
Û _
_ X
Û _
_ X
Û _
X
Û
_ —
X
Û
_ #_—
—
X
Û a ¥ ‹
a XÚ . ––– XÚ–– XÚ–– –– XÚ– ––– ––– –– ––– XÚ–– ‹ ——XÛ ‹ a —— X—Û— #_—XÛ _X—Û . __XÛ _X—Û n_X—Û n_
X
Ú
– b X
Ú X
Ú
==
? ======== =‹‹ ======= a XÚ––– XÚ––– XÚ––– =‹‹ ––– ======== – – – – –– – – ‹
= Ú
X
– X
Ú
– X
Ú
– X
Ú
–
‹ # XXÚÛ– X–Ú– XÚ–
‹ –
– –– –– – X
Ú
– X Ú
– –
‹ X–Ú– . X–Ú– X–Ú– XÚ– ––– XÚ X–Ú– –XÚ– ––– X–Ú– X–Ú– ‹
‹ – – – – –– – – – – ‹‹
==
? XÚ–– ======= – – – – XÚ–– XÚ– b XÚ– XÚ– XÚ =‹ XÚ–– ======== –– – =‹ – ======== –=
– –– – – – – – –– –– –– – –– – – –
— —— X——Û X———Û _X——Û— X———Û —— —— _X——Û— _X——Û— _X——Û _X——Û— X———Û
« ——
a —— ——XÛ X——Û— X——Û . X——Û X——Û X——Û— _X—Û—
XÛ X—Û XÛ XÛ—
==
& XÚ––– ============ ¥ ‹ ============‹
_X—Û— ——— X———Û X——Û X——Û . X——Û j
# —
X
Û
—— a ¥— — — — — — — ¥— — — — a j
XÛ — — — — —
X
Û — — — —
X
Û — — —
— —
—
— —
—
—— —— —— —— X——Û ——— ———
‹ ‹ ==
& XÚ––– ======= XÛ ‹ XÛ—========
_ X
Ú
–
XÛ XÛ— . XÛ XÛ— X—Û XÚ–– XÚ– XÚ– X—Û XÚ– XXÛÚ– XÚ–– ‹
j — J
a a XÚ–– # XÚ–– XÚ––– XÚ–– XÚ– n_XXÛÚ– . XÚ–– XÛ= X
Ú – # X—ÛXÚ–– XÚ–– XXÛÚ–– XÚ– _XEÛÚ– XÛ XÛ XÚ–– XÚ–– XXÛ—Ú–– XÚ–=‹ _XÛXÚ–X—Û—========
– ‹ –– XÚ––
–
XÚ–– –– ––– –– XÚ––– ––– –– –– ‹
– –
——— — — — —— X——Û —— ‹‹ —— _X——Û— ——— X———Û X———Û _X——Û— X———Û —— —— _X——Û— ‹‹
_XXÛÚ– . _ _XÛ ‹ XXÛ—Ú XÚ– b_XÚ– XÚ X—Û _ _XÚ– _ _ n_XÛ n XÛ— _ ‹ J– – –– –– –– –– ‹‹ ––– –– – – – –– –– ‹ ‹
XXÛÚ– XÚ–– XÚ– XÚ– XÚa XÚ– XX—Û—Ú X—Û XXÛ—Ú– — ‹ ‹ —
— —
— — — — — — — —
== – –
? – ============ – – – – – X
Ú
– X
Ú – ––– # XÚ–––
– –
–– –– –– # XÚ– XÚ– ––
‹‹ –– =========== –– ––
XÚ––
– =‹‹
a —— ——— #_X——Û— _X—Û . ‹ ‹ _ X
Û _X—
Û — — — — — —
— ——— X——Û ‹‹
— _ X
Û _
– – –– – –– –– –– –– XÚ– XÚ–– XXÛÚ–– XÚ– XXÛÚ––– XÚ––– EÚ– ‹ XÚ XÚ– XÚ– XÚ XÚ ‹ XÚ XÚ––– XXÛÚ–– # XÛXÚ–– X—Û XXÛÚ– X—Û EX—Ú–Û– XÛ ‹
==
? –– ======= ‹‹
« – –– –– –– =‹‹ ––– ======== –– –– ––– XÚ–– XÚ– XÚ– # XÚ XÚ–––– # XÚ–––– ––––– =‹‹ ––– ========
–– – –– ––– _XÚ–– –– –– –
– – –– –
—
E—Û X
——Û— . # XX——ÛÚ X——Û XÚ–
X Ú . – X Ú
X——Û XÚ– # XX——ÛÚ– XÚ– XÚ– X——Û n X——Û X——Û— X———Û ——— X——Û ——— ——
«
==
& a============
XÚ–– XÚ––– XÚ––– –––
–
––– ––– XÚ––– ––– = ––– –– –– –– XÚ––– XÚ––– a XÛa XÛ =
‹ XÚ––– =========== J X Ú
–
X—Û ‹
— — — — — — — — —— —— _X——Û —— —— —— — — — j — j j — j
‹ J– ‹
4.5. SPACING, LINE BREAKING, AND PAGE FILLING

— — — ‹ ==
XX—Û—Ú X—Û X—Û— X——Û XX——ÛÚ XX——ÚÛ– b XX—Û—–Ú X—Û XX—Û–Ú XÛ XÛ XX—ÚÛ–– X—Û XX—Û—Ú X——Û X——ÛX——Û . X——Û X—Û—j — —X—Û — X—Û — X——Û X——Û XÚ– X——Û b XX——ÛÚ X——Û—XÚ X—Û— XÚ XX——ÚÛ–
– – – XÚ– – = – ‹
—— — —
— —
— —
— —
—
—— —— —— — ‹‹ — — — — —— — — — ‹ & ––– ========= ––– –– –– – –– ––– =‹ XÚ–========
‹ ––
XÚ–– XXÛÚ–– XXÛÚ–– X—Û X—Û =‹ XÚ–– ======
– – –
__XÛ XÚ– _XÚ– _XÚ–– _XÛ—_XÚ– XÚ– _
X Û
Ú
– —
X
Û _
X
Û —
XÛ
__XÛ _XÛ— _—XÛ X—Û— ‹ _X—Û —— X—Û— _X—Û _XÛ— _X—Û X—Û— —— ——
X
Û XÛ XÛ ¥ ‹ ‹ J– – J–– –– –– –– – ‹
‹ ‹
X–Ú – –– – – – X–Ú XÚ– –
– – – – – – J a ‹ a XÚ ‹ — —— —— —— _X——Û — —— —— _X——Û —— —— ‹‹ ‹
==
? ============ ¥ ‹
============ X
Ú
XÚ–– ––– –– =‹ – ‹— —
– __XE—ÛÚ– . __XÛ—__X—Û _X—Û __ _XX—Û—–Ú __XÛ— __XX–ÚÛ— ____XXÛ—Ú–– __X—Û ‹ XÚ X–Ú XÚ– XÚ
– –
– – – ‹ – – – X Ú
—X—Û— XÚ X——ÚÛ—–
X Ú –
‹ X—Û— —— —— —— —— . X——Û— ——— ——— X——Û ‹
‹ — — —
X
Û X
Û X
Û —
X
Û ‹
XÛ XÛ
« ==
? – ========= =‹ –– ======== –– ––– –– ––– XÚ–– XÚ– XÚ– XÚ– XÚ–– ––– ––– ––– XÚ=‹ w======
– –– –– – – – ––– =‹
a — — — — —
X
—— —— —— —— j
—Û XÛ— # XX—ÛÚ X—Û X——Û—Ú– . XÚ– XÚ– @XÚ X—Û— X——Ú–Û– X——Û # X——Û— XX—ÛÚ– XX—ÛÚ– XÚ– XX——Û—Ú– # XX——ÚÛ X——Û X——Û— X——Û X——Û X—Û— ——— X——Û X——Û— X——Û X——Û XX——ÚÛ
«
==
& XÚ–– ============– – – – # XÚ– n XÚ– XÚ # X—Û
‹ –– =========== ––– ‹ —— —— X——Û —— —— —— —— — — — —
— _
X
Û —
X
Û — — — — — — — — — — —
— —
— —
—
—— —— —— —— —— —— —— . X——Û _E———Û
_XÛ __
– – –– –– –– ––– ––– XÚ––– –– = ‹ – – –– –– –– ––– XÚ––– XÚ–– XÚ––– XÚ––– =
– ‹ b
‹ ‹ ==
& =– ========
XXÛ—Ú– . XÛ XÚ–– XÚ– XÚ– XÚ–– XXÛÚ XÚ–– XÛ XXÛÚ–– XXÚÛ–– XXÛÚ–– XÛ—XÚ– EX—ÛÚ– b XÚ– XÚ– XÚ XÚ @ X——Û X——Û n X—Û— X—Û XÛ— XÛ XÛ XÚ XX—ÛÚ– X——Û X—Û— X—Û X—Û XÛ— XÚ––– XÚ–– EEÛ—Ú–––
– – – – – – – – X
Ú – X
Ú – =\
‹ — — — — ‹ – – – – –– – – – – =‹‹ – ========= – –– –– ––– –– ––– XÚ–– XÚ––
– – XÚ–– . ––– ‹‹ – ====== @– –
‹ a ——— # X——Û # X——Û X——Û— . n XÚ X—Û X—Û— X——Û _X—Û ‹ ‹ – ‹
. XÚ–– XÚ– X–Ú XÚ–– XÚ ‹ XÚ–Û– XÚ–– XÚ– ––– XÚ–– ‹ — —————
==
? XÚ–– ============ –– –– –– – XÚ–– XÚ–––– XÚ––– ––– XÚ––– XÚ–– =
– ‹ X–Ú–– =========== J– J– J =‹ ‹ _w
‹
J X
——— X——Û— X——Û— X——Û ——XÛ— X———Û —— —— —— X——Û X———Û— X———Û b X—Û— ———XÛ— ‹‹ X——Û ——— X———Û X——Û— X——Û X—Û— _X—Û X——Û E——Û
Û XÛ XÛ— XÛ ‹

Figure 4.24: The Bach fugue (BWV 846) set by the optimum page fill algorithm
—w
« ==
? =========
‹‹ w XÛ
==========‹ w====== =\
117

(c) Kai Renz, musical data taken from MuseData database and automatically converted to GUIDO
«
118 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

27/2/2036.48 27/4/1777.37 27/6/1955.95 27/8/2935.19 27/9/3046.15 27/11/2457.36

26/2/1859.54 26/4/1739.95 26/6/2014.49 26/8/3605.34 26/9/2863.77 26/11/2280.42

25/2/1574.11 25/4/1752.69 25/6/2731.94 25/9/2462.75 25/11/1959.91

24/2/1629.73 24/4/1904.27 24/6/2758.98 24/9/2170.19 24/11/1749.31

23/2/1523.60 23/4/2502.84 23/6/2586.60 23/9/2057.72 23/11/1636.84

22/2/1645.99 22/4/3021.97 22/6/2260.09 22/9/1757.25 22/11/1371.45

21/2/2376.45 21/4/2520.12 21/6/1931.33 21/8/2079.47 21/9/1510.45 21/11/1397.21

20/1/3147.68 20/2/3094.24 20/4/2176.37 20/6/1673.53 20/8/1567.35 20/9/1287.73 20/10/2168.44 20/11/1562.27

19/2/2579.21 19/4/1862.89 19/6/1413.25 19/8/1300.01 19/11/2279.25

18/2/2110.94 18/4/1522.15 18/6/1136.35 18/8/1410.89 18/11/3004.18

17/2/1763.31 17/4/1299.87 17/6/1154.30 17/8/2133.54 17/11/2695.42

16/2/1461.49 16/4/1011.85 16/6/1286.39 16/8/2879.68 16/11/2177.81

15/2/1150.79 15/4/972.124 15/6/1951.36 15/9/2956.14 15/10/3225.05 15/11/1739.58

14/2/1065.92 14/4/1044.65 14/6/2637.93 14/8/2461.47 14/9/2496.45 14/10/2765.37 14/11/1529.37

13/2/886.540 13/4/1671.12 13/8/2052.50 13/9/2317.07 13/10/2585.99 13/11/1336.18

12/2/810.913 12/4/2404.20 12/8/1705.90 12/9/1578.37 12/10/3319.07 12/11/989.580

11/1/1561.87 11/2/1541.99 11/6/2187.95 11/8/2456.86 11/9/1220.86 11/10/1740.54 11/11/757.413

10/6/1612.79 10/9/896.470 10/11/717.802

9/6/1113.57 9/8/650.127 9/11/1434.70

8/4/1734.92 8/6/796.896 8/8/618.229

7/4/1132.64 7/6/553.791

6/4/669.170 6/6/490.502

5/4/441.509

4/2/835.235 4/4/371.609

3/2/291.758

2/2/188.106

Figure 4.25: The calculated graph for the optimum page fill of the Bach fugue (BWV
846)
4.6. CONCLUSION 119

Further Thoughts on Line Breaking

Some of the assumptions used when describing the optimal line break and page
fill algorithm must be reconsidered: mainly the assumption that slices are simply
treated as measures does not hold for all types of music. There are scores, where
breaks in between measures are necessary and lead to much better scores than
it is the case if only complete measures can be broken. Additionally, some music
does not contain measures, or different voices/staves can contain different meters
and therefore different bar lines. Then, the question of detecting suitable break
locations gets complicated. In rare cases, music can be constructed that contains
no possible break locations, because there are no common onset times for all given
voices (see also the AutoBreaks-algorithm on page 73).
Another issue that has to be mentioned is the question of how the slices are merged
and how rods are treated that lie at slice boundaries. In the case of bar lines, the
issue is pretty straight forward. If other break locations are considered, it must be
asserted that several slices can be merged into one line without visible disruptions.
Finally, Knuth’s line break algorithm has been fine tuned over a period of time by
carrying out user experiments. For example, Knuth mentions how loose lines being
followed by tight lines disturb the visual appearance. When dealing with optimal
line breaks, the fine-tuning of the penalty function  and the setting of the optimum
force and the allowed penalty for individual lines must be carefully adjusted. This
certainly requires some experience with a large body of scores.

4.6 Conclusion
This chapter dealt with the process of converting an arbitrary G UIDO description
into a matching graphical representation of a score. First, it was shown that some
of the required music notation algorithms can be directly described as G UIDO to
G UIDO transformations. Then, those music notation algorithms, which operate di-
rectly on the Abstract Representation were presented. In the following, the graphi-
cal requirements for any conventional music notation system were exemplified and
the Graphical Representation (GR), which is an object-oriented hierarchical struc-
ture representing all visual elements of a score was introduced. Subsequently, the
conversion of a G UIDO description (and its corresponding AR) into the matching
GR was explained. Finally, an improved algorithm for spacing a line of music was
presented. Additionally, a completely new algorithm for optimal page fill was intro-
duced, which makes optimal use of all pages required by the score.
The algorithms and procedures described in this chapter show that the creation of
a score is a complicated task that strongly depends on the underlying data struc-
ture. In order to create “good” music notation, great care has to be taken when de-
signing the overall structure and the available manipulation routines. Overall, the
creation of conventional scores can be managed (at least partially) by using clever
120 CHAPTER 4. CREATING THE CONVENTIONAL SCORE

algorithms.
Obviously, some issues, which are essential for creating esthetically pleasing music
notation, have not been discussed, although they have been – at least partially –
implemented in the current system. These issues concern subjects like a completely
automatic collision detection (and prevention) or, for example, the exact and com-
plete description of how to calculate beam-slopes for any conceivable case. While
some of these techniques have been described elsewhere (see for example [Gie01]),
some have not been dealt with in the accessible literature. A system capable of
automatically avoiding all sorts of collisions of musical symbols has not been yet re-
alized, although it seems that progress using “intelligent” approaches is possible; a
fruitful endeavor might be the use of random local search algorithms in conjunction
with evaluation functions to avoid local collisions of symbols. It is nevertheless a
futile task to estimate if such a system will be available in the near or more distant
future.
Chapter 5

Applications

The previous chapters dealt with the algorithms and data structures involved dur-
ing the conversion of arbitrary G UIDO descriptions into conventional scores. This
chapter now presents the notation system, which has been designed and imple-
mented during work on this thesis. All of the ideas presented in the previous chap-
ters are incorporated in the so called G UIDO Notation Engine (GNE). The objective
of the GNE is the conversion of an arbitrary G UIDO description into a graphical
score. The GNE is realized as a platform independent library, which offers well
defined interface functions that can be used by applications, which require conven-
tional music notation to be displayed. The GNE has been compiled as a Dynamic
Link Library (DLL) for Windows and as a shared object library for Linux. As the
complete source code is written using ANSI C++, it is easily possible to compile the
notation engine on other systems. Currently, three different output mechanisms
for a graphical score exist when using the GNE: a score can be retrieved as a GIF
picture (which is a bitmap format), or it can be drawn directly into a window (us-
ing operating system dependent drawing routines), or a so called G UIDO Graphic
Stream (GGS) can be retrieved, which is a platform independent way to describe a
rendered score. The first two retrieval methods are currently available only when
using the Windows-DLL, while the third approach is available using Linux or Win-
dows.
At the moment, the GNE is used in three different application contexts: in connec-
tion with a standalone notation viewer, as an online service using standard Internet
services, and as a (prototypical) interactive notation editor based on Java. These ap-
plications together with extensions made possible through them, are presented in
this chapter.

5.1 The G UIDO NoteViewer

The G UIDO NoteViewer is an application for displaying and printing musical scores,
which are created from arbitrary G UIDO descriptions. The application is currently

121
122 CHAPTER 5. APPLICATIONS

running on Windows PCs. As the name suggests, the G UIDO NoteViewer is not a
notation editor. The NoteViewer reads G UIDO descriptions and creates a screen
display or a printer output of the rendered score. The user can zoom in and out of
the score; it is possible to scroll within the window and to change the displayed page
number. The G UIDO NoteViewer is somewhat similar to the Acrobat Reader, which
displays PDF documents, but does not allow them to be changed interactively.
Figure 5.1 shows a screen shot of the G UIDO NoteViewer. The G UIDO description of
the score in the lower window is visible in a text-editor.

Figure 5.1: The G UIDO NoteViewer

5.1.1 Architecture of the G UIDO NoteViewer

The G UIDO NoteViewer is a combination of several components, which are shown in
Figure 5.2. Within the main module, which is called gmnview.exe, flow control is
handled through the “Flow control”-unit. User input consists of either a G UIDO
description or a MIDI file. If the input is a MIDI file, it is first converted into
5.1. THE GUIDO NOTEVIEWER 123

a G UIDO description using the midi2gmn component, which has been realized by
J. Kilian [Kil99]. The flow control unit then sends the G UIDO description to the
GNE (called nview32.dll), where it is prepared and converted into an internal score
representation, as it was shown in the previous chapters. The flow control unit also
creates a window on the screen, in which the GNE directly draws the score using
functions supplied by the operating system. All user interaction (like, for example,
the zooming or changing of the page number) is handled by the flow control unit,
which sends formatting information to the GNE, which then redraws the score.
Another component deals with audio playback using MIDI: the flow control unit
sends a G UIDO description to the gmn2midi module, which creates a MIDI file.
This MIDI file is then played using routines provided by the operating system.
A text editor window within gmnview.exe can be used to edit the textual G UIDO
description of any displayed score. If the G UIDO description is changed by the user,
the flow control unit resends it to the GNE, which then redraws the score in the
respective score window. The changed description may also be saved in a file.
Printing is handled similar to screen-display: all the printing commands are gener-
ated by the GNE through functions provided by the operating system.
The communication between the flow control unit and the individual modules fol-
lows a well defined interface, which is partly described in the following subsection.

GUIDO description MIDI file

sends GUIDO
sends MIDI file
description and
formatting in− midi2gmn
formation Flowcontrol creates GUIDO
description

nview32.dll
(Notation Engine) plays sends GUIDO description
converts GUIDO MIDI file
description into gmn2midi
creates
conventional score sends
GUIDO MIDI
user− File
Text Editor
input creates
draws in window
window
Scorewindow

gmnview.exe

Figure 5.2: The Architecture of the G UIDO NoteViewer

124 CHAPTER 5. APPLICATIONS

5.1.2 Interface Functions of the GNE

There are more than twenty interface functions that can be used to interact with
the GNE. In the following, only the most important ones are shortly described:

 nview parse This function is used to start a new conversion process: a file-
name for a G UIDO description file is provided; the file is parsed by the GNE and
converted into an internal score-representation. Finally, an integer-handle is
returned to the caller. This handle is then used in all of the following routines
to uniquely specify the process.

 FreeHandle This routine is called, when a process can be terminated (this

happens, if a user closes a score-window). In this case, the GNE frees the
internal storage space for the process, which is identified through the unique
handle.

 OnDraw This function is used for score display and printing. Additional format-
ting information is supplied by the caller: a zoom-factor, scrolling-parameters,
a page-number, the size and a handle of the display-window. Additionally, a
flag can be set to trigger printing or Postscript-output. The GNE then draws
(or prints) the score within the window (or on paper).

 getNumPages This routine can be used to determine the number of score pages
that were created by the conversion process. This is important for handling the
scrolling and printing of individual pages.

 exportMusic This routine retrieves the transformed G UIDO description: as

was shown in the previous chapters, the conversion of an arbitrary G UIDO
description into a score can be described as a G UIDO to G UIDO transformation.
exportMusic returns the final G UIDO description, which is the result of all
transformation routines contained in the GNE.

Several more interface functions are provided that are used in different application-
contexts, which will be described later in this chapter.

5.2 The G UIDO NoteServer

Two aspects of G UIDO Music Notation make it an ideal candidate for online us-
age: first, it is a text-based language, which means it can be created very easily
either by hand or automatically; second, it is adequate in the sense that a sim-
ple score has a simple G UIDO description. The second feature also implies that
simple G UIDO descriptions can often be understood intuitively. As an almost natu-
ral consequence, an online score notation service based on G UIDO Music Notation
was developed. This application, which was realized using the GNE, is the G UIDO
5.2. THE GUIDO NOTESERVER 125

NoteServer. The G UIDO NoteServer is a free online service, which converts G UIDO
descriptions into images of conventional scores, which can be displayed in a stan-
dard Internet-browser [RH98, RH01]. Figure 5.3 shows a screen shot of the G UIDO
NoteServer: on the left, the default input page is shown; on the right, the resulting
score image is displayed.

(b) Result Page

(a) Input Page

Figure 5.3: The G UIDO NoteServer

The G UIDO NoteServer is realized as a collection of Perl-scripts [WCS97] and sev-

eral executables. The notational logic is encapsulated in the same Dynamic Link
Library (nview32.dll) that is used within the G UIDO NoteViewer. Figure 5.4 shows
the basic architecture of the G UIDO NoteServer. First, a G UIDO description is cre-
ated using one of the methods shown at the top: several converters can be used to
transform different music representation formats into G UIDO descriptions, for ex-
ample converting MIDI files or the MuseData format. The G UIDO description is
sent to the NoteServer using CGI, which is a client-server-protocol supported by al-
most any web server and browser. Within the NoteServer, the G UIDO description is
converted into a score by using the GNE. The formatting parameters are first eval-
uated using Perl-scripts; then, the necessary executables are called. Finally, the
output is created and the result is sent back to the calling client.
Several access modes for the G UIDO NoteServer exist, all of which will be described
in the following.
126 CHAPTER 5. APPLICATIONS

Sibelius
Finale
Score Database
MIDI Score
or MIR System
(Converted
(Converted with from other
midi2GMN) Notation Packages)
Coded by hand
GuidoXML
G UIDO description
(eg. [ c d e f g])
Virtual Keyboard
CGI or
Secure Socket Layer

GIF of Score
GUIDO NoteServer
PERL script
(administration)

uses/renders
GMN2GIF
EPS of Score
G UIDO
Notation
GMN2EPS Engine

Communi−
cation
GMN2MIDI using
MIDI of Score G UIDO
Graphic
Stream

Interactive score display JAVA Applet

and editing (platform independent)

Figure 5.4: Architecture of the G UIDO NoteServer

5.2. THE GUIDO NOTESERVER 127

5.2.1 Browser-Based access

The simplest access to the G UIDO NoteServer is the usage of any standard web
browser. As was shown on the left of Figure 5.3, the NoteServer web page allows the
entry of a G UIDO description together with additional formatting parameters (like,
for example, the zoom factor). The user sends the G UIDO description by pressing
the send button. Then, the image of the respective score is returned as a GIF image,
which is directly shown in the browser window. It is also possible to listen to the
music matching the score by playing the automatically created MIDI file. Because
only standard Internet protocols are used, the browser-based access is completely
platform independent. The text-based entry is obviously useful for creating simple
scores “on-the-fly”. Sometimes, scores need to be embedded within a web pages or
within other applications. This can be be realized by using the CGI-based access,
which will be described next. The standard browser-based access is internally im-
plemented using CGI, but the details of this are hidden from the user.

5.2.2 CGI-Based access

A more advanced way of accessing the G UIDO NoteServer is the usage of CGI (Com-
mon Gateway Interface) [cgi02], a well defined method of interaction between clients
and servers on the Internet using HTML. The NoteServer consists of three main
services, all of which are realized as Perl-scripts, which can all be accessed using
CGI:

 noteserv: this script gets a G UIDO description with additional formatting

parameters and returns a complete web page including additional links (for
example to the MIDI file to realize audio-output) and for accessing different
pages.

 gifserv: this script gets a G UIDO description and additional formatting pa-
rameters and simply returns an image of the score. This service is very useful
for third party applications, that do not need a complete web environment, but
just want to include the score-image within their own environment.

 midserv: this script takes a G UIDO description and returns a MIDI file, which
can then be directly played on the client computer using a standard sound-
card.

CGI-based access is realized through especially formatted URLs (Universal Re-

source Locators), which are just the standard web addresses. In the case of the
NoteServer, a typical CGI-URL looks like this:

http://www.noteserver.org/scripts/salieri/gifserv.pl?defpw=16.0cm&
defph=12.0cm&zoom=1.0&crop=yes&mode=gif&gmndata=%5B%20c%20d%20e%20%20%5D%0A
128 CHAPTER 5. APPLICATIONS

The first part is a standard web address; after the question mark, a series of name-
value-pairs are separated by ampersands. In the URL above, the following variables
are used:
 defpw=16.0cm This sets the default page width to 16 cm.

 defph=12.0cm This sets the default page height to 12 cm.

 zoom=1.0 This sets the zoom factor to 1.0.

 crop=yes This sets the page-adjust-flag. This ensures, that only that portion
of a page that contains the score is returned as the image.

 mode=gif This ensures, that a GIF-image is returned (and not a postscript-

file).

 gmndata=%5B%20c%20d%20e%20%20%5D%0A This is just an encoding for the

G UIDO description [ c d e ].
There are some additional variables, which are used in other application-contexts.
The creation of CGI-URLs is greatly facilitated by Perl-routines; therefore, it is quite
simple to use the CGI-based access mode. Internally, every single application using
the G UIDO NoteServer is using the CGI-based-access mode.

5.2.3 Usage of JavaScript

In order to facilitate the usage of the CGI-based access and to make it possible to
easily include images of music scores in web pages, some routines have been written
using JavaScript [Fla98], a scripting language that can be used in web pages, which
are written using HTML, and which are interpreted by the client browser. Fig-
ure 5.5 shows the HTML source code including two (relatively simple) JavaScript
functions, which are used to dynamically generate the score picture shown of the
right. Note that the G UIDO description is directly embedded in the HTML source
code of the page: by simply changing the G UIDO description, the score being dis-
played changes as well. When looking at the HTML source of Figure 5.5, one aspect
has to be pointed out: the G UIDO description must be syntactically changed to follow
the syntax of JavaScript. Each backslash in the original G UIDO description is du-
plicated; otherwise, JavaScript would interpret the backslash as a control-character
(similar to the C-programming language).
The following functions are provided for the use of JavaScript:
 GetGIFURL This function takes a G UIDO description and returns the URL that
converts the given description into a GIF-file.

 GetMIDIURL This function takes a G UIDO description and returns the URL
that converts the given description into a MIDI file.
 <html> <head>
<title>How to embed Music Notation in WEB pages
using JAVAScript</title>

<script language=’’JavaScript’’>
// this functions takes a GMN-string and returns the URL
// that converts it into a GIF-file
function GetGIFURL(gmnstring,zoom,pagenum)
{
gmnstring = escape(gmnstring);
gmnstring = gmnstring.replace(/\//g,"%2F");

var string = "http://" + noteserveraddress +

"/scripts/salieri" + versionstring +
"/gifserv.pl?";

if (!zoom) { zoom = "1.0"; }

if (!pagenum) { pagenum = "1"; }

string = string + "pagewidth=21";

5.2. THE GUIDO NOTESERVER

string = string + "&pageheight=29.7";

string = string + "&zoomfactor=" + zoom;
string = string + "&pagesizeadjust=yes";
string = string + "&outputformat=gif87";
string = string + "&pagenum=" + pagenum;
string = string + "&gmndata=" + gmnstring;

return string;
};
// This function takes a GUIDO string, accesses the
// NoteServer (address specified as a constant above)
// and then embeds the GIF-Image in the document.
function IncludeGuidoStringAsPict(gmnstring,zoom,pagenum)
{
if (!zoom) zoom = "";
if (!pagenum) pagenum = "";

document.write("<img src=" +
GetGIFURL(gmnstring,zoom,pagenum) + ">");
};
</script>

Figure 5.5: Using JavaScript for embedding music notation

</head>
<body>
<script>IncludeGuidoStringAsPict(
’[ \\clef<"treble"> _/8 g g g \\bar e&/2 ]’,
’0.6’);
</script>
</body> </html>
129
130 CHAPTER 5. APPLICATIONS

 IncludeGuidoStringAsPict This function takes a G UIDO description and

then creates the HTML code necessary to embed the given description as a
GIF-image at the current position in the document.

 IncludeGuidoStringAsMIDI This function creates a hyper link to access the

MIDI file that matches the given G UIDO description. The hyper link is placed
at the current document position.

 IncludeGuidoStringAsApplet This function creates the HTML code neces-

sary to place a Java-Scroll-Applet (which will be described in the next section)
at the current location in the document.

For each one of the above mentioned JavaScript routines, there exists an additional
function, that takes a G UIDO-URL instead of a G UIDO description. A G UIDO-URL
is just a standard web address, which points to a valid G UIDO description. Using
this mechanism it is possible to easily create a score display for G UIDO based music
databases.

5.2.4 The Java Scroll Applet

Because sometimes the scores that need to be embedded in web pages become quite
large, another approach using Java has been implemented. The developed Java
Applet uses the G UIDO NoteServer to display the image of a score. The image is
scrollable and it is further planned to realize an adjustable zoom factor. Figure 5.6
shows the Java Applet in a web page.
The shown Java Applet uses version 1.1.8 of Java, therefore, it runs on almost any
platform.1 The basic structure of the scroll Applet is quite simple: the CGI-based
access to the NoteServer is used to retrieve a GIF-image of the score. This GIF-
image is then displayed within the scrollable area of the window. Because Java
offers very easy to use routines for accessing Internet content, the realization of the
scroll Applet was fairly easy. Because of Java security issues, the Applet must be
stored on the same machine as the G UIDO NoteServer. Although it is possible to
adjust the security level for an Applet, it is generally very important to ensure, that
only trusted Applets are allowed access to other computers on the Internet.

1
Newer versions of Java (beginning from 1.2) do not run on Macintosh Computers with OS 9 and
before. Using the older Java version ensures that the scroll applet can be used by almost all Internet
users.
5.2. THE GUIDO NOTESERVER 131

Figure 5.6: The Java Applet for score display

5.2.5 The Java Keyboard Applet

In order to facilitate the learn-
ing of G UIDO, a “virtual” key-
board was realized as a Java Ap-
plet. Figure 5.7 shows the Java
Keyboard Applet in a standard
browser. Whenever one of the
“keys” on the virtual piano is
pressed (by clicking it with the
mouse), the score display and the
G UIDO description below is up-
dated. Recently, an enhance-
ment was realized, which triggers
an audio-feedback when a key is
pressed.
Basically, the keyboard Applet
has a similar internal structure
as the scroll Applet from above.
Obviously, the continuous update
of the display and the G UIDO
description requires some more
internal logic; nevertheless, the
part, which is concerned with the
score display is exactly the same. Figure 5.7: The Java Keyboard Applet
132 CHAPTER 5. APPLICATIONS

The keyboard Applet is an excellent tool for learning how to write music using
G UIDO. Because both the score and the G UIDO description are shown in paral-
lel, and because the text can be edited directly, the intuitive nature of G UIDO can be
easily seen. By supplying buttons for the most common musical markup (like clef,
key, and meter), the user directly learns, how tags are used within G UIDO descrip-
tions.

5.3 Java-based Music Notation and Editing

The notation applications presented in this chapter so far are all music notation
viewers. They are static, as the score notation is presented without the ability to
directly edit any of the graphical elements. The displayed score can only be changed
by editing the underlying G UIDO description.
In this section, the (prototypical) Java-based music notation editor is presented. The
fundamental idea was the creation of a platform-independent notation editor that
is also usable for online applications within web browsers. Figure 5.8 shows the
realized Java application for displaying and editing music notation. All graphical
elements shown are movable; new notes can be added.

Figure 5.8: Java-based music notation and editing

The general architecture of the Java-based music notation editor is shown in Fig-
ure 5.9. The layout is a standard client-server-application; in this case, the client is
the Java-based music notation editor and the server is the G UIDO Notation Engine.
Communication between the client and the server is done using a newly defined
protocol language, which is called G UIDO Graphic Stream. This protocol language
will be described in the next subsection. Additionally, a “FontServer” has been de-
veloped: this server is needed to create images of musical symbols that are needed
for score display. Because the Java version being used for the development of the
editor does not allow the usage of arbitrary fonts, the FontServer had to be devel-
oped to guarantee platform independent notation. The FontServer not only creates
5.3. JAVA-BASED MUSIC NOTATION AND EDITING 133

the image of the symbol, but also returns information on the bounding-box, which
is needed for hit-testing when reacting to user input.
Two interesting features have been (partially) implemented in the notation editor:
hit-testing and editing-constraints. Hit-testing is the process required when evalu-
ating, which element needs to respond to a mouse-click. In the current implemen-
tation, a grid is used to identify those objects that might be candidates for a hit.
Editing-constraints define allowed movements for musical symbols: a note head, for
example can only be vertically placed directly on a staff-line or in the space in be-
tween. All other vertical positions are not allowed. Therefore, when moving a note
head, it must be ensured that the final location is at an allowed position.

Client Server
Internet
Java Music Notation Editor GUIDO Notation Engine
− interprets GGS GUIDO − converts GUIDO
− displays score Graphic description into GGS
− handles user interaction Stream − sends and interprets GGS
− creates and sends − updates GUIDO description
GGS for editing
requests
symbol
Font Server
− provides images of
sends
music notation elements
image

Figure 5.9: Architecture of the Java-based music notation editor

5.3.1 The G UIDO Graphic Stream Protocol

The G UIDO Graphic Stream (GGS) is a text based protocol language for describing
the graphical elements of a score. GGS is not nearly as powerful as generalized
graphical descriptions languages (like Postscript, or Portable Document Format).
Its focus lies on a rather simple description of the position of elements visible on a
score page. Even though GGS is a simple format, it can not only be used to visually
describe the score, but also to transmit editing instructions. For a quick under-
standing of GGS consider the text and the score being shown in Figure 5.10. The
individual parts of the GGS-text are linked to the score by arrows.
Each GGS-command looks like a G UIDO tag. It begins with a backslash followed by
a command name and optional parameters. One very important point of the GGS is
134 CHAPTER 5. APPLICATIONS

\unit<25>
\open_page<4979,7042>

\draw_staff<1,5,474,674,594>

\draw_image<"treble_clef",2,417,824>

\draw_image<"ledger_line",3,444,724>
\draw_image<"qnotehead",3,495,724>
\draw_stem<3,525,724,175>

\draw_image<"qnotehead",4,686,699>
\draw_stem<4,716,699,175>

\draw_image<"qnotehead",5,877,674>
\draw_stem<5,907,674,175>

\draw_image<"endbar",6,1028,674>

\close_page

Figure 5.10: The G UIDO Graphic Stream for a score

the use of unique (integer) identifiers, which are used to group and identify individ-
ual graphical elements. Different GGS-commands may use the same id to specify
that all graphical elements using this id are treated as a unit. This can be seen
in Figure 5.10, where the individual notes are created from note heads and stems,
which share the same id. The id is also used for sending editing instructions from
the client to the server. An editing instruction might look like nmove<4,725,599>
which instructs the server to move the element with the id 4 to the given position.
Currently, only a small subset of the GGS is actually implemented in the G UIDO No-
tation Engine; it is planned to realize a complete GGS output for all implemented
notational elements. The fully implemented GGS would directly result in a com-
pletely platform independent music notation viewer (and editor).
The conversion of a GGS description into another document oriented format, like
(encapsulated) Postscript or PDF, is very easy, because it merely requires a one to
one conversion of GGS-commands into other drawing commands.

5.4 A Musical Database System and Music Infor-

mation Retrieval
G UIDO Music Notation has been used as a music representation language in the
context of Music Information Retrieval (MIR) [HRG01]. MIR applications are con-
cerned with the retrieval of musical data from musical databases. Music Informa-
tion Retrieval distinguished between audio based and structure based music rep-
resentation. Audio-MIR works on concrete audio files (like WAV or mp3), while
structure based MIR currently mostly uses MIDI for describing music. In [HRG01]
5.5. CONCLUSION 135

it was shown that G UIDO is an ideal candidate for structure based MIR. The (pro-
totypical) system, which was developed, allows the search for a musical melody (or
fragments of such) in a body of scores, which are stored as G UIDO descriptions in a
database. The search is specified using an enhanced form of G UIDO. If a match is
found in the database, the score can be retrieved, where the location of matches are
highlighted. This highlighting is made possible by an enhancement of the G UIDO
NoteServer: the interface was extended to offer the possibility to mark certain frag-
ments of a score. An example of such a highlighted score can be seen in Figure 5.11.
On the left, the search phrase [ g f e d ] can be seen; on the right, a score is
displayed, where the found search pattern is shown in red.

Figure 5.11: Music Information Retrieval

By using the G UIDO NoteServer to display the result of the query, all of the present
features can be fully exploited. The user can listen to the music and scroll to other
parts of the score. It is also possible to embed the image of the score on other web
pages or in research papers.

5.5 Conclusion
The applications presented in this chapter give an overview of the variety of mu-
sic notation applications made possible through the use of G UIDO Music Notation.
136 CHAPTER 5. APPLICATIONS

Even though the developed applications are used by a growing number of people
around the word, it became clear during the work on this thesis that the develop-
ment of a complete notation system is an enormous, never-ending task. In spite
of the incomplete nature of the music notation system, the general idea of using
G UIDO and especially the online aspect of music notation is interesting for many
users. Because online music notation and editing has not been presented elsewhere,
it seems like a fruitful endeavor to further improve the G UIDO Graphic Stream and
the Java-based editor. A more complete notation editor could be easily used for on-
line music education tools. Overall, the collection of applications proves that G UIDO
Music Notation and the G UIDO Notation Engine are a solid foundation for music
notation applications.
Chapter 6

Conclusion

Many music notation systems have been developed since computers are being used
for music processing. While most systems are capable of automatically creating
nicely formatted scores of simple music, a completely automatic system for complex
music has not yet been build. The reason for that lies in the complexity of a musical
score, where different, sometimes contradictory constraints have to be met. Very of-
ten when setting complex music, some typesetting rules have to be explicitly broken
in order to get a reasonable result. Currently, human interaction is indispensable
when producing high-quality scores.
In this thesis, the internals of a new music notation system were presented; it differs
from other systems by its underlying music representation language. Using G UIDO
Music Notation as the input language for the implemented music notation system
created insights in the general procedures which are necessary when automatically
creating conventional scores. Because G UIDO is an adequate, intuitive text-based
language, the creation of musical data, represented as a G UIDO description, is fairly
easy. Nevertheless, the process of automatically creating a graphical score from an
arbitrary G UIDO description is far from trivial.
As G UIDO descriptions are human readable plain text, the conversion into a graph-
ical score requires a number of steps. First, it was shown that G UIDO descriptions
can be converted into a so called G UIDO Semantic Normal Form (GSNF). The defi-
nition of the GSNF was very helpful for defining an object-oriented computer-suited
representation for G UIDO, which is called Abstract Representation. A G UIDO de-
scription in GSNF is converted into a one-to-one corresponding instance of the Ab-
stract Representation. This instance is used for storing, manipulating, and travers-
ing the musical data. The Abstract Representation has been designed and imple-
mented in C++ using object-oriented design patterns, therefore the data structure
and operations on the data are both part of the class library.
Once the G UIDO description has been converted into the one-to-one corresponding
instance of the Abstract Representation, a number of music notation algorithms
are executed. These music notation algorithms enhance a given G UIDO description
by analyzing the input and applying common musical typesetting rules. All im-

137
138 CHAPTER 6. CONCLUSION

plemented music notation algorithms are G UIDO to G UIDO transformations: they

take a G UIDO description as their input and return an enhanced G UIDO descrip-
tion. Most of the music notation algorithms add formatting information which is
automatically computed from the input using commonly accepted musical typeset-
ting rules. As music typesetting rules are sometimes discussed contradictory in
different publications, all algorithms can be exchanged quite easily.

Once the music notation algorithms have been performed on the Abstract Represen-
tation, the contained data is used to create an instance of the so called Graphical
Representation, which is closely related to a graphical score. The conversion into
the Graphical Representation requires the creation of graphical notational elements
visible in the score. Additionally, those notational elements have to be identified
that require an equal horizontally position, because they have the same onset time.
A suitable way to deal with the issue is the usage of the spring-rod-model, which
uses springs and rods to describe the layout of a line of music. Once the elements
have been associated with springs, a line of music can be stretched to a desired ex-
tent by applying a “force” on the virtual springs. To prevent horizontal collisions,
rods are used to pre-stretch the springs. The spring-rod-model has been first used
for spacing lines of music in 1987 and produces quite good results, which closely
match scores from human engravers. The issue of calculating spring constants for
this model is not easy, and it was shown in this thesis, that it can be improved,
especially if rhythmically complex interactions of voices are concerned.

After the Graphical Representation has been created from the Abstract Represen-
tation, another set of music notation algorithms needs to identify optimal line- and
page-break positions. These depend on the spacing of individual lines and also on
the degree of page-fill of the last page (in music, the last page of a score should be
completely full). An optimal line-breaking algorithm for music based on the line
breaking algorithm for TEX has been previously published by [HG87], but there has
been no publication on optimally filling pages of a score. In this thesis a new optimal
page fill algorithm was designed and implemented. The new algorithm is an exten-
sion of the optimal line breaking algorithm; it makes use of dynamic programming
and is scalable so it can be adapted for different requirements.

The developed music notation system is used within a couple of applications, which
were also implemented during the work on this thesis. The stand-alone G UIDO
NoteViewer can be used to create graphical scores from G UIDO descriptions, which
can also be printed. The online G UIDO NoteServer is a client-server application
on the Internet that converts a G UIDO description into a picture of a score. This
free service can be accessed using any standard web browser. Because G UIDO is an
intuitive and powerful music representation language, it is used by a continuously
growing number of people and research groups. The developed G UIDO based music
notation tools are also being used and accepted widely by users around the world.
 139

Outlook
A music notation system is never complete in the sense that every single notation
feature required in any conceivable score is already implemented. As music notation
is continuously evolving to represent new musical ideas, there will probably never
be a single system that covers all needs.
Many features of conventional music notation have not been implemented in the
presented music notation system. Some of these features can be implemented rather
easily by merely using diligence (for example the addition of different note shapes).
Others are quite complicated and require a lot of additional research: these include
automatic collision detection and prevention. The framework of the implemented
music notation provides a solid ground for further research. Additionally, the un-
derlying music representation language G UIDO is a powerful notation interchange
format. Therefore, any enhancement to the implemented music notation algorithms
can be directly coded into a G UIDO description, which can then be read by any
G UIDO compliant music notation software.
Another interesting topic for further research is the enhancement of the prototypi-
cal Java based music notation editor, which uses the G UIDO Graphic Stream proto-
col. Because Java is platform independent, this could provide the basis for a truly
interchangeable music notation system. Nevertheless, a lot of additional work is
necessary to create a fully functional music notation editor.
140 CHAPTER 6. CONCLUSION
Bibliography

[ARW98] V. Abel, P. Reiss, and R. Wille. Mutabor ii - ein computergesteuertes

musikinstrument zum experimentieren mit stimmungslokigen und
mikrotönen. Technical Report 34, Universität Mainz, Musikinfor-
matik und Medientechnik, 1998.

[Bel57] Richard Bellman. Dynamic Programming. Princeton University

Press, Princeton, New Jersey, 1957.

[Bel01] Alan Belkin. NIFF Homepage at http://www.musique.umontreal.ca/

personnel/Belkin/NIFF.doc.html, 2001.

[BH91] Dorothea Blostein and Lippold Haken. Justification of printed music.

Communications of the ACM, 34(3):88–99, March 1991.

[Blu89a] Friedrich Blume, editor. Musik in Geschichte und Gegenwart,

volume 9, chapter Notensatz (music notation), pages 1595–1667.
Deutscher Taschenbuch Verlag, Bärenreiter Verlag, Kassel, Basel,
London, 1956,1989.

[Blu89b] Friedrich Blume, editor. Musik in Geschichte und Gegenwart, vol-

ume 5, chapter Guido von Arezzo, pages 1071–1078. Deutscher
Taschenbuch Verlag, Bärenreiter Verlag, Kassel, Basel, London,
1956,1989.

[Blu89c] Friedrich Blume, editor. Musik in Geschichte und Gegenwart, vol-

ume 9, chapter Notendruck (music printing), pages 1667–1695.
Deutscher Taschenbuch Verlag, Bärenreiter Verlag, Kassel, Basel,
London, 1956,1989.

[Boo91] Grady Booch. Object Oriented Design with Applications. The Ben-
jamin/Cummings Publishing Company, Inc., 1991.

[BSN01] P. Bellini, R. Della Santa, and P. Nesi. Automatic formatting of music

sheets. In Proceedings of the First International Conference on WEB
Delivering of Music – WEDELMUSIC, pages 170 – 177, 2001.

141
142 BIBLIOGRAPHY

[Byr84] Don Byrd. Music Notation by Computer. PhD thesis, Department of

Computer Science, Indiana University, 1984.
[cgi02] CGI: Common Gateway Interface. http://www.w3.org/CGI/, 2002.
[CGR01] Gerd Castan, Michael Good, and Perry Roland. Extensible Markup
Language (XML) for Music Applications: An Introduction. In Wal-
ter B. Hewlett and Eleanor Selfridge-Field, editors, The Virtual Score,
number 12 in Computing in Musicology, chapter 6. The MIT Press
and CCARH, 2001.
[Eck00] Robert Eckstein. XML – kurz & gut. O’ Reilly, 2000.
[eng98] Webpage on Hand-Enraving. http://www.henle.de/englisch/info/
notenstich.htm, G. Henle Verlag, 1998.
[Fla98] David Flanagan. JavaScript: The Definitive Guido, Third Edition.
O’ Reilly & Associates, Cambridge, 1998.
[Fri00] Martin Friedmann. GUIDO to MIDI Converter. Computer Science
Department, Darmstadt University of Technology, 2000.
[Fri01] Martin Friedmann. MuseData to GUIDO Converter. Computer Sci-
ence Department, Darmstadt University of Technology, 2001.
[FS00] Martin Fowler and Kendall Scott. UML konzentriert. Eine strukturi-
erte Einführung in die Standard-Objektmodellierungssprache. 2., ak-
tualisierte Auflage. Addison-Wesley, 2000.
[GHJV94] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Design Patterns: Elements of Reusable Object-Oriented Software.
Addison-Wesley Publishing Company, 1994.
[Gie01] Martin Gieseking. Code-basierte Generierung interaktiver Noten-
graphik. PhD thesis, Universität Osnabrück, 2001.
[GNU] The GNU Project Webpage: http://www.gnu.org.
[Gou87] John S. Gourlay. Spacing a Line of Music. Technical report, Ohio
State, 1987.
[Gra97] Cindy Grande. The Notation Interchange File Format: A Windows-
Compliant Approach. In Eleanor Selfridge-Field, editor, Beyond MIDI
– The Handbook of Musical Codes, chapter 31, pages 491–512. The
MIT Press, 1997.
[Had48] Karl Hader. Aus der Werkstatt eines Notenstechers. Waldheim-Eberle-
Verlag, Wien, 1948.
BIBLIOGRAPHY 143

[Ham98] Keith Hamel. NOTEABILITY - A COMPREHENSIVE MUSIC NO-

TATION EDITOR. In Proceedings of the 1998 International Com-
puter Music Conference, pages 506–509, University of Michigan, Ann
Arbor, Michigan, USA, 1998. International Computer Music Associa-
tion.
[HB95] Lippold Haken and Dorothea Blostein. A New Algorithm for Hori-
zontal Spacing of Printed Music. In Proceedings of the 1995 Interna-
tional Computer Music Conference, pages 118–119, Banff Centre for
the Arts, Banff, Canada, 1995. International Computer Music Asso-
ciation.
[Hew97] Walter B. Hewlett. MuseData: Multipurpose Representation. In
Eleanor Selfridge-Field, editor, Beyond MIDI – The Handbook of Mu-
sical Codes, pages 402–450. The MIT Press, 1997.
[HG87] Wael A. Hegazy and John S. Gourlay. Optimal line breaking in music.
Technical Report OSU-CISRC-8/87-TR33, The Ohio State University,
1987.
[HH96] Holger H. Hoos and Keith Hamel. Basic GUIDO Specification. Tech-
nical report, Darmstadt University of Technology, 1996.
[HHR99] Holger H. Hoos, Keith A. Hamel, and Kai Renz. Using Advanced
GUIDO as a Notation Interchange Format. In Proceedings of the 1999
International Computer Music Conference, pages 395–398, Tsinghua
University, Beijing, China, 1999. International Computer Music As-
sociation.
[HHRK98] Holger H. Hoos, Keith A. Hamel, Kai Renz, and Jürgen Kilian. The
GUIDO Notation Format – A Novel Approach for Adequatley Repre-
senting Score-Level Music. In Proceedings of the 1998 International
Computer Music Conference, pages 451–454, University of Michigan,
Ann Arbor, Michigan, USA, 1998. International Computer Music As-
sociation.
[HHRK01] Holger H. Hoos, Keith Hamel, Kai Renz, and Jürgen Kilian. Rep-
resenting Score-Level Music Using the GUIDO Music-Notation For-
mat. In Walter B. Hewlett and Eleanor Selfridge-Field, editors, The
Virtual Score, volume 12 of Computing in Musicology, chapter 5. The
Center for Computer Assisted Research in the Humanities and the
MIT Press, 2001.
[HKRH98] Holger H. Hoos, Jürgen Kilian, Kai Renz, and Thomas Helbich.
SALIERI – A General, Interactive Computer Music System. In Pro-
ceedings of the 1998 International Computer Music Conference, pages
144 BIBLIOGRAPHY

385–392, University of Michigan, Ann Arbor, Michigan, USA, 1998.

International Computer Music Association.

[Hoo] Holger H. Hoos. The GUIDO Parser Kit. http://www.salieri.org/guido.

[How97] John Howard. Plaine and Easie Code: A Code for Music Bibliography.
In Eleanor Selfridge-Field, editor, Beyond MIDI – The Handbook of
Musical Codes, pages 362–372. The MIT Press, 1997.

[HR78] David Halliday and Robert Resnick. Physics. John Wiley & Sons,
1978.

[HRG01] Holger H. Hoos, Kai Renz, and Marko Görg. GUIDO/MIR – An Ex-
perimental Musical Information Retrieval System Based on GUIDO
Music Notation. In Proceedings of the 2nd Annual International Sym-
posium on Music Information Retrieval (ISMIR), pages 41–50, 2001.

[Hub99] Matthias Huber. Entwurf eines objektorientierten Frameworks für

die abstrakte Repräsentation und Visualisierung der konventionellen
Musiknotation. Studienarbeit (Termpaper), Darmstadt University of
Technology, 1999.

[Hur97] David Huron. Humdrum and Kern: Selective Feature Encoding. In

Eleanor Selfridge-Field, editor, Beyond MIDI – The Handbook of Mu-
sical Codes, chapter 26, pages 375–401. The MIT Press, 1997.

[HwDCF+ 97] Walter B. Hewlett, Eleanor Selfridge-Field with David Cooper,

Brent A. Field, Kia-Chuan Ng, and Peer Sitter. MIDI. In Eleanor
Selfridge-Field, editor, Beyond MIDI – The Handbook of Musical
Codes, chapter 2, pages 41–72. The MIT Press, 1997.

[HYT95] Hypermedia/Time-Based Structuring Language (HyTime), ISO docu-

ment 10744, 1995.

[Kil99] Jürgen Kilian. MIDI2GMN – Converting MIDI to GUIDO Music No-

tation. Technical report, TU Darmstadt, 1999.

[Kil02] Jürgen Kilian. Converting MIDI to GUIDO. PhD thesis, Darmstadt

University of Technology, 2002. to be published.

[Knu98] Donald E. Knuth. Digital Typography, chapter Breaking Paragraphs

Into Lines, pages 67–155. Center for the Study of Language and In-
formation, Leland Stanford Junior University, 1998.

[MNN99] Adrian Mariano, Han-Wen Nienjuys, and Jan Nieuwnhuizen. Mudela

1.0.7 / LilyPond 1.1.8 Reference Manual, January 1999.
BIBLIOGRAPHY 145

[msd02] Articles on the document view model. http://msdn.microsoft.com,

2002.

[NN01] Han-Wen Nienjuys and Jan Nieuwenhuizen. GNU LilyPond – The

music typesetter, March 2001. The newest tutorial and reference man-
ual available at http://www.lilypond.org and downloaded at January,
21st, 2002.

[Pre00] Bruno R. Preiss. Data Structures and Algorithms with Object-

Oriented Design Patterns in Java. John Wiley & Sons, 2000.

[Rea79] Gardner Read. Music Notation – A Manual of Modern Practice. Ta-

plinger Publishing Company, New York, 1979.

[Ren00] Kai Renz. Design and Implementation of a Platform Independent

GUIDO Notation Engine. In Proceedings of the 2000 International
Computer Music Conference, pages 469–472, Berlin, Germany, 2000.
Berliner Kulturveranstaltungs GmbH, International Computer Mu-
sic Association.

[Ren02] Kai Renz. An Improved Algorithm for Spacing a Line of Music. In

Proceedings of the ICMC 2002, 2002.

[RH98] Kai Renz and Holger H. Hoos. A WEB-based Approach to Music No-
tation using GUIDO. In Proceedings of the 1998 International Com-
puter Music Conference, pages 455–458, University of Michigan, Ann
Arbor, Michigan, USA, 1998. International Computer Music Associa-
tion.

[RH01] Kai Renz and Holger H. Hoos. WEB delivery of Music using the Guido
NoteServer. In Proceedings of the First International Conference on
WEB Delivering of Music – WEDELMUSIC, page 193. IEEE Com-
puter Society, 2001.

[Rob98] Robert Robson. Using STL. Springer, 1998.

[Ros87] Ted Ross. Teach Yourself the Art of Music Engraving & Processing.
Hansen House, Miami Beach, Florida, 1987.

[Sch97] Bill Schottstaedt. Common Music Notation. In Eleanor Selfridge-

Field, editor, Beyond MIDI – The Handbook of Musical Codes, chap-
ter 16, pages 217–221. The MIT Press, 1997.

[Sch98] Bill Schottstaedt. Common Music Notation, website. http://ccrma-

www.stanford.edu/CCRMA/Software/cmn, 1998.
146 BIBLIOGRAPHY

[SF97a] Eleanor Selfridge-Field, editor. Beyond MIDI – The Handbook of Mu-

sical Codes. The MIT Press, Cambridge, Massachusetts, London,
England, 1997.

[SF97b] Eleanor Selfridge-Field. DARMS, Its Dialects, and Its Uses. In

Eleanor Selfridge-Field, editor, Beyond MIDI – The Handbook of Mu-
sical Codes, chapter 11, pages 163–174. The MIT Press, 1997.

[SGM86] Standard Generalized Markup Language, ISO document 8879, 1986.

[SMD95] Standard Music Description Language (SMDL), Draft, ISO document

10743, 1995.

[Smi97] Leland Smith. SCORE. In Eleanor Selfridge-Field, editor, Beyond

MIDI – The Handbook of Musical Codes, pages 252–282. The MIT
Press, 1997.

[SN97] Donald Sloan and Steven R. Newcomb. HyTime and Standard Mu-
sic Description Language: A Document-Description Approach. In
Eleanor Selfridge-Field, editor, Beyond MIDI – The Handbook of Mu-
sical Codes, chapter 30, pages 469–490. The MIT Press, 1997.

[Str91] Bjarne Stroustrup. The C++ Programming Language. Addison-

Wesley Publishing Company, 1991.

[TME99] Daniel Taupin, Ross Mitchell, and Andreas Egler. MusiXTEX– Using
TEX to write polyphonic or instrumental music, version t.93 edition,
April 1999.

[vI70] Otto von Irmer, editor. J. S. BACH – Das Wohltemperierte Klavier,

volume 1. G. Henle Verlag, München, 1970.

[Vin88] Albert C. Vinci. Die Notenschrift – Grundlagen der traditionallen

Musiknotation. Bärenreiter-Verlag, Kassel, 1988.

[W3C02] HyperText Markup Language Home Page. World Wide Web consor-
tium; http://www.w3c.org/Markup, 2002.

[Wan88] Helene Wanske. Musiknotation – Von der Syntax des Notenstichs zum
EDV-gesteuerten Notensatz. B. Schott’s Söhne, Mainz, 1988.

[WCS97] Larry Wall, Tom Christiansen, and Randal L. Schwartz. Program-

mieren mit Perl. O’ Reilly, 1997.
Complete Advanced G UIDO
Description for Bach Sinfonia 3

The following is the complete Advanced G UIDO description of one page of Bach’s
Sinfonia 3 (BWV 789). The score page is shown in Figure 1 on page 148.
% The first page of a BACH Sinfonia, BWV 789
% Most of the element-positions are specified
% using Advanced GUIDO tags. The layout has
% been very closely copied from the URTEXT
% edition by the Henle-Verlag.
% This example has been prepared to show, that
% Advanced GUIDO is capable of exact score-
% formatting.
%

{ [ % general stuff
\pageFormat<"a4",lm=0.8cm,tm=4.75cm,bm=0.1cm,rm=1.1cm>
\title<"SINFONIA 3",pageformat="42",textformat="lc",dx=-2cm,dy=0.5cm>
\composer<"BWV 789",dy=1.35cm,fsize=10pt>

% indent of 1.05 cm for the first system.

\systemFormat<dx=1.05cm>

% voice 1

\staff<1,dy=0.85cm> % next staff is 0.85 cm below

\staffFormat<style="5-line",size=0.9375mm>
% barlines go through whole system
\barFormat<style="system">
% measure 1 (voice 1)
\clef<"treble"> \key<"D"> \meter<"C"> \stemsUp
\restFormat<posy=-1hs> _/8
\beam( \fingering<text="3",
dy=8hs,dx=-0.1hs,fsize=7pt>(f#2/16) g)
\beam( \stemsUp<5hs> a/8
\fingering<text="2",dx=1hs,dy=11.5hs,fsize=7pt>( \stemsUp<8hs> c )
)
\beam( \stemsUp h1 e2/16 f#)
\beam( \stemsUp<5hs> g/8 \stemsUp<8.5hs> h1 \stemsUp)
\bar
% measure 2 (voice 1)
\beam( a1/8 d2/16 e) \beam( f#/8 a1)
\beam( \stemsUp<12hs> g/16
\stemsUp \fingering<text="4",fsize=7pt,dy=9hs,dx=-0.2hs>(f#2) e
\stemsUp<8hs> d \stemsUp)
\beam( \stemsUp<12hs> c# \stemsUp
\fingering<text="5",fsize=7pt,dy=9hs>(h) a
\stemsUp<8hs> g \stemsUp ) \bar
% measure 3 (voice 1)

147
148 APPENDIX . BACH SINFONIA 3

SINFONIA 3
BWV 789

—— ———— —
# # c a X——Û X——Û _—XÛ n X———Û X————Û X———Û X——Û X——Û X———Û ——— ———XÛ X———Û X——Û ———— ———— X——Û X———Û X———Û X————Û _X—Û _X—Û X——Û X—Û— X——Û X——Û ——XÛ X——Û X———Û X——Û # X——Û _X—Û XÚ– XÚ– X—Ú–Û–
5
4 1 3
3 2 2
5

=‹ X—Û======= X—Û X—Û a –– –– – nXÚ–– ‹

2

&
========= =‹ ========

« _ XÚ–– ‹ X Ú ‹ XÚ–– _XÚ–– XÚ– XÚ– # XÚ XÚ– XÚ– _XÚ–– _XÚ–– _XÚ–– XÚ– ‹‹
_
‹ – X
Ú ‹
2

# – a X–Ú–– –– X
Ú a XÚ–– ‹‹ X–Ú–– a XÚ–– –– –– ––– X
Ú – ‹ XÚ ––– ––– –– –– –– –– –– – –– – – ‹‹
? #c
========= J 3
–J======== –J 2
–– XÚ––– =‹ ––– ======== 1 3 1

——— X——Û ——— ——— —— X–Ú # XX—ÛÚ _E—Û

5

# # X—Û ——Ú–Û ——Û

3 2

—
1 5

X X Û XÚ–– XXÛÚ–– XXÛÚ– # XX—ÛÚ– ––– ––– XÚ––– XÚ–– XÚ–– XÚ– XÚ–– XÚ–– XÚ– XÚ–– XÚ––
45

X
Ú X
Û
Ú X
45

XÚ– XÚ–– –– –– XÚ– XÚ–– XÚ–– XÚ––– ––– XÚ– =

1 1 2 1 3

&
============== ‹ XÚ– =========== =‹
‹ – –– –– – – – – – – – – – – – – – ‹
« # # # XÚ––– XÚ–– # XÚ––– XÚ––– XÚ––– _XÚ––– XÚ––– n XÚ–– XÚ––– XÚ–– XÚ–– XÚ––– XÚ––– XÚ–––– XÚ––– n XÚ––– ‹‹ XÚ–– XÚ– X——Û —— ——— ——— X———Û X——Û XÚ–– XÚ–– n XÚ––– XÚ–– ‹‹
2

?
============== 1 1
– – – – = ‹ – ===========
4
– 1 _X——Û X—Û XÛ
2 3
3
– – – = – ‹
—
# # _XX—ÛÚ– ————XÛ X———Û X——Û X——Û X——Û X——Û X———Û # X——Û ——— X———Û X——Û X———Û X——Û ———XÛ n X———Û X——Û —— —— X——Û X——Û X——Û X——Û X———Û ——
2 5

—Û XÚ
1 3 4 5 4

X
4 3

– XÚ XÚ––
X
Û — X
Û XÚ–– XÚ––– XÚ––– XÚ–– XÚ– –––– –––– =
X Û
5

& ––
============== XÚ–– XÚ–– XÚ–– = XÛ
‹ XÚ––– =========== XÚ––
– – – –– ‹‹
«
– – – ‹ – –
‹ — —— —— ——— —— —— —— —— —— XÚ– XÚ– XÚ ‹
12

# # XÚ–– XÚ–– XÚ–– XÚ––– XÚ––– n XÚ– XÚ XÚ–– XÚ–– XÚ––– XÚ ‹ —— X—Û XÛ XÛ —— —— XÛ XÛ X—Û XÚ– ––– –– ––– ‹
? – – – –– –– ––– –– –– –– ––– =
============== ‹ XÛ=========== XÛ X—Û –– –– –– = – ‹

# # X—Û —— X——Û . ——— —— —— — —— — —— —— ——— —— ——— X ——Û —— — — — —— — ——— ———

X Û — — X
Û X
Û . XÚ–– XÛ X——Û X——Û X——Û XÛ X——Û XÛ XÛ
3

X Ú
– X
Ú —
X
Û Ú
X X
Ú
– # X
Ú X
Ú
– X Ú
– — — —
XÛ XÛ X—Û XÛ XÛ XÛ XÛ— — — — # X
Û —
X
Û
X
Ú X
Ú
– X
Ú
– X
Ú
– X
Ú
–
& –– ––– XÚ––– ––– –– –– –– – EÚ––
============== – = ‹ XÚ–– =========== – – – – XÚ– – – =‹
‹ – –– – – – – ––
«
– —
— ‹
# # X–Ú– XÚ–– XÚ– XÚ–– X–Ú– XÚ–– X–Ú– # XÚ––– XÚ––– XÚ–– XÚ––– . X
Ú ‹
––– ‹ n XÚ–– X–Ú XÚ– X–Ú XÚ–– X–Ú XÚ–– XÚ–– ––– XÚ–– XÚ–– XÚ X
Û ‹
– – – – – – – – – – ‹
? – – –– – – – – – –
============== = ‹ =========== – – – – =‹
# # XÚ–– XÚ–– XÚ– XÚ–– XÚ–– X Ú
– X Ú
– X Ú
–
– ——— X———Û X———Û X——Û ———— ———— X——Û X———Û X———Û XÚ––– XÚ–– XÚ––
& –
============== – –
– – – –– n XÚ–– # XÚ–– ––– –– ––– n XÚ–– = – ‹ X—Û=========== X—Û X—Û # XÚ–– –– –– =
–– ‹

«
– – – ‹ ‹
——— ——— ——— _——XÛ _X———Û _
—X—Û ——— ——— —— — —— —— ——— ——— ——— —— ‹ — —
_ _XÛ _XÛ X—Û # X———Û # X—Û X—Û _XÛ _XÛ _XÛ X—Û ‹ # X—Û ——— # X———Û X——Û X——Û — — — —
— —
— —
——Û X——Û _X—Û _X—Û __XÛ X——Û ‹‹
—
X Û # X
Û X Û X
# EÚ–
? # ––
==============
XÚ––
– XÚ––
– =
‹ XÚ–– XÛ
‹ – =========== @ XÚ––– XÚ––– XÚ––– n X–Ú–– XÚ––
– =‹
‹

# # XÚ– XÚ– XÚ XÚ– XÚ– XÚ XÚ– XÚ– —— —— —— —— X———Û X

——— ——— —— —— ——
Û ——Û ——— ——— —— ———
– – – – – – – – — # —
X
Û —
X
Û X
Û # X
Ú — # —
X
Û —
X
Û X Û X XÛ
& – –
– –– – – –– – – # XÛ
============== – — ––– XÚ–– n XÚ–– = XÛ—
‹ # XÚ–– =========== XÚ–– XÚ––– XÚ––– n XÚ–– _XÚ–– # X—Û X—Û XÛ _XÚ–– n XÚ––– n XÚ–– =
_XÚ–– ‹‹

« ——— —— —— — —— ——— – – ‹ – – – – – – – – – ‹
X Û n —
X
Û # —
X
Û — X—
Û X Û ‹ X Ú
– # X Ú
# XÛ XÚ ‹ – – XÚ– # XÚ XÚ XÚ– XÚ–– ‹‹
? # EÚ–––
============== ––– XÚ–– ‹ XÚ–– ===========
= XÚ–– –––– –––– ––– ––– XÚ–– # X–Ú–– ––– ––– XÚ––– = –
– – –

Figure 1: First page of Bach’s Sinfonia 3 (BWV 789)

 149

\beam( \stemsUp<5.5hs> f#2/16 \stemsUp e

\fingering<text="2",fsize=7pt,dy=10hs>( d ) \stemsUp<5.5hs> e
\stemsUp)
\beam( \stemsUp<6hs> f# \stemsUp
\fingering<text="1",fsize=7pt,dy=11hs>(e)
\fingering<text="3",fsize=7pt,dy=11hs>(f#)
\stemsUp<6.5hs> g# \stemsUp)
\stemsUp<4.75hs> a/4 \stemsUp
\slurBegin<dx1=2hs,dy1=3hs,dx2=0hs,dy2=2hs,h=2hs>
\fingering<text="5",fsize=7pt,dy=6hs>( \stemsUp<4.5hs> e/4 )
\bar \newSystem<dy=4cm>
% measure 4 (voice 1)
\staff<1,dy=0.98cm>
e/4 \slurEnd
\tie<dy1=2.4hs,dx2=-1hs,dy2=2.4hs,h=1.75hs>(
\fingering<text="4 5",dy=8hs,fsize=7pt>( \stemsUp<5hs> d) d )
\tieBegin<dy1=2hs,dy2=2hs,dx2=0hs>
\fingering<text="4 5",dy=8hs,fsize=7pt>(c#)
%measure 5 (voice 1)
\bm( \stemsUp<8hs> c#/16 \stemsUp
\tieEnd \fingering<text="5",dy=11hs,fsize=7pt>(e) d
\stemsUp<7.5hs> c# \stemsUp )
\bm( \fingering<text="2",dy=12.5hs,fsize=7pt>(
\stemsUp<8hs> h1/8 ) \acc( \stemsUp<5hs> g#2 \stemsUp))
\slurBegin<dy2=2hs,dx2=0hs>
\fingering<text="5",dy=5hs,fsize=7pt>( \stemsUp<4hs> a/2)
\newSystem<dy=4.15cm>
% measure 6 (voice 1)
\staff<1,dy=1.08cm>
\bm( \stemsUp<5.5hs> a/16 \stemsUp
\slurEnd \fingering<text="2",dy=13hs,fsize=7pt>( c# )
\fingering<text="1",dy=11.25hs,fsize=7pt>(d)
\stemsUp<6hs> \fingering<text="3",dy=9.5hs,fsize=7pt>(e)
\stemsUp)
\bm( \stemsUp<7hs> f# \stemsUp g f# \stemsUp<7.5hs>
\fingering<text="5",dy=11hs,fsize=7pt>(e) \stemsUp )
\bm( \stemsUp<6hs> d# \stemsUp h1 c#2 \stemsUp<6hs> d# \stemsUp )
\bm( \stemsUp<7hs> e \stemsUp \fingering<text="4",dy=9hs,fsize=7pt>(f#)
\fingering<text="5",dy=9.5hs,fsize=7pt>(e)
\stemsUp<7.5hs> d \stemsUp )
% measure 7 (voice 1)
\bm( \stemsUp<6hs> c# \stemsUp a1
\fingering<text="4",dy=10hs,fsize=7pt>(h)
\stemsUp<6hs> \fingering<text="3",dy=9.25hs,fsize=7pt>(c#2)
\stemsUp)
\bm( \stemsUp<7hs>
\fingering<text="4",fsize=7pt,dy=9.25hs>(d)
\stemsUp e d \stemsUp<7hs> c# \stemsUp )
\stemsUp<5.5hs> \fingering<text="5",fsize=7pt,dy=8hs>(h1/4)
\tieBegin<dy1=2.5hs,dx2=0,dy2=1.5hs,h=1.25hs>
\stemsUp<4.5hs> e2
\newSystem<dy=4.25cm>
% measure 8 (voice 1)
\staff<1,dy=1.02cm>
\bm( e/8 \tieEnd \stemsUp<6.5hs>
\fingering<text="3",fsize=7pt,dy=12hs>(a1) \stemsUp)
\dotFormat<dy=1hs>
\bm( d2/8. e/16)
\bm(c# h1 a h )
\bm( c#2 h1 c#2 d# )
% measure 9 (voice 1)
\bm( e/8 h1)
\dotFormat<dy=0>
\bm(e2/8. f#/16)
\bm(d c# h1 c#2)
150 APPENDIX . BACH SINFONIA 3

\bm(d c# d e)
\newSystem<dy=3.9cm>
% measure 10 (voice 1)
\staff<1,dy=1.48cm>
\bm( \stemsDown f# e d e)
\bm(f#/8 \acc(a1))
\bm(g# c#2/16 d)
\bm(e/8 \acc(g1))
% measure 11 (voice 1)
\bm( \stemsUp f# h/16 c#2)
\bm(d/8 f#1)
\bm( \stemsUp<13hs> e/16 \stemsUp d2 c#
\stemsUp<9hs> h1 \stemsUp )
\bm( \stemsDown<5.5hs> a# \stemsDown g2 f#
\stemsDown<8.5hs> e \stemsDown)
\newSystem<dy=4.45cm>
% measure 12 (voice 1)
\staff<1,dy=1.09cm>
\bm(d/16 c# h1 c#2 )
\bm(d h1 c#2 d)
\bm( \stemsUp<9.5hs> e#1 \stemsUp g# a
\stemsUp<6hs> h \stemsUp )
\tieBegin<dy1=3.2hs,dx2=0,dy2=3.2hs> c#2/4
% measure 13 (voice 1)
\bm(c#/16 \tieEnd f#1 g# a)
\tieBegin<curve="up"> h/4
\bm( h/16 \tieEnd e# f# g#)
\tieBegin<dx1=2hs,dy1=2.8hs,dx2=0hs,dy2=-2.1hs,h=1.1hs>
a/4
\newPage
% Here, the new page begins ....
% measure 14 (voice 1)
a/16 \tieEnd
% .....
] ,
[ % voice 2
\staff<1>
% measure 1 (voice 2)
\restFormat<posy=-8hs,dx=2.5cm> _/1
% measure 2 (voice 2)
_/1
% measure 3 (voice 2)
\restFormat<posy=-2hs> _/2 \restFormat<posy=-5hs> _/8
\stemsDown \beam( \fingering<text="2",fsize=7pt,dy=6hs>(c#2/16)
\stemsDown<7.5hs> d \stemsDown )
\beam( \stemsDown<8hs> e/8 \stemsDown
\stemsDown<5hs> \acc<dx=0.02cm>(
\fingering<"2",fsize=7pt,dy=-3hs,dx=0.8hs>( g1 ) )
\stemsDown )
% measure 4 (voice 2)
\bm( \stemsDown<4.5hs> f#1/8 \stemsDown
\fingering<text="2",fsize=7pt,dy=-6.5hs>(h/16)
\stemsDown<6hs> c#2 \stemsDown)
\bm( \stemsDown<7hs> d/8 \stemsDown<4.25hs> f#1 \stemsDown )
\bm( \stemsDown<5hs> e \stemsDown a/16 \stemsDown<7hs> h \stemsDown)
\bm( \stemsDown<7hs> c#2/8 \stemsDown<4.5hs> e1 \stemsDown )
% measure 5 (voice 2)
\bm( \stemsDown<5hs> d/16 \stemsDown
\fingering<text="3",fsize=7pt,dy=11hs>(c#2) h1
\stemsDown<7hs> a \stemsDown )
\bm( \stemsDown<6hs>
\fingering<text="1",fsize=7pt,dy=12.25hs>( g# )
\stemsDown f#2 e \stemsDown<8.5hs>
\fingering<text="1",dy=5hs,fsize=7pt>(d)
\stemsDown)
 151

\bm( \stemsDown<8hs> c# \stemsDown

\fingering<text="1",fsize=7pt,dy=7hs>(h1)
\fingering<text="2",fsize=7pt,dy=8hs>( a )
\fingering<text="1",fsize=7pt,dy=7hs>(
\stemsDown<7.5hs> h \stemsDown) )
\bm( \stemsDown<9hs> \fingering<text="3",dy=6hs,fsize=7pt>( c#2 )
\stemsDown a1 h \stemsDown<8.75hs> c#2 \stemsDown )
% measure 6 (voice 2)
d2/4 \tieBegin<dx1=0,dy1=-3.25hs,dx2=-2hs,dy2=-3.25hs,h=-1hs> a1
\fingering<text="1 2",fsize=7pt,dx=1.3cm,dy=-4hs>(a) \tieEnd
\tieBegin<dx1=0,dy1=-2.25hs,dx2=-2hs,dy2=-2.25hs,h=-1hs> g
% measure 7 (voice 2)
g \tieEnd \tieBegin<dx1=-0.5hs,dy1=-2hs,dx2=-2hs,dy2=-2hs,h=-1hs> f#
\bm( f#/16 \tieEnd a g f# )
\bm( e d2 c# h1 )
% measure 8 (voice 2)
\bm( a1/16 g f# g)
\bm( a g# a h )
\tieBegin<dx1=0.25hs,dy1=-1.5hs,dx2=-2hs,dy2=-1.5hs,h=-2hs> e1/2
% measure 9 (voice 2)
\bm( e/8 \tieEnd g/16 a)
\bm( h a h c#2)
f#1/4 \staff<2>
\tieBegin<dx1=2hs,dy1=3hs,dx2=0hs,dy2=4hs,h=1.2hs>
\stemsUp h0
\bar
% measure 10 (voice 2)
\bm( h/16 \tieEnd a# h c#1)
\bm(d e d c#)
\bm(h0 g# \acc(a#) h)
\bm(c#1 d c# h0)
% measure 11 (voice 2)
\bm( a# f# g# a#)
\tieBegin<curve="up"> h/4
\bm(h/16 \tieEnd h c#1 d)
\bm(e/8 a#0)
% measure 12 (voice 2)
\bm( h \acc(a) )
\bm(g# f#)
\tieBegin g#/4
\bm(g#/16 \tieEnd \staff<1> \stemsDown
\acc(g#1/16) f# \acc(e) )
% measure 13 (voice 2)
\tieBegin<dx1=0.5hs,dy1=-1.9hs,dx2=-2hs,dy2=-1.9hs,h=-1hs> d#/4
\bm(d#/16 \tieEnd f# e d)
\tieBegin<dx1=0hs,dy1=-1.9hs,dx2=-2hs,dy2=-1.9hs,h=-1hs> c#/4
\bm(c#/16 \tieEnd \acc(e) \acc(d) c#)
],
[ % voice 3
\staff<2>
\staffFormat<"5-line",size=0.9375mm>
% measure 1 (voice 3)
\clef<"bass"> \key<"D"> \meter<"C">
d1/4 \restFormat<posy=-3hs> _/8 \stemsDown
\fingering<text="3",dy=-7hs,fsize=7pt>( f#0 ) g/4 _/8 e
% measure 2 (voice 3)
f#/4 _/8 d \beam( h \fingering<text="2",fsize=7pt,dy=-8hs>(g))
\beam(a a-1)
% measure 3 (voice 3)
\bm( \stemsDown<7hs>d0 \stemsDown d1 c#
\fingering<text="1",fsize=7pt,dy=-10hs>(
\stemsDown<9hs> h0 \stemsDown ) )
\beam( \stemsDown<8.25hs> a/16 \stemsDown g# a
\stemsDown<9.25hs> h \stemsDown )
\bm( \fingering<text="3",fsize=7pt,dy=-10hs>(
152 APPENDIX . BACH SINFONIA 3

\stemsDown<8hs> c#1 \stemsDown )

d c#
\fingering<text="1",fsize=7pt,dy=-9hs>(
\stemsDown<7hs> h0 \stemsDown ))
% measure 4 (voice 3)
\bm( \stemsDown<8.25hs> a# \stemsDown f# g#
\stemsDown<8.25hs> a# \stemsDown)
\bm( \stemsDown<7hs> \fingering<text="1",fsize=7pt,dy=-9hs>( h )
\stemsDown c#1 \fingering<text="1",fsize=7pt,dy=-9hs>( h0 )
\stemsDown<6.25hs> \acc(a) \stemsDown )
\bm( \stemsDown<9hs> g# \stemsDown e f#
\stemsDown<9hs> g# \stemsDown )
\bm( \stemsDown<8hs> a \stemsDown h a
\stemsDown<7.25hs> g \stemsDown )
% measure 5 (voice 3)
\bm( \stemsDown<7hs>
\fingering<text="4",fsize=7pt,dy=-7hs>(f#/8 )
\stemsDown<6.25hs> d \stemsDown)
\bm( \stemsUp<6hs>
\fingering<text="1",fsize=7pt,dy=-5hs>(e)
\stemsUp<11hs> e-1)
\bm( \stemsUp<8.75hs>
\fingering<text="2",fsize=7pt,dy=-1hs>(a/16) \stemsUp h
\fingering<text="3",fsize=7pt,dy=-3hs>(c#0 ) \stemsUp<6hs> d \stemsUp )
\bm( \stemsDown<7hs> e \stemsDown
\fingering<text="3",fsize=7pt,dy=-7.5hs>(f#) \acc(g)
\stemsDown<7hs> e \stemsDown )
% measure 6 (voice 3)
\bm(f# e f# g)
\bm(a/8 \acc(c))
\bm(h-1 e0/16 f#)
\bm(g/8 h-1)
% measure 7 (voice 3)
\bm( \stemsUp a d0/16 e)
\bm(f#/8 a-1)
\bm( \stemsUp<12hs> g/16 \stemsUp f#0 e \stemsUp<8hs> d )
\bm( \stemsDown c# h a g)
% measure 8 (voice 3)
\bm(f# e d e)
\bm(f# e f# g#)
\bm(a/8 e)
\dotFormat<dy=1hs>
\bm(a. h/16)
% measure 9 (voice 3)
\bm( \acc(g) f# e f#)
\bm( g f# g a)
\bm( h/8 a)
g/4
% measure 10 (voice 3)
\tie<dx1=0.25hs,dy1=-1.5hs,dx2=-2hs,dy2=-1.5hs,h=-2hs>( f#/2 f#/4 )
\tieBegin<dx1=0,dy1=-1.25hs,dx2=-2hs,dy2=-1.25hs,h=-1.5hs> e
% measure 11 (voice 3)
e \tieEnd
\restFormat<posy=-4.8hs>
_/16 \bm(d e f#)
\acc( g/4 ) f#
% measure 12 (voice 3)
\tie<dx1=0,dy1=-2.2hs,dx2=-2hs,dy2=-2.2hs,h=-2hs>( h-1/2 h/4)
\tieBegin<dx1=0.2hs,dy1=-1.9hs,dx2=-2hs,dy2=-1.9hs,h=-2hs> a/4
% measure 13 (voice 3)
a/4 \bm( a/16 \tieEnd a0 g# f#)
\bm(e# c# d# e#)
\bm(f#/8 h-1/16 c#0)
% measure 14 (voice 3)
] }
 153

Curriculum vitae
1970 born in Darmstadt, Germany
1976-1980 Schillerschule, Darmstadt
1980-1983 Lichtenberschule, Gymnasium, Darmstadt
1983-1987 Georg-Büchner-Schule, Gymnasium, Darmstadt
1987-1988 Northridge Highschool, Middlebury, Indiana, USA
1988-1990 Lichtenbergschule, Gymnasium, Darmstadt
Allgemeine Hochschulreife
1990-1991 Städtische Kliniken Darmstadt, Zivildienst
1991-1993 Technische Universität Darmstadt
Studium der Physik, Abschluss Vordiplom
1993-1997 Technische Universität Darmstadt
Studium der Informatik, Abschluss Diplom
1997-2002 Technische Universität Darmstadt
Fachgebiet Automatentheorie und Formale Sprachen
Wissenschaftlicher Mitarbeiter

Erklärung
Hiermit erkläre ich, die vorliegende Arbeit zur Erlangung des akademischen Grades
Dr.-Ing. mit dem Titel “Algorithms and Data Structures for a Music Notation Sys-
tem based on G UIDO Music Notation” selbstständig und ausschließlich unter Ver-
wendung der angegebenen Hilfsmittel erstellt zu haben. Ich habe bisher noch keine
Promotionsversuche unternommen.

Darmstadt, 26. August 2002, Kai Renz, geb. Flade