A musician-oriented graphical user interface for …mdv/courses/CM30082/projects.bho/2009-10/... ·...

A musician-oriented graphical user interface for Anton

Henry Thacker

Bachelor of Science in Computer Science with HonoursThe University of Bath

May 2010

This dissertation may be made available for consultation within the Uni-versity Library and may be photocopied or lent to other libraries for thepurposes of consultation.

Signed:

A musician-oriented graphical user interface for

Anton

Submitted by: Henry Thacker

COPYRIGHT

Attention is drawn to the fact that copyright of this dissertation rests with its author. TheIntellectual Property Rights of the products produced as part of the project belong to theUniversity of Bath (see http://www.bath.ac.uk/ordinances/#intelprop).This copy of the dissertation has been supplied on condition that anyone who consults itis understood to recognise that its copyright rests with its author and that no quotationfrom the dissertation and no information derived from it may be published without theprior written consent of the author.

Declaration

This dissertation is submitted to the University of Bath in accordance with the requirementsof the degree of Bachelor of Science in the Department of Computer Science. No portion ofthe work in this dissertation has been submitted in support of an application for any otherdegree or qualification of this or any other university or institution of learning. Exceptwhere specifically acknowledged, it is the work of the author.

Signed:

Abstract

Anton applies ASP1 techniques to compositional rules to produce an algorithmic compo-sition system [Boenn et al., 2009a]. Anton is a system developed within the University ofBath in collaboration with the University of Glamorgan.

ASP is a declarative style of programming typically used to solve difficult search problems.In an ASP program, one declares “known facts” as a set of rules. A solver is then runover these rules and distinct solutions to the problem are given (if they exist). In Anton,the musical rules that constitute a valid piece of music have been encoded in a seriesof files written in AnsProlog*. Once a solver is run over these rules, a file is generatedwhich constitutes a “valid” piece of music. The current rule set built into Anton generatescompositions in a musical form known as “species counterpoint”. Anton’s rules are basedon those defined by Professor Markand Thakar.

To generate a composition using the command line version of Anton, one must run a Perlscript from the command line, passing a series of arguments to alter the characteristicsof the composed piece. One can also reverse the process to ask Anton whether a givenpiece of input music is considered valid. Another feature of Anton is its ability to auto-fillsections of empty measures within existing compositions. However, it requires a correctlyformatted input file describing the pre-existing musical material.

Many of the features provided by Anton cannot be found in traditional composition softwarepackages. Enabling musicians to have access to these advanced tools, in a user-friendly way,may help shape the evolution of future composition tools based on this technology. Thisproject details the extension of Anton with a graphical user interface to mask the existingcommand line interface with a view to making the software available, for the first time,outside of a computer science context.

1Answer Set Programming

Contents

List of Figures vii

List of Tables viii

Nomenclature ix

1 Introduction 1

2 Literature Survey 4

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Automated Music Composition . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Musikalisches Wurfelspiel . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 CHORAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 Strasheela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Answer Set Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Introduction to Answer Set Programming . . . . . . . . . . . . . . . 8

2.3.2 Answer Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.3 Other Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Anton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 The Use of ASP in Anton . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Relevant Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.1 Language Evaluation and Selection . . . . . . . . . . . . . . . . . . . 13

2.5.2 MIDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.3 MusiXTEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ii

CONTENTS CONTENTS

2.5.4 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.5 GTK+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.6 LilyPond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Project Management 21

3.1 Project Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.1 Requirements Gathering . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.2 Project Control List (Project Scope) . . . . . . . . . . . . . . . . . . 22

4 Iteration I 23

4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.2 Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Project Control List (Scope) . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4.2 Working with the Anton Scripts . . . . . . . . . . . . . . . . . . . . 30

4.4.3 Score Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.5 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5.1 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5.3 GUIDO Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5.4 Score Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5.5 Score Composition Workflow . . . . . . . . . . . . . . . . . . . . . . 38

4.5.6 Diagnosis Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.5.7 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5.8 Source Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

iii

CONTENTS CONTENTS

4.5.9 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6.1 Testing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6.2 Testing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.6.3 Testing Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.6.4 Results Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Iteration II 46

5.1 Project Control List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Further Design and Implementation . . . . . . . . . . . . . . . . . . . . . . 46

5.2.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.2 Score Serialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.3 Composition Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.4 Windows Fixes for Perl Scripts . . . . . . . . . . . . . . . . . . . . . 53

5.2.5 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.1 Results Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Iteration III 56

6.1 Project Control List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2 Further Design and Implementation . . . . . . . . . . . . . . . . . . . . . . 56

6.2.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2.2 MIDI Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.2.3 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.3.1 Results Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.4.1 Building and Packaging . . . . . . . . . . . . . . . . . . . . . . . . . 58

7 Evaluation 60

iv

CONTENTS CONTENTS

7.1 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.4 Personal Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Bibliography 65

A Designs 68

A.1 Iteration I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.1.1 Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.1.2 Other Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

A.2 Iteration II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.2.1 Composition Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A.3 Iteration III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.3.1 MIDI Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

B Screenshots 72

B.1 Iteration I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

B.2 Iteration II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

B.3 Iteration III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

B.4 Cross-Platform - OS X, Windows, OpenSUSE Linux . . . . . . . . . . . . . 76

C Examples 77

C.1 Example - Legacy Score File . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

C.2 Example - Native XML Score File . . . . . . . . . . . . . . . . . . . . . . . 79

D Diagrams 80

D.1 Score Editor - Logic Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

D.2 Score Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

D.3 Property Node Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

D.4 Composition Buffer List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

E Test Scripts 85

v

CONTENTS CONTENTS

F Patches 103

F.1 Patch to parse.pl [1.5.0] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

G User Guide 105

H Source Code 119

vi

List of Figures

2.1 Johann Philipp Kirnberger - Paraphrased from the German [Gedan, 2009] . 5

2.2 Bars 1-8 of a minuet composed using an online tool . . . . . . . . . . . . . . 6

2.3 Basic ASP rules - typical syntax . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 ASP positive program - example taken from [Brain and De Vos, 2008] . . . 10

2.5 ASP non-positive program - example taken from [Brain and De Vos, 2008] . 10

2.6 Dorian mode definition from Anton . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 Error predicate - detecting notes from other modes . . . . . . . . . . . . . . 13

2.8 Perfect cadence definition from Anton . . . . . . . . . . . . . . . . . . . . . 13

4.1 Reading an answer set score . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 ComposeWorkflow - Constituent tasks . . . . . . . . . . . . . . . . . . . . . 38

4.3 DiagnoseTask - Constituent tasks . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4 Rule violation error format . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1 Colour property definition in FragmentListModel . . . . . . . . . . . . . . . 49

A.1 User Interface: Designs for iteration I . . . . . . . . . . . . . . . . . . . . . 69

A.2 User Interface: Composition buffer . . . . . . . . . . . . . . . . . . . . . . . 70

A.3 User Interface: MIDI input . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

vii

List of Tables

1.1 Popular music production / scoring applications . . . . . . . . . . . . . . . 2

5.1 Serialised score data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

viii

Nomenclature

ASP Answer Set Programming

CAAC Computer Aided Algorithmic Composition

GUI Graphical User Interface

HCI Human Computer Interaction

IDE Integrated Development Environment

LGPL Lesser General Public License

MIDI Musical Instrument Digital Interface

MVC Model View Controller

ix

Acknowledgements

I would like to extend my thanks to all who provided support and assistance throughout thisproject. In particular, I would like to express my gratitude to my supervisor Dr Marina DeVos and Martin Brain (the original developer of Anton), both of whom were instrumentalin providing direction for the project.

x

Chapter 1

Introduction

Over the past two decades, a lot of work has been done in the field of human computerinteraction (HCI). This work has become necessary with the increasing complexity of dailyinteractions between man and machine. [O’Neill et al., 2006] describe the need for a rev-olution “comparable to the revolution in the 1980s from command line to graphical userinterfaces”. Today, a majority of user-facing computer applications are presented to theusers via a graphical user interface. Examining existing music software, in addition tothe plethora of new input methods that are being researched, one will almost always findthe retention of some type of score editor. Most classically trained musicians will feel “athome” when presented music in this format, thus it has become a ubiquitous interfacewithin music software. Appendix D.1 (on page 81) shows a typical implementation of ascore editor.

Anton suffers at the moment because of the lack of a user interface. This means thatinputting pre-existing musical material is difficult. If this were made easier, Anton wouldbe more useful to musicians because it could be used to extend existing music. Withouta method of inputting music, musicians would have to learn Anton’s custom input for-mat and spend a long time converting musical extracts to conform with this new format.Including a score editor would instantly make Anton accessible to many more musicians.These musicians would be able to get to grips more quickly with the software and becomemore productive. It would be even better to include some kind of MIDI import / directrecording. However, this is more technically demanding and it may well fall out of thescope of this project - although it is definitely something for serious consideration.

Even as far back as 1985, it is possible to find research that suggests that the processof designing effective computer-music interfaces, especially in the field of composition, isparticularly difficult [Pennycook, 1985]. Pennycook draws reference to the compositionmethods of composers such as Beethoven and Stravinsky. Within these references he illus-trates how the methodologies adopted by different composers causes their workflows to varyenormously. In order to streamline a composer’s use of composition software, Pennycookseems to suggest that it is necessary for a composer to be able to tailor their software for

1

CHAPTER 1. INTRODUCTION

Sibelius ProTools 8 Logic Studio Reason Rosegarden CsoundWindows X X X X

OS X X X X X XLinux X X

Table 1.1: Popular music production / scoring applications

their own purposes.

Users of software such as Logic Studio Pro and Sibelius will quickly notice the flexibil-ity that they offer to composers. As with any other expert system, users will probably notwant to be forced into using a single methodology defined by the programmer or systemarchitect.

It is also interesting to extrapolate some of the ideas that are introduced in Pennycook’spaper. As this was written in 1985, the prevalence of personal computers was not suchthat everyone had (or could afford) their own machines and could compose/record entirealbums from the comfort of their bedrooms. Now not only are computers everywhere wego, but we have a lot more choices about which computers we buy and what software theyrun. Looking at the latest statistics from Wikipedia (compiled and averaged from a numberof reputable sources), we can see that there are a handful of different desktop operatingsystems, each with large user bases [Wikipedia, 2009b]. Looking at the platform compat-ibility table (Table 1), we can see that music application developers target each of theseuser bases with various product offerings. This shows us that Pennycook’s assumptionsabout workflow can also be applied to software portability. Music software developers haverecognised that musicians do not wish to be restricted to a single operating system or aspecific version of an operating system. Their products must be as diverse as their userbase.

Coming back to Anton and looking at how some of this knowledge might be applied, itmakes sense to start by looking at some of the restrictions it places upon the composer.One of the issues with Anton is that it currently only wraps the definitions of one musicstyle. It cannot be assumed that every potential user that could benefit from the auto-matic composition features of Anton would want to compose in a single style. As such, itwould be beneficial to try and pass this control over to the user. Composition should notbe hampered by rules imposed by the software, thus opening up styles for user definitionwould ensure better adoption within the music community. It is conceivable that a powerfulstyle definition interface could be fairly complex to use, however usability should always beconsidered the foremost priority when designing for a greater cross-section of users.

As a summary of the initial reading around the problem domain, it is apparent that Antonis a unique product and needs to be extended in order to access to this wide and diversifieduser base, who may wish to take advantage of Anton’s features. A lack of graphical userinterface is the main problem with Anton in its original form and is the pre-cursor to many

2

CHAPTER 1. INTRODUCTION

of the points raised above.

This project details the analysis, design and implementation that was carried out to developa graphical user interface for Anton. The original, key aims for this project were to developan interface to expose many of Anton’s unique features while developing in a platformindependent way, ideally incorporating some type of score view. At the conclusion of theproject, not only were a majority of the aims met, but several key, novel features weredeveloped that supplement the features already available in Anton. The provided userinterface not only has the potential to bring Anton into the workflows of musicians, butalso provides a solid platform upon which Anton could be extended.

3

Chapter 2

Literature Survey

2.1 Introduction

In preparation for the design and implementation of the project, it is first necessary to fullyresearch the problem domain to see what work has previously been done in this area. Someof the main areas that are connected to Anton include Answer Set Programming, otherexisting logic composition applications, possible implementation languages / frameworksand general HCI1 material that may provide a better understanding of how an effectiveinterface to Anton can be built.

Examining basic ASP2 techniques will impart knowledge about how Anton’s musical rulesare built and encoded. A good understanding of these rules is required so that the problemof extending Anton with additional musical styles can be fully understood.

Several music applications already exist which compose music through a variety of dif-ferent applications of logic and methods of reasoning. Looking at these systems will revealboth positive and negative aspects in their approach to user interface design. It will beparticularly of interest to see how the existing programmes cope with making their fullfeature-set available to the users. In addition to picking up good practices that are em-ployed by other systems, it is important to highlight and develop solutions to any potentialproblems in these comparative systems that will directly benefit the provided interface toAnton.

A literature survey is an important document of self-validation and will be a critical ref-erence at certain points in the project, based on the experience and expertise of previousacademic work.

1Human Computer Interaction2Answer Set Programming

4

2.2. AUTOMATED MUSIC COMPOSITION CHAPTER 2. LITERATURE SURVEY

2.2 Automated Music Composition

2.2.1 Musikalisches Wurfelspiel

[Ayers, 2008] defines algorithmic composition as “Automatic music composition, also calledalgorithmic composition or computer-assisted composition, uses computer programs tocompose music. . . ”. While this definition is true in essence, in general, an algorithm isnot necessarily restricted to a computer-based implementation. It is fair to say that aset of well-defined instructions could constitute some kind of naıve algorithm. Mozart de-veloped a relatively early example of non-computer based, algorithmic composition in theform of the “Musikalisches Wurfelspiel” (literally: musical dice game). The “Musikalis-ches Wurfelspiel” is an interesting topic, because many composers prior to Mozart areknown to have developed similar music dice games. Unfortunately any documents detail-ing the work of other composers in this space seems to be non-existent, even in libraries[Kupper, 1995]. However, the University of Mainz kindly provides online scans of JohannPhilipp Kirnberger’s paper, written in 1757 entitled “The ever ready composer of Polonaisesand Minuets” 3.

It is quite possible that the German music theorist and organist Johann PhilippKirnberger’s instructions from 1757 on how to compose “innumerable numbersof Polonaises, Minuets and corresponding Trios” with the help of a dice, wasa forerunner of many of today’s computer programmes such as the so-called“Band in a box” games to even compositional tools. . . . Such systems do littleelse than “play” Kirnberger’s dice game even though many likely employ subtlymore complex algorithms.

Figure 2.1: Johann Philipp Kirnberger - Paraphrased from the German [Gedan, 2009]

This work is particularly of interest, because as Gedan correctly states, these types of gameare the pre-cursor to many modern games and software. For instance, as part of their “iL-ife” package, Apple offer a music composition tool for home-users called GarageBand. Afeature of GarageBand, known as “Magic GarageBand”, allows users to jam along to acustomisable backing track. While it seems most of the backing tracks are static for anyselected instrument within a given genre, the user is able to change parts at will using theuser interface. Thus, it seems that some of these so-called “Composition Tools” do noteven attempt to introduce chance into the material that is “composed”.

Despite Kirnberger’s set of instructions being written over 250 years ago, the same tech-niques are being employed today to try to bring algorithmic or pseudo-algorithmic processesinto music composition. What is particularly of note is that a lot of time is spent mak-

3http://www.musikwissenschaft.uni-mainz.de/Musikinformatik/schriftenreihe/nr15/

Kirnframe.html

5

http://www.musikwissenschaft.uni-mainz.de/Musikinformatik/schriftenreihe/nr15/Kirnframe.html

http://www.musikwissenschaft.uni-mainz.de/Musikinformatik/schriftenreihe/nr15/Kirnframe.html


ing these systems usable. The aforementioned iLife package is included with every newApple computer that is sold. The software is designed so that it can be simply picked upby anyone, even those with no prior musical knowledge. Even the more complex musicaldice games could have been played by anyone, musical or not, when they had the bookof instructions. These techniques are simple and simple techniques map more easily intouser-friendly software.

Various web implementations exist that will generate music based on instructions fromthe different musical dice games that exist. Chuang has developed an online generatorbased on Mozart’s “Musikalisches Wurfelspiel”. The start of a sample, randomly gener-ated minuet is given in Figure 2.2. This type of resource shows how the whole process canbe completed in one single click of a button, with no dice needed. The ease-of-use of suchsystems should be taken into account during the development of Anton. While Anton will,of course, have many more options, it should still be possible to access this core compositionfunctionality without having to understand the ASP rules.

Figure 2.2: A minuet (bars 1 - 8) composed using Mozart’s “Musikalisches Wurfelspiel”technique. Generated using an online implementation [Chuang, 1995]. The numbers be-tween the staves represent which randomly selected phrase was chosen in each bar.

2.2.2 CHORAL

Ebcioglu developed an expert-system known as CHORAL that was capable of harmonisingfour-part chorales in the style of J.S. Bach. The harmonisation was encoded in a series ofaround 350 rules. To implement CHORAL, Ebcioglu developed a new logic-programminglanguage which he called BSL (Backtracking Specification Language) [Ebcioglu, 1988]. TheBSL language compiler was written in LISP and generated C target code. Ebcioglu’s paperdescribes his approach to composition as “generate-and-test”. The work of Ebcioglu is very

6


interesting, as he found Prolog and LISP to be too slow for implementing his approach.While an ASP-oriented language, such as AnsProlog*, would probably not have been suit-able direct replacement for BSL within CHORAL, certain parallels can be drawn to Anton.Anton uses similar kinds of assertive rules to describe what harmonic and melodic pat-terns are considered “valid”. CHORAL seems to attack the problem of how the answer iscomputed, whereas Anton relies on the method and associated efficiency of the grounderand the solver. CHORAL continually evaluates the work it has done so far by studyingit from multiple viewpoints. These viewpoints concentrate on certain parts of the music,i.e. the chords, the melody (for restricting certain intervals) and fill-ins (passing notes andsuspensions). Anton has a similar set of view points, implemented via multiple rule files(chord.lp, harmony.lp, rhythm.lp etc). Essentially these rules, despite being compart-mentalised in separate files, are not implemented as subsystems of observers, but are globalobservations, all of which should be consistently valid.

CHORAL differs from Anton in that a global decision is taken to back-track and tryanother solution once a “dead-end” situation is met. This dead-end situation in Anton iscompletely black and white - a given composition is either valid or not. We can even run apiece through Anton and ask whether it is valid. If the piece is not valid, we can try with adifferent input until we find a valid input. Through various levels of heuristics, CHORALattempts to encode various rule exceptions and “musical intelligence” through Ebcioglu’sintensive research and observation of Bach’s harmonisations. This gives the impressionthat the detection of a “dead-end” situation is somewhat ambiguous and that althoughthe resultant harmonisation might be considered “more musical”, the amount of processingrequired is much higher.

In terms of user interface, CHORAL is a batch CAAC (Computer Aided Algorithmic Com-position) system [Ariza, 2005]. Ariza provides a useful definition of a batch interface forcomputer aided composition systems. He also mentions that in many cases, modern-daybatch processing can be preferable to using an interactive system. This statement is cer-tainly true in many cases, one example is the many Unix-based server systems that operate,even today, with no graphical window manager. In an expert system (such as CHORAL),users who are proficient with the input syntax and command-set will often be more pro-ductive in a batch/non-graphical environment. Proficient users will be able to use all ofthe functions they desire without being slowed down by having to dismiss series of complexdialog boxes and locating hidden menu options. However, CHORAL was written specif-ically to take one type of input and was evidently not designed to target consumer levelmachines (it ran on IBM mainframes) or even be used by any given musician. Our mainaim for Anton is to make it more accessible, portable and expandable. As a result, wewant to ensure that proficient users can still utilise the command-line (batch like) interfaceand all other users can make use of the new graphical interface.

7

2.3. ANSWER SET PROGRAMMING CHAPTER 2. LITERATURE SURVEY

2.2.3 Strasheela

Strasheela is another CAAC (Computer Aided Algorithmic Composition) tool. Strasheelais slightly different to Anton, in that it uses constraint logic programming. Anders describesconstraint logic programming as “a programming paradigm which introduces techniques tosolve constraint satisfaction problems” [Anders, 2007]. The whole of Strasheela is writtenin a language called Oz.

The Strasheela user interface is the Oz programming language: a Strasheelauser writes an Oz program which applies Strasheelas contributions to Oz mostof all its score representation. [Anders et al., 2005]

The way that users interact with Strasheela is completely different to the way that usersinteract with Anton. A user of the Strasheela system must understand the API (Applica-tion Programming Interface). Additionally, this will require the user to be able to programin the Oz programming language. It seems that the target audience of such a system willbe very limited. [Boenn et al., 2009a] also make the comparison between the comparativesize of code-base between Anton and Strasheela (800 and 8000 lines respectively). Whilethis is a perfectly valid comparison to make, it must be noted that the systems are funda-mentally different in terms of their feature sets and goals. The goal of Strasheela is to makeoriginal music, but for demonstration purposes they have encoded a series of counterpointrules, similar to those provided by Anton. As both Anton and Strasheela provide encodedcounterpoint rules, the number of lines of code certainly look in Anton’s favour, especiallyconsidering that both systems will generate similar kinds of output.

Another problem is that Oz is a multi-paradigm language. As such, one is able to writeprograms that combine imperative, functional, logic, constraints, object-oriented and manymore different programming paradigms. Strasheela makes use of both object-oriented andconstraint based programming styles, which is certainly not something that could be easilypicked up by many programmers, let alone musicians.

2.3 Answer Set Programming

2.3.1 Introduction to Answer Set Programming

Answer Set Programming (henceforth referred to as ASP) is a declarative programmingparadigm. ASP programs typically target difficult (NP-hard) search problems. A pro-gram written using the ASP paradigm will typically use a prolog-like language to declareknown information. The focus of an ASP program is on the solution rather than themethod. A common declarative language used for ASP programs is AnsProlog*, describedby [Baral, 2003] as “logic programming with the answer set semantics”. Anton uses ruleswritten in AnsProlog* to describe what constitutes a valid piece of music.

8


ASP is very useful in many fields as fact-based problems can be implemented/solved ina much shorter time than comparative procedural programs. “[ASP is often used for]programs that must be correct with respect to a formal specification. . . ”[Baral, 2003] - thisuseful property is true because the formal specification for an ASP program is actually theprogram itself.

Before discussing how solutions to answer set programs are generated, a brief discussionof the syntax and semantics will be given. The information within an ASP program isencoded through the use of one or more atoms. All atoms are assigned truth values (eithertrue or false). In Figure 2.3 a, b1...m and c1...n are all atoms. The atom a is called the“head” of its clause.

A core concept within an ASP program is negation as failure. While it is possible torepresent two different types of negation within an Answer Set program [Lifschitz, 2008],the definition of negation as failure is particularly important to the Answer Set semantics.Negation as failure means that if a fact has not been proven to be true then we assumeit to be false. An atom can be negated in this way by prefixing it with not. Atoms ornegated atoms are collectively referred to as literals.

A “rule” has an atom in the head and the body consists of one or more literals. Rules withempty bodies are known as facts. When reading a rule, if the body of a rule is true (orempty) then this causes the head to be true. An answer set program Π is called a “positiveprogram” if none of its rules contain negation as failure.

a : − b1, . . . , bm, not c1, . . . , not cn

Figure 2.3: Basic ASP rules - typical syntax

2.3.2 Answer Sets

An answer set is a set of truth assignments to atoms, for instance {q, p, r} is a shorthandnotation which states that the atoms q, p, r are true. Any atom outside of this set is false,thus not a will be true by the negation as failure semantics.

First, the definition of an answer set for a positive program will be given. By [Lifschitz, 2002],an answer set for a positive program Π is the minimal set from those sets that are closedunder Π. A set X is closed under Π if for every rule in Π, Head of Rule ∩ X 6= ∅ wheneverBody of Rule ⊆ X.

9


If the positive program Π is denoted by:

a ← b.

b ← .

c ← a, b.

d ← b, c.

e ← f.

f ← e.

The set {b, a, c, d} is an answer set for Π.

Figure 2.4: ASP positive program - example taken from [Brain and De Vos, 2008]

For programs that contain negation as failure, a reduct ΠX of Π relative to X is generated.The “Gelfond Lifschitz” reduct produces a positive program obtained from non-positiveprogram Π via the following method:

• Removing rules whose bodies contain some negative literal not belonging to X andcontain literals that do belong to X

• Removing all negative literals from the remaining rules.

The set X is said to be an answer set for non-positive program Π if X is an answer set forΠX .

If the non-positive program Π is denoted by:

a ← not b.

b ← not a.

c ← not d.

e ← a, c, not b.

f ← not g, e.

g ← not f, e.

The reduct with respect to {b, c}, Π{b,c} is thus:

b ← .

c ← .

f ← e.

g ← e.

Figure 2.5: ASP non-positive program - example taken from [Brain and De Vos, 2008]

10

2.4. ANTON CHAPTER 2. LITERATURE SURVEY

The set {b, c} is an answer set for Π. The sets {a, c, e, f} and {a, c, e, g} are also answersets for Π

2.3.3 Other Constructs

Constraints can be specified in an ASP program by omitting the head of an expression,resulting in an expression such as: ← x, not y. Rules of this form can be used to enforceproperties on the solutions that are generated. Constraints are considered “syntactic sugar”and can be rewritten as a series of normal rules. Another type of expression is a “choicerule”. The choice rule, expressed {a, b, c}, states that any combination of the atoms a, b orc may be selected arbitrarily. A special syntax also allows choice rules to be constrained,e.g. 1{a, b, c}2 which states that at least 1 of the atoms will be selected, but no more than2.

ASP programs can contain variables, which are generally represented with upper caseletters. For instance, Figure 2.7 (on page 13) shows an example which contains the threevariables P, T,C. Solutions to ASP programs are generated by passing the input programthrough two different phases. The first phase removes all of these first-order variables fromthe input program resulting in a “ground (variable-free) program”. The second processgenerates the answer sets from the ground program. Gringo is the grounder that is usedwithin Anton and clasp is the solver, both can be found on the Potassco Sourceforge projecthomepage4.

2.4 Anton

[Boenn et al., 2009b] give an overview of the difficulties involved in automated compositionand the approaches taken by existing systems (discussed in Section 2.2 on page 5). Thesection on Anton is particularly interesting because it discusses Anton’s radically differentapproach to composition. While other systems exist that use techniques such as Markovchains to compose melody and harmony in automated way, Anton is unique in using thepower of the Answer Set Programming paradigm for music composition. A property of thechosen methodology is that melody and harmony choices are evaluated simultaneously, tak-ing the whole piece into account. This means that rather than composing pieces in smaller,fragmented parts, Anton is able to make choices that ensure the validity of the whole piece.

Another noted benefit of viewing the entire score as a whole during composition is thatmissing notes or whole sections can be filled in automatically. This is possible because thecomposition approach does not operate sequentially, building a piece from start to finish.Instead, the defined rules place constraints on the melody and harmony that is expectedin the sections that have already been composed and those that need to be filled. ThusAnton is able to make composition decisions irrespective of where these empty parts occur,

4http://potassco.sourceforge.net/

11

http://potassco.sourceforge.net/

2.4. ANTON CHAPTER 2. LITERATURE SURVEY

i.e. there is no pre-requisite to have several notes prior to an empty part in order to beable to automatically fill the empty parts. It is clear that the use of ASP techniques hasallowed [Boenn et al., 2009b] to ignore the actual process by which the compositions arecreated (this problem being passed to the solver / grounder programs that are used) andinstead concentrate on the musical properties that the finished composition should possess.

[Boenn et al., 2009a] go on to discuss some of the other features present in Anton suchas the “diagnosis mode”, which is able to detect specific rule violations within a givenpiece. The diagnosis feature, in particular, takes Anton from simply being an algorithmiccomposition system to a system that can be used to validate manually composed material.The fact that the rules are already defined to aid the system in the automatic compositionprocess means that the hard work of creating a validation procedure for an arbitrary piecehas already been done. The ability to easily develop additional features such as this, furtherhighlights the benefits of using ASP techniques in a composition system.

2.4.1 The Use of ASP in Anton

In order to provide some context for ASP within Anton, Figure 2.6 demonstrates the useof some ASP rules that encode the concept of the dorian mode.

modeChromaticPosition(1) : − mode(dorian).modeChromaticPosition(3) : − mode(dorian).modeChromaticPosition(4) : − mode(dorian).modeChromaticPosition(6) : − mode(dorian).modeChromaticPosition(8) : − mode(dorian).

modeChromaticPosition(10) : − mode(dorian).modeChromaticPosition(11) : − mode(dorian).

Figure 2.6: Dorian mode definition from Anton

The definition in Figure 2.6 states that degrees 1, 3, 4, 6, 8, 10, 11 of the chromatic scale(starting on the fundamental note) can be present in a piece declared as being in the do-rian mode. This rule can then be used to detect pieces which contain notes not presentwithin the relevant mode. If a piece declared mode(lydian), starting on its native funda-mental F , but F] was used (F] would be the 2nd degree of the F chromatic scale, whichis not present in the lydian mode), then this note will be marked as not belonging to thecurrent mode. The presence of notes from other modes is detected using an error predicate(seen in Figure 2.7 on page 13). The presence of such error predicates allows us to flag thepiece as being an invalid composition.

12

2.5. RELEVANT TECHNOLOGIES CHAPTER 2. LITERATURE SURVEY

#const err_nik="Choosen note not in mode"reason(err_nik).err(P,T,err_nik) :- choosenChromatic(P,T,C), not modeChromaticPosition(C).

Figure 2.7: Error predicate - detecting notes from other modes

The predicate modeChromaticPosition(C) will only be defined if the Cth degree of thechromatic scale is a member of the chosen mode. If modeChromaticPosition(C) is notdefined then this means that the current note (in part P, at time T) is not in the requiredmode. In such cases the “negation as failure” semantics mean that the clause will becometrue, associating the error with the note in question.

A more complicated rule is also demonstrated in Figure 2.8 which is the encoding of aperfect cadence. The rule defines that we have a perfect cadence at T , if the chord atposition T − 1 is the dominant chord, followed by the tonic chord at T .

cadence(T, “perfect”) : − chord(T − 1, “dominant”), chord(T, “tonic”), time(T − 1).

Figure 2.8: Perfect cadence definition from Anton

The developers of Anton ([Boenn et al., 2009a]) saw the use of ASP techniques as a naturalchoice for music composition because musicologists use similar rule based analytics forcategorising music into different genres and styles. The ASP paradigm allows the rules inAnton to be incredibly small in number, but expressive enough to allow very good musicto be produced as output.

2.5 Relevant Technologies

2.5.1 Language Evaluation and Selection

A large step in any project is the choice of which implementation framework and languageto use. In many commercial development environments, the language choice is normallydictated or limited to a strict subset of pre-selected languages. During the implementationof this project, an appropriate language and associated framework must be selected thatwill provide all the necessary features, be easy for others to work with and is preferably

13


open-source, to maintain the existing open-source nature of the project.

The main aim for this project is to develop an interface that will allow musicians to gainaccess to the extensive feature set of Anton. With this in mind, it makes sense that fea-tures such as score editors and other interfaces that musicians are familiar with are includedwhenever necessary. A lot of these interfaces are fairly complicated in terms of design andcode complexity. The study of many of these types of interface has been the focus of entireprojects in their own right. As a result, a lot of the problems in this space have been thor-oughly researched and documented. Unfortunately, it seems probable that much of thiswork is never released into the public domain, because the resultant code is incorporatedinto commercial music applications. One of the key aims of this section is to evaluate whatexisting, open-source parts have been developed that could potentially be reused and howthis may limit the choice of development language(s).

Rather than looking directly at the relative merits of various programming languages,it is more useful to examine the various existing open-source solutions for music scoringand other relevant components that are available. The programming language is secondaryto the interface that is provided and as such, this is the way that the problem will beresearched.

Computer music scoring interfaces have been around for a very long time. Despite beingwritten in 1984, Byrd’s thesis accurately describes many situations where scoring music isan imprecise science [Byrd, 1984]. While many of the challenges he discussed have beensolved, for instance a lot is written about using algorithms and artificial intelligence toperform collision detection of barlines and text, it is still assumed that humans will almostalways need to tweak the final output. [Blostein and Haken, 1991] state that “Music pro-cessing lags far behind text processing because of the complexities of music notation. Mostmusic published today is still laid out by hand; [. . . ] decisions about music-symbol place-ment are made by people.”. Over the course of the last decade, this statement has becomemore and more invalid with the advent modern music packages such as Sibelius5, howeverit has taken researchers several decades to get close to the solutions that we have availabletoday. Due to the expertise and time spent in existing research comparative to the timeavailable to complete this project, it makes sense to concentrate on evaluating existingsoftware that can be reused, rather than attempt to develop everything from scratch.

2.5.2 MIDI

MIDI (Musical Instrument Digital Interface) was specified in 1983 as a standardised datainterchange format between synthesisers of different manufacturers. By using MIDI, amusician was able to ensure that a musical fragment recorded using the flute patch onone synthesiser (for example) would be played back using the corresponding flute patchon another synthesiser. No analog music signals are sent over MIDI, instead a stream of

5http://www.sibelius.com

14

http://www.sibelius.com


MIDI events are sent when musical events happen. MIDI also sends lots of metadata thatallows synthesisers to adjust their internal clocks for performance synchronisation, recordthe change in tempo at a particular section and many other types of performance-relatedmessages6. Support is also provided for the recording of other (sometimes manufacturerspecific) MIDI events so that performances can be recorded and played back faithfully, forinstance: pitch bend / vibrato controls / patch changes. Because of the prevalence and ma-turity of the MIDI standard, there are many tools available for reuse in the public domain.

Most MIDI applications support some kind of score representation, however it is incrediblyunlikely that importing the same MIDI file into different software packages will produceanything like the same score. In order to resolve this issue in their own programs, the devel-opers of MIDI editor packages have traditionally developed their own file formats in orderto preserve information about score setup and layout, features that were (correctly) left outof the MIDI standard. The MIDI Manufacturer’s Association claim on their website7 thatMIDI can be used to “Print Sheet Music”. This statement is entirely false, because MIDIis an interchange format. The events within a MIDI file can be used to construct (reverseengineer) a score, but metadata about the score (page layout, floating text) cannot be pre-served in a portable way and thus, score rendering has to be implemented independently,separated from the MIDI representation. A score and a MIDI file are two distinct objects,a MIDI file holds a lot of information that is not represented in a score and visa-versa. Itis not a simple superset - subset relationship. The existing third-party libraries generatescores based on common elements in both MIDI files and scores. All metadata only presentin scores must then be stored in an application specific format which wraps the MIDI data.Because of this restriction, instead of being able to leverage a lot of existing MIDI codewhich exists, it is necessary to find some kind of alternative music representation that canproduce a deterministic graphical score representation as its main goal.

One potential use for MIDI within the Anton project would be a live playback featurefor the composed material.

2.5.3 MusiXTEX

MusiXTEX is described as a “. . . set of TEX macros to typeset polyphonic, orchestral or poly-phonic music” [Taupin et al., 2005]. MusiXTEX allows users of LATEX to embed musicalnotation within a document. Unlike GUIDO, MusiXTEX does not apply (many) musicalrules to the produced output, the composer is required to make their own choices relatingto note grouping, spacing and other typesetting decisions. This is the desired behaviour ofMusiXTEX as it is concerned with letting users precisely typeset a score. While this is verypowerful, it unfortunately makes the reuse of MusiXTEX within another application fairlydifficult, because that application would then have to undertake the fairly arduous task ofencoding all of the various music rules that relate to music scoring. Because MusiXTEX

6http://www.midi.org/techspecs/index.php7http://www.midi.org/aboutmidi/tut_makemusic.php

15

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

http://www.midi.org/aboutmidi/tut_makemusic.php


is designed primarily to produce postscript output files, as with standard LATEX, this isnot an ideal format for embedding within an application. The typeset MusiXTEX PDF filewould have to be displayed within Anton using some kind of embedded PDF viewer. Thisproblem is not insurmountable, but it is far from ideal.

The MuX2d8 project attempts to wrap MusiXTEX within their own graphical user in-terface, but it does not seem to be especially stable or well-supported. Additionally theauthor admits on the project’s home page that the project is currently not mature enoughfor serious use.

2.5.4 Qt

2.5.4.1 Introduction

Qt is a C++ framework, originally developed by Trolltech, but now owned by Nokia. Qtprovides a lot of framework classes (networking, databases, etc.) and has been invested inheavily, culminating in arguably one of the best cross-platform GUI9 toolkits.

Qt is a mature C++ framework that is widely used around the world. Inaddition to Qts many commercial uses, the Open Source edition of Qt is thefoundation of KDE, the Linux desktop environment. [Nokia Corporation, 2009]

Qt’s use within the extremely popular KDE window-manager for Linux demonstrates thestability and maturity of the framework. Additionally, as a fairly recent change Qt hasadopted the GNU LGPL10 which, like Anton, embraces the notion of open-source. VariousQt-based open-source music projects exist that prove that Qt would be a suitable frame-work to use, for instance: NoteEdit and Rosegarden. Another relatively new project usingQt is the QuteCsound project11, which is an alternative, graphical front-end to Csound.

Another huge advantage of Qt is that the framework embraces the “write once, compileanywhere” approach. The Qt framework does not just provide portability between differ-ent desktop operating systems, but also embedded and mobile devices. This is particularlyrelevant given Anton’s requirement to be as portable as possible.

2.5.4.2 GUIDOLib

GUIDOLib12 is a C++ library for parsing and displaying scores represented in the GUIDOmusic format. The GUIDO music syntax is similar to that of Lilypond [Wikipedia, 2009a].

8http://mux2d.sourceforge.net/index.shtml9Graphical User Interface

10Lesser General Public License11http://qutecsound.sourceforge.net/12http://sourceforge.net/projects/guidolib/

16

http://mux2d.sourceforge.net/index.shtml

http://qutecsound.sourceforge.net/

http://sourceforge.net/projects/guidolib/


This in itself is a huge advantage as Anton can already output compositions in Lilypondformat. GUIDO music representation feels like it has been created with developers in mind.Both the simple and advanced GUIDO groups of functions have been wrapped up in anopen-source, cross-platform library, ready for reuse. Another benefit is that “GUIDO canalso be used to represent incompletely specified music material. . . ” [Hoos et al., 1998]. AsAnton is able to compose small fragments as well as entire compositions, the ability todisplay small fragments of incomplete music is beneficial. In addition to standard, plat-form specific C++ libraries, they also maintain a platform-agnostic Qt port of GUIDOLib.

[Hoos et al., 1998] state the need for GUIDO by describing the shortcomings of MIDI (Mu-sical Instrument Digital Interface). The material regarding MIDI in Section 2.5.2 (on page14) talks about the deficiencies of MIDI being used for accurate, faithful musical typeset-ting. [Hoos et al., 1998] take this concept further by discussing the need for a plain-text,human readable format for use over the Internet. Using a text format rather than a binaryone makes interoperability with other systems easier, as writing file converters is trivial forplain text files.

One disadvantage is that GUIDOLib provides no functionality to allow the user to graph-ically edit a score and the underlying GUIDO representation. This is understandable,as GUIDOLib is concerned with score representation rather than providing music editingfeatures. True editing features could certainly be added by third-party developers. Al-ternatively, the user could be given the impression that they are able to edit the musicby providing an editing layer on top of the display. This virtual editing layer would workdirectly on the GUIDO text representation underneath the score display, refreshing thescore view where necessary.

2.5.4.3 Canorus

Canorus13 is another C++ Qt based project. Instead of a score representation library, itis a whole score editor. It grew out of a previous open-source project called NoteEdit14.Canorus uses the MVC (Model View Controller) architecture which means that reusingpart of the library’s Qt widgets would be fairly straightforward [Katzmann, 2009]. Unfor-tunately, like MuX2d (Section 2.5.3 on page 15), Canorus is still in a fairly early phaseof development and there is not much third-party information available online about it orsupport for the proprietary file format that it uses. In addition to providing score rep-resentation widgets, Canorus comes with support for MIDI playback. As mentioned inSection 2.5.2 (on page 14), MIDI playback is one feature that would be useful within An-ton. Canorus are using the RtMIDI library15 to achieve MIDI playback.

The MVC architecture, first made widely available in Smalltalk [Sommerville, 2007], is13http://canorus.berlios.de/wiki/index.php/Main_Page14http://noteedit.berlios.de/15http://www.music.mcgill.ca/~gary/rtmidi/

17

http://canorus.berlios.de/wiki/index.php/Main_Page

http://noteedit.berlios.de/

http://www.music.mcgill.ca/~gary/rtmidi/


particularly beneficial for a music application such as Canorus or Anton. If the view layerand model layers are separated, then it is possible to instantiate many views (think ofgraphical windows) pointing to the same piece of data using a different perspective. InAnton, this could be looking at two different parts of the same score. Because the modelis shared, making destructive changes to the score from one view would be reflected in theother view instantaneously.

2.5.5 GTK+

2.5.5.1 Introduction

GTK+ is another framework, like Qt (Section 2.5.4 on page 16), but written in C. How-ever, unlike Qt, GTK+ is purely a graphical user interface framework. GTK+ also adopts a“code once, compile anywhere” type approach. Mobile devices are also supported throughGNOME’s GMAE (GNOME Mobile and Embedded) initiative. GTK+ is also the ba-sis of two different window managers, the very popular GNOME environment and XFCE[Krause, 2007]. Even though GTK+ is written in C, it has been written in an object-oriented way using constructs and features present in the underlying GLib library. Bindingsare available for many popular languages including C++ [The GTK+ Team, 2008].

It is difficult to directly compare GTK+ to Qt as the frameworks are different in theirfeature set, even though they attempt to address similar goals in the GUI frameworkspace. All of the various webpages that try to do this lack reference to published findingsand seem purely subjective.

2.5.5.2 Denemo

Denemo is a composition tool written in the GTK+ framework. It provides score-editing,transcription and arrangement tools. As Denemo leverages GTK+, it also benefits fromcross-platform support. Denemo itself does not render the score, but it relies on LilyPond’stypesetting abilities to draw the score for display (Section 2.5.6 on page 19). Music can beentered into Denemo using a MIDI device or even the pitch deduced from audio samplesfrom an audio input/microphone [Shann and Mehl, 2009].

Denemo’s embedded LilyPond view with an editing layer built on top is similar to thesuggestion that was raised earlier (Section 2.5.4.2 on page 16) regarding building a layer ontop of a non-editable view. Through personal testing, Denemo appears to have executedthis very well. The amount of work involved in modifying this to work with Anton, how-ever, would be substantial because the differences in features between Denemo and Antonwould necessitate many changes.

18

2.6. SUMMARY CHAPTER 2. LITERATURE SURVEY

2.5.6 LilyPond

LilyPond is a very popular open-source music engraving package, like MusiXTEX. However,unlike typesetting with some other TEX-based solutions, LilyPond determines the necessaryspacing to avoid collisions [Nienhuys and Nieuwenhuizen, 2003]. The LilyPond project con-centrates on producing very high quality musical notation. Certainly, the sample outputfrom LilyPond is very impressive. The team spent a lot of time designing the font, “Feta”,which is used by LilyPond to generate its output. LilyPond has been well accepted into theopen-source community and Rosegarden, Canorus, Denemo (among others) can all outputfiles in LilyPond input format16. Anton is also able to export completed compositions inLilyPond format.

Again, like MusiXTEX, LilyPond is designed to produce postscript compatible files (viaLATEX). For the same reasons as mentioned in Section 2.5.3 (on page 15), this is not aparticularly easy way to display (potentially) interactive music notation within a third-party application. Denemo (Section 2.5.5.2 on page 18) has shown us that it is possible todevelop a user interface based on this premise, but it is certainly not trivial.

It is also possible to override LilyPond’s default behaviour using the inbuilt Scheme in-terpreter. This approach seems more sensible than that taken by MusiXTEX. LilyPondexcels by incorporating the use of sensible (and well researched) defaults, but also allowingthe user to override certain parameters where necessary. This leads to LilyPond being easyto use, but still incredibly powerful.

2.6 Summary

Throughout this literature survey, a number of different, relevant areas were looked at.In order to give some background to the music rules used in Anton, an introduction toAnswer Set Programming was presented. Looking at the basic concepts underpinning ASPcombined with the existing Anton papers made the role of the AnsProlog* rules in Antonclearer. This information was also key to helping determine how Anton may be extendedin future to adopt different styles of music and how a graphical user interface may need toadapt to this. The research showed that incorporating style creation/management featureswould be non-trivial and that it was impractical to look to implement this within theallocated time.

After researching ASP, some of the existing Anton papers were reviewed. The discussionaround a couple of Anton’s more unique features made it clear that making such usefulfeatures available to musicians would be highly beneficial to the project. Reviewing theAnton papers reiterated how useful the project is in its original form and highlighted thereal need to extend it, making it available to a wider cross-section of people.

16http://lilypond.org/about/features

19

http://lilypond.org/about/features

2.6. SUMMARY CHAPTER 2. LITERATURE SURVEY

It was decided that the work of existing logic-based composition methods should be ex-amined, in the hope that they may provide some development “good practices” alongsidepotential areas for improvement. Various methods were looked at chronologically, start-ing with a pre-computer example: Mozart’s “Musikalisches Wurfelspiel”. This work, eventhough it predates computers, was still found to be relevant as parallels could be drawnto modern day systems that claim to perform the same task. It was interesting that suchdice games were, in effect, accessible to anyone, regardless of their musical ability. Manymodern day systems, “Band in the Box” etc, also target this same, general market. Theresultant user interface in Anton will largely determine who the target audience could be,so a lot can be learnt by studying user interface techniques utilised in such systems. Thework of Ebcioglu and Anders was also considered. What was particularly notable aboutboth solutions was that no particular attempt to broaden the user base was found in anyof the research. It simply showed that many of our aims for Anton cover new ground, thisis why it has been particularly difficult to find relevant material in this space.

Having looked at some of the musical pre-cursors to Anton, some consideration was givento existing open-source technologies. These technologies were viewed with an aim of po-tentially reusing some of their functionality in the implementation of Anton. What wasparticularly surprising was the lack of scoring libraries available. Considering the preva-lence of such interfaces within music software, it is a shame that there is such a lack ofchoice. That being said, some of the solutions that are available appear to be outstanding.The technology that seems most relevant, all research taken into account, is the GUIDOLiblibrary. GUIDOLib seems to be the most fit for purpose as it was developed specifically foruse cases such as Anton. Having completed a fairly comprehensive search of appropriatetechnologies, it is fair to say that the implementation will use, or at least consider the useof many of the technologies that were mentioned. Some of the projects mentioned, such asMusiXTEX were incredibly powerful, but fairly difficult to reuse as they were not designedto be used as software development components. The RtMIDI library used by Canorusmay also come in use as it would be desirable to add some kind of MIDI playback facility(if not input). The use of the MVC paradigm within the Canorus project was also notableand something that Anton might be able to benefit from too.

The researched materials have definitely contributed positively to the roadmap for thisproject. Informed decisions about implementation choices can now be made, based on pub-lished information. It has also provided an opportunity to think about potential boundariesfor the project as the implementation of all of the desired features is clearly not practicalin the time given. Much of this analysis will be used at key points in the project withreference to the findings in this Literature Survey.

20

Chapter 3

Project Management

3.1 Project Methodology

The project was conducted using an iterative development approach, rather than the tradi-tional waterfall model. An iterative methodology allowed for decomposition of the projectinto smaller “iterations”. The strict waterfall model is too inflexible for fast-changingprojects such as this. As Anton itself was being developed in parallel with this graphicaluser interface, an iterative model allowed the GUI to be readily adapted alongside newreleases of Anton, implementing new features. This approach is often described as “AgileSoftware Development” due to the flexibility that it affords the developers and stakeholdersof the system. Unlike a truly agile approach, more attention was paid to the documentationto ensure that all choices and changes were effectively communicated.

The work effort for an iterative project is based on a “Project Control List”. The “ProjectControl List” for this project is explained in the “Requirement Gathering” overview (seeSection 3.2.1 on page 22). Rather than allowing one attempt at getting the requirement,design and implementation phases correct, the iterative approach means that each iterativestep is decomposed into smaller requirement, design, implementation and testing sections.Instead of stipulating what features will be present in each iterative step, the feature-setof the iteration is dictated by what is achievable with the amount of time given to eachiteration.

It was hoped that the selection of this methodology would allow a large feature set tobe completed in the given time and that the goals could be continuously ratified with thestakeholders. Another benefit of this methodology is it also encourages continual testing,which generally leads to a higher quality product.

21

3.2. REQUIREMENTS CHAPTER 3. PROJECT MANAGEMENT

3.2 Requirements

3.2.1 Requirements Gathering

As a software project rather than a purely research based project, a majority of the require-ments were dictated or heavily influenced by the key stakeholders of the system. This waspositively encouraged through the selection of the iterative design approach. In order tostart collecting requirements for the first iteration, a meeting was held with the developerand academics who were involved in the original Anton project. As the project had a veryminimal user base, a meeting made more sense than distributing a survey. A survey wouldhave been difficult to conduct, because many musicians and ordinary computer users willnever have seen (and certainly not have used) a package like Anton.

In addition to gathering requirements, the meeting was used to try and determine the scopeof the project. Unfortunately there was not time to implement all of the desired features forthe system, thus it was important to “ring-fence” the requirements through a prioritisationprocess to ensure that the critical requirements were not missed. The prioritisation processwas performed by noting down which parts were considered key features by the stakeholders.Conflicts in the prioritisation process were raised with the relevant stakeholders. Therequirements were split into two sections: functional and non-functional requirements. Allattempts were made to ensure that every individual requirement adhered to the S.M.A.R.T1

requirement principle. Writing requirements in this fashion made it easier to verify whenthey had been met.

3.2.2 Project Control List (Project Scope)

The iterative development methodology represents project scope using a “Project Con-trol List”. The list was used to document the features that had to be implemented forthe completed system. The list was altered during the development phase with inputfrom stakeholders, after reviewing the previous iterative step. Many high-profile softwareprojects fail due to scope creep and other scope related issues. To prevent this from happen-ing, any feature that was outside of this list was not implemented unless time allowed for it.

The suggested deliverables were ascertained through further decomposition of the require-ments. The appropriate requirement pertaining to each deliverable is referenced in eachcase. Requirements were introduced into later iterations by adding the new requirementsinto the project control list for the next iteration. The project was only considered com-pleted when all of the milestones within the control list had been implemented.

1Specific, Measurable, Achievable, Realistic and Timely

22

Chapter 4

Iteration I

4.1 Requirements

The requirements were taken from the initial meeting with the project stakeholders. Aspreviously mentioned, efforts were made to ensure that the requirements adhere as closelyas possible to the S.M.A.R.T requirement principles (Section 3.2.1 on page 22). The successof the requirements was measured by suggesting various tests that prove that the featureswork.

4.1.1 Functional Requirements

4.1.1.1 Allow creation of new Anton pieces based upon existing styles

Description It must be possible to produce new compositions, providing all of the optionsthat are present in the command-line version of Anton. Allow users to select stylesfrom the list of inbuilt styles.

Output The piece should be created by Anton and presented in the graphical user inter-face.

Possible Tests Possible tests will ensure that this requirement has been achieved include:

• Ensure that the pieces are represented properly in the graphical user interface.

– Make sure that the number of parts is consistent between the output pieceand what is displayed in the graphical user interface.

– Ensure that the notes match (same pitch and rhythm) in the graphical userinterface and the output from the Anton script.

– Run diagnose on the generated piece and ensure that it is considered validfor the applicable style.

23

4.1. REQUIREMENTS CHAPTER 4. ITERATION I

Source From the initial meeting.

Priority High

4.1.1.2 Allow the import of existing Anton pieces

Warning This requirement is not specific as it relies on details that were undecided beforethe implementation phase.

Description Existing pieces generated by Anton (in the examples folder of the Antondistribution and newly produced pieces from the GUI version), should all be openablewithin Anton. The platform that the piece was created on should be irrelevant.

Output Existing scores must be able to be opened within Anton, causing the GraphicalUser Interface to resume the state of the saved score.


• Visual check that after opening a score, all visible settings are retained.

• Ensure that no errors or state inconsistency is experienced after attempting toload a previously saved score.

• If specific settings are missing from a save file, these should be supplemented(wherever possible) with sensible defaults.

Source Developer. In order to have any use, the program must be able to save / restorestate. A composer cannot consistently be expected to complete compositions in onesitting, without wanting to close down Anton.

Priority High

4.1.1.3 Provide a musical score view

Description It should be possible to see the content of the different parts in classicalmusic representation. The chosen classical musical representation is the standardmusic score. As well as seeing the parts individually, it would be useful to be able tosee the piece in its entirety in the score view.

Output A window should be provided which displays the graphical representation of theselected part(s).


• The provided score viewer must display results consistent with the Lilypondoutput. Should any part of the Lilypond export be buggy (as touched uponwithin the Anton README file), it must be proved that the newly developedview results are actually correct, in contrast with the Lilypond export.

24


• The displayed score must be consistent with the selected part(s) within thegraphical user interface at all times.

Source From the initial meeting. The desire was expressed that the parts would be view-able using some form of classical music notation.

Priority High

4.1.1.4 Diagnosis feature

Description During the editing of a piece, it should be possible to click a button whichruns Anton’s “Diagnosis” facility to check that the input piece is valid. The currentstate of the piece should be serialised at this point and passed to the Anton scriptsto validate. It is important that the state of the Graphical User Interface (the score/ note data) not be allowed to change during the diagnosis procedure, otherwise thediagnosis output may be inconsistent with the updated state of the score.

Output Visual feedback should be presented to the user to indicate whether the piece isvalid or not. This could be in a label within the user interface or with a popup dialog.It should be possible to obtain the list of errors, as provided by Anton.


• The diagnosis from the GUI version of Anton must always be consistent withthat of command-line Anton.

• The “serialised” version of the score must be a completely accurate representa-tion of the score within the user interface.

• The return value from the Anton script must be tested with multiple examplesto ensure that the correct state is represented within the graphical user interface.

• The list of diagnosis errors should be consistent within the GUI interface andthe command line version.

Source From the initial meeting. As the diagnosis feature is one of the usage switches forAnton, it is desired that all of these options should be available from the GUI.

Priority High

4.1.1.5 Input musical snippets

Description It should be possible to append new musical material to existing fragmentsusing MIDI controller input.

Output An existing fragment should be extended with the new musical information fromthe MIDI controller.

25



• Test that notes played on a MIDI controller are accurately detected within theapplication.

Source From the initial meeting. The desire to allow input and rearrangement of musicalfragments was expressed, although it was not stipulated as a high requirement.

Priority Low

4.1.1.6 Composition buffer

Warning This requirement is not specific as it relies on details that were undecided beforethe implementation phase.

Description In order to provide some notion of “non-destructive editing”, it is desirablethat the state of the score can be “snapshotted” before certain destructive operationstake place so that the full state of the piece may easily be restored at a later point intime.

Output A list of entries within the Composition Buffer should be present within the GUI.Upon selecting a previous state, it should be restored.


• Scores are correctly persisted at the pre-determined points.

• The user is able to restore any previous score in its entirety.

• When restoring a previous score, the current score state is also persisted.

• If the current score matches a previous score within the composition buffer, it isnot persisted - rather a new entry is made which aliases the previous, equivalentcomposition.

• Entries should be able to be purged from the saved data. Purged entries shouldnot reappear after they have been purged.

Source Developer. As Anton can produce random results by passing different seeds tothe solver, it is conceivable that the composer may want to try several differentvariations before settling on one. As such, being able to move backwards and forththrough different possibilities may prove useful.

Priority Low

4.1.1.7 Compose with snippets

Description Anton has the ability to complete previously incomplete pieces. This featureshould be exposed within the Graphical User Interface.

26


Output A button should be provided that allows any piece to be passed to the composetask. The piece will then be used as a basis for a new, musically-complete composition.


• A piece with some measures removed should be replaced with a completed piece.

• The current piece should be saved within the current “Composition Buffer”before it is passed to the relevant Anton script. It should be possible to restorethe entire state of the piece before the “Compose” task was called.

• An already “completed” piece will be replaced by itself.


Priority Medium

4.1.2 Non-functional Requirements

4.1.2.1 Extendible architecture

Description Design the system in such a way that writing extensions would be trivial.

Method Discuss the chosen architecture in the Design phase. Ensure that core systemcomponents are developed with the same “extension” architecture, so that this facilitywill have been tested fully.


Priority Medium

4.1.2.2 Portable code

Description Conduct the development using languages / frameworks that allow cross-platform solutions to be developed from the same codebase. The ability to be ableto port parts of the project to a mobile device would also be beneficial.

Output At each iteration, a build should be made for Windows, a Linux distribution(Ubuntu 9.10) and Mac OS X. The testing should be carried out on each platform toensure consistency.


Priority High

27

4.2. CONFLICTS CHAPTER 4. ITERATION I

4.1.2.3 Developed using free / open-source software

Description Conduct the development using languages / frameworks that are free / open-source software wherever possible.


Priority Medium

4.2 Conflicts

During the course of the discussion, a couple of conflicts arose. The first issue that wasraised was the possibility of having some kind of “New Style Generator”. This, as men-tioned in the Introduction section, would certainly lead to a much wider use of the system.Unfortunately there were many difficult, unanswered questions surrounding the creationof such a new interface. In addition, no reference to any similar, existing interface couldbe found in any of the preliminary research. As such, the time that would be required toresearch and implement such a custom interface design would be extensive. Additionallyas such a deep knowledge of music is required to be able to develop styles, it may even beimpossible to develop a basic, universally accessible interface to do this. The syntax usedto define the rules does not really introduce any additional complexity for someone whounderstands the semantics. The benefits of providing a complex rule definition interfacefor expert users who can already write styles would be minimal.

During the course of the first iteration, the possibility of implementing rhythm (a newfeature in the recently released Anton 2.0) was considered. Sadly the implementation ofrhythm would have caused several complications including the requirement of being ableto support and parse the new, slightly different file format, rendering the correct durationsand time signatures in GUIDO and many others. While the decision to not implementthese features was taken fairly early on, thought was continually given to this as a poten-tial avenue for future work. To this end, support was added to take rhythm into accountwherever possible in the code.

4.3 Project Control List (Scope)

The project control list is a list of features/milestones that will be implemented in the com-pleted system. As each iteration was short (between 7-10 days), only a small subset of theitems within the project list was completed during each iterative step. The order that thefeatures are written in are the order that they were implemented in. The ordering was donein this way to ensure that any dependencies between requirements were taken into account.

1. New composition wizard (from Requirement 4.1.1.1)

28

4.3. PROJECT CONTROL LIST (SCOPE) CHAPTER 4. ITERATION I

2. Import existing score feature (from Requirement 4.1.1.2)

3. “Arranger View” to show separate parts (from Requirement 4.1.1.1)

4. Music score editor window (from Requirement 4.1.1.3)

5. Diagnose piece button and code (from Requirement 4.1.1.4)

6. Diagnosis results list (from Requirement 4.1.1.4)

7. Ability to have multiple fragments (musical snippets) per part (from Requirement4.1.1.5)

8. Complete piece button and code (from Requirement 4.1.1.7)

9. Serialisation feature (allowing for future data to be saved / queried from the file)(from Requirement 4.1.1.2)

10. Composition buffer list (from Requirement 4.1.1.6)

11. Ability to purge entries in composition buffer (from Requirement 4.1.1.6)

12. Ability to alias equivalent compositions in buffer (from Requirement 4.1.1.6)

13. Ability to deduce whether current score is equivalent to one already in the buffer(from Requirement 4.1.1.6)

14. MIDI input feature (from Requirement 4.1.1.5)

29

4.4. DESIGN CHAPTER 4. ITERATION I

4.4 Design

4.4.1 Introduction

This section discusses the chosen solutions behind some of the main design challenges thatwere encountered in the planning of the first iteration. All decisions at this stage weretaken without prior knowledge of the choices that were made at the implementation stage.

4.4.2 Working with the Anton Scripts

When deciding upon the ideal architecture for the system, a major design decision had tobe made. There were three potential methods that could have been selected to wrap thefunctionality of the existing command line Anton scripts.

1. Shell the required processes, relying on the host system’s Perl interpreter

2. Link the graphical user interface with a Perl interpreter

3. Rewrite the scripts in the implementation language

While point 2 would have allowed Anton to be downloaded and used immediately, evenon systems without Perl installed, it would have complicated the build process too muchfor the benefits it would have brought. One particular benefit of bundling Perl with thebinaries would have been that a consistent implementation of Perl would have been usedacross platforms. Having users use the same version of Perl as Anton was originally testedwith would have made unexpected errors less likely to occur. On the other hand, the Antonbundled version of Perl might not have been as optimised as an existing Perl interpreterbuilt specifically for that user’s machine.

Rewriting the scripts (point 3) would have been possible, but would have required a muchdeeper understanding of the original scripts. Rewriting the scripts would have also taken avery long time and meant that there would be two versions to maintain (the original Perlversion and the rewritten version).

The selected approach was to shell Anton’s processes to an existing Perl interpreter (point1 in the list). This choice has several advantages that come from the loose coupling be-tween the user interface and the scripts. Firstly, it allows the graphical user interface toeasily switch between different underlying versions of Anton and Perl, which in both casesmay yield performance and feature related benefits. Additionally it will not cause a “fork-ing” of the Anton codebase, where two separate versions of the Anton scripts need to bemaintained.

A disadvantage of the chosen approach is that it places the burden of installing pre-requisitesoftware on the user. While this is not an issue on Unix based systems (Linux / Mac OSX) which often come bundled with a standard Perl interpreter, it is an issue for Windows

30


users. By packaging a Perl interpreter with the final Windows installer, any concerns withthis approach could be alleviated.

4.4.3 Score Representation

While the Graphical User Interface is being used to work with a score, it is necessary tohold some kind of representation of the score in memory. This in-memory representationwill be transformed using the output from the various Anton processes. For instance, if theuser chooses to “Regenerate” a piece of music, it is the in-memory representation that willbe updated using the musical information given as output from the regeneration script.

Having a memory-based representation makes sense, but it is not immediately clear whatthe best format for this data is. While the data could easily be stored in the same textformat as is present in the original score files (an example is given in Appendix C.1 onpage 78), this is certainly not convenient. In order to hook up graphical user interfaceelements to parts of the data, the input file would have to be continually parsed to locatethe relevant information. Also writing changes back to arbitrary locations within the scorecould involve relatively expensive traversals of the text file.

To solve this problem, the various sections of a musical score (parts, notes, musical phrases)were split into objects. Objects provide a natural way of representing nested informationthrough the use of parent / child links. One could easily identify possible nested layersthat might exist within a score (Score, Parts within the Score, Notes within Parts, etc).

The final structure that was decided upon is as follows:

Score The Score object encompasses all of the other objects. It stores properties whichare unique to the score, such as the number of parts within the piece, the mode of thescore, the style and any title/composer that should be displayed in the score viewer.

FragmentListModel The FragmentListModel is synonymous with the musical terms“Part” or “Voice”. If a piece is composed as a quartet, there will be exactly 4 Frag-mentListModel objects within the Score. The properties stored at this level includethe type of clef that is used in the staves for this FragmentListModel (treble, alto,tenor, bass clefs), the track name, the number of the track, etc. The FragmentList-Model is so-called because it is essentially an ordered list of FragmentModels thatconstitute the musical content for one voice.

FragmentModel The FragmentModel groups together a contiguous set of notes. Thisis a useful level of abstraction to have, because it allows a group of notes to beoperated on at the same time. It is also something that can be seen in other musicapplications. Features like Autofill do not really make sense for a single note, butseveral contiguous notes - so the FragmentModel makes this easy to accomplish. Thesole property of the FragmentModel is its offset - this dictates its position within theparent FragmentListModel.

31


Note A Note is the smallest level of granularity within a Score. Each note has a pitchassociated with it and duration (ready for supporting Anton version 2.0).

An alternative idea was to have a similar decomposition, but to make the objects graphicalwidgets instead of models, combining both the data and graphical representations into oneobject. While this would have worked, separating the view and data layers into separateobjects, called the Model-View-Controller (MVC) pattern, does afford many benefits. Inparticular, the model data can be attached to multiple view representations, each display-ing a slightly different view. Another very useful attribute of classes that are designed tothe MVC pattern is that all painting and “business logic” concerns are separated.

In Anton, the use of the MVC pattern has allowed the model classes to remain verylightweight and totally focussed on musical properties. Similarly the view controls (notmentioned in detail here) are completely focussed on the necessary code to style and drawthe representations of the data within attached models. The idea for this approach camefrom the researched material on the Canorus project (Section 2.5.4.3 on page 17). Onedisadvantage is the requirement to have a controller that is in charge of keeping the modeland view layers in sync, however many of the frameworks that were discussed in the Liter-ature Survey have event raising mechanisms that would allow the propagation of messagesto instruct attached views that the underlying data has changed.

Appendix D.2 (on page 82) illustrates the mapping between musical elements of a score tothe object decomposition that was described earlier.

4.4.4 User Interface

The User Interface (UI) was designed by looking at music applications such as GarageBand,Logic Studio, Audacity and ProTools. As pieces in Anton consist of multiple parts, thedesign patterns in other music applications which support multiple tracks are also applicableto Anton. The track arranger and score views are features that will be instantly recognisableto musicians who have used any of the major computer music applications.

The views are designed to be “dockable” into the main window. This will help users toorganise Anton the way they want it to look, rather than being forced into an inflexible,developer-provided layout.

The designs can be found in Appendix A.1 (on page 69).

32

4.5. IMPLEMENTATION CHAPTER 4. ITERATION I

4.5 Implementation

4.5.1 Language

The choice of implementation language has been restricted by some of the informationthat was found out during the Literature Survey and the choices made at the design stage.During the design phase it was shown that representing scores using an object-orientedapproach would be beneficial (Section 4.4.3 on page 31). As such, it narrowed the poten-tial implementation language to one which supports object-oriented development. Anotherlarge concern was the availability of pre-existing music scoring libraries. Out of all of theoptions that were discussed in the literature survey, the main library that seemed promis-ing was GUIDOLib (Section 2.5.4.2 on page 16). To support native scoring, the GUIDOteam recommended the use of their Qt libraries. For these reasons, it was decided that theproject would be implemented in C++ using the Qt framework to provide GUI classes andcross-platform compatibility.

As well as being able to access the existing work from the GUIDOLib project, an ad-ditional advantage of selecting Qt/C++ was that the MVC pattern can be implementedelegantly through the use of Qt’s slots / signals mechanism. An object is able to declarespecial methods, which are called slots. Slots can be “bound to” and are invoked auto-matically when a particular event occurs. The events that cause a slot to be invoked areknown as signals. The signals that are emitted by an object are also declared in the object’sheader file. After the definition of a slot and a signal, a connection can be made betweena particular slot and signal so that the slot is invoked when the signal is emitted. Multipleslots can be assigned to a single signal, which allows for objects to easily subscribe to eventsthat they are interested in. This loose coupling makes MVC particularly easy to achieve,by emitting signals which inform the view that the underlying data model has been markedas “dirty” (i.e. the state of the model has changed).

In addition to the many advantages that came from choosing Qt/C++, there were alsoa few disadvantages. The first disadvantage was that developer had no prior exposure toQt and very limited experience with C++. While this point was deliberated, it was decidedthat the quality of the Qt-provided documentation and books was such that the learningcurve could be overcome. Another disadvantage was that the underlying language of C++is still machine dependent at its core. While Qt is able to mask many of the differencesbetween different system architectures, this did create unexpected issues during the build-ing and deployment of the finished system. These issues will be explained in greater depthlater in the project (Section 6.4.1 on page 58). This is mentioned because the choice ofother more cross-platform oriented languages, such as Java, would have mitigated many ofthese concerns.

The Qt provided QtCreator IDE1 was used throughout the implementation of this project.1Integrated Development Environment

33


4.5.2 Extensibility

In line with Requirement 4.1.2.1 (on page 27), it was requested that the architecture ofthe user interface should be extendible. To satisfy this requirement and avoid writing lotsof repetitive code, two specific libraries were developed for implementing some of the coreuser interface features. These libraries were created after two specific, repetitive patternswere noticed in the requirements:

1. The need to run potentially long-running tasks. This includes the following list ofAnton tasks and the associated work that is done by the answer set grounder (gringo)and solver (clasp).

• The new composition procedure - generates a new composition based on usersupplied parameters

• The score autofill procedure - fills in blank portions of the score

• The score diagnosis procedure - finds errors that are present in the score

2. The need to provide an interface to the user to select options when running tasks.

To satisfy these requirements the Task and Workflow frameworks were designed.

4.5.2.1 Task Framework

A common thread noticed in the Design phase was that many “tasks” were being launched,the Anton scripts, clasp and gringo. These tasks are also not necessarily discrete, but theinput / output from previous tasks is often required in order to complete the next task.With this in mind, a Task Framework was created whose purpose is to allow potentiallylengthy units of work to be invoked and connected together in a chain (where necessary).While the original use-case is mainly process oriented (invoking scripts and executables),the Task Framework provides an abstract base class Task which can be extended to anytype of required task. The support for invoking processes is provided by a custom subclassProcessTask (Section 4.5.2.2 on page 35).

The Task framework supplies a special container class TaskList into which multiple Taskobjects can be loaded. After the tasks have been loaded, the TaskList can be instructedto start the execution of the tasks. The task execution occurs in a separate worker thread,ensuring that the graphical user interface thread remains responsive during the potentiallylong-running task. A modal dialog reports the current task that is being executed with adescription that is customisable by the developer.

The Task superclass also provides a simple error catching mechanism where the devel-oper can flag that an error has occurred and set a relevant description of the error. Beforemoving to the execution of the next task, the TaskList will check whether the previous

34


task completed successfully. If any errors have occurred, the remainder of the tasks will becancelled.

The composition, diagnosis and “auto-fill” (referred to as “Regenerate Fragment” in theUser Interface) features all use the Task framework internally.

4.5.2.2 Process Spawning

All of the interaction with Anton happens through the execution of scripts - thus beingable to invoke these processes reliably and access the output are critical priorities. The Qtlibrary provides a QProcess class which is able to invoke processes, pass parameters andcapture output. Rather than creating a series of QProcess objects and connecting inputsand outputs, it was decided that processes should easily have access to information sourcedfrom the Workflow and Task frameworks. To implement this feature, a custom subclass ofTask was written called ProcessTask, allowing processes to be executed in concert withother tasks.

Wrapping QProcess has made interaction between processes easier to achieve, as it pre-vents the developer from having to manually instantiate multiple QProcess objects, setvarious common properties and handle the results of the final process. The concern ofhow processes are connected together is abstracted away from the developer, as the Taskframework deals with this instead. Using ProcessTask instead of QProcess saves a lot ofcode duplication and makes QProcess more friendly to the Task ecosystem.

4.5.2.3 Workflow Framework

The Workflow framework is a light-weight layer on top of Qt’s QWizard class. It providesa way of displaying a wizard style interface without forcing the developer to manually addgraphical widgets into the QWizard. The framework makes it easy to populate the fieldsand also retrieve the values that were set when the Wizard is closed.

The wizards are meant to be linear processes, rather than having steps that are depen-dent on the user input.

The main benefit of using the Workflow framework as opposed to QWizard directly, isthat it integrates with the Task framework (Section 4.5.2.1 on page 34). The frameworkconsists of three different parts:

WorkflowAttribute A WorkflowAttribute object constitutes a single parameter thatcan be set in a WorkflowWizard. WorkflowAttribute supports various control types- such text fields, spinner fields and combo boxes. For combo box fields, it is pos-sible to set the valid choices (and underlying data values). Spinner fields can have

35


maximum / minimum values set. If the Workflow is integrated with the Task frame-work, the developer can set which Task objects are interested in the value of thisWorkflowAttribute field.

WorkflowStage The purpose of a WorkflowStage is to group together all of the relatedWorkflowAttribute objects that should appear on a single screen of the wizard. Itallows a title and subtitle to be set for each stage. Each WorkflowStage holds areference to the WorkflowStage that should follow the current stage.

WorkflowWizard WorkflowWizard is the widget that is displayed to the user. It buildsthe necessary wizard pages from the attached WorkflowStage definitions. It alsomanages the transition between different stages, ensuring that they are built andshown in the correct order.

After the wizard has been completed, if a TaskList (Section 4.5.2.1 on page 34) has beenassociated with the WorkflowWizard then this will be invoked. A map between tasks andselected parameters is returned from the completed WorkflowWizard. The TaskList thendistributes the correct parameters to the relevant Task objects.

4.5.3 GUIDO Conversion

The previously designed in-memory score representation solves the problem of how musicis represented internally within Anton. However, the requirement of being able to displaymusic in a score (Requirement 4.1.1.3) means that the internal score representation hasto be accessible to the score components provided by GUIDOLib. The main input for-mat supported by the QGuidoWidget component is a string / file containing GUIDO musicnotation. As such, routines had to be created that provided the interface between theapplication and the score viewing components.

In order to facilitate this conversion, the GUIDOConverter class was created which is able toaccept objects from different levels within our music hierarchy (Score, FragmentListModel,FragmentModel) and convert these to the relevant GUIDO statements. The conversionprocess breaks down the Score/FragmentListModel/FragmentModel into individual notesand converts each in turn to generate the string in GUIDO format.

Some optimisations are made during the conversion, octave changes are written out onlyonce, in the places where they occur, instead of specifying the octave for each note. Ad-ditionally, if a part has not been given a specific clef type, it defaults to ClefType::Auto.This special ClefType is used to indicate to GUIDOConverter that it should calculate themost likely clef to use for this part. The calculation for this is quite simple, the averageoctave over the whole part is taken. If the average octave is less than 0.5 then the bass clefis selected, otherwise the treble clef is used. This figure was selected after generating manyrandom pieces and adjusting the average figure as necessary until all of the subsequentscores that were generated were given a sensibly chosen automatic clef type.

36


4.5.4 Score Conversion

Routines are provided to facilitate the conversion between the existing Anton score formatand the new “native” score format. This section discusses the conversion method employedby each conversion process.

4.5.4.1 Answer Set Score → Native Score Format

This conversion is provided by the initialize method on a Score object. It uses regularexpressions to match the notes in the supplied answer set score. Figure 4.1 shows how anote in Anton answer set format is parsed using the supplied regular expression. Antonrepresents notes in the format: choosenNote(PART, TIME, PITCH), where PART is the partnumber. A solo only has one part, while a duet has two, etc. TIME indicates the note’sordering in the part, so the first note in a part is numbered 1. The PITCH value representsthe musical pitch of the note, in other words how high or low the frequency of the note is.

(choosenNote$([0-9]+),([0-9]+),([0-9]+)$) → choosenNote(4,17,22).

→ Part = 4, Time = 17, Pitch = 22

Figure 4.1: Reading an answer set score

The regular expression is used to extract the part, time and pitch values from the expres-sion. In Figure 4.1, the current note belongs to part 4. While parsing this statement,the conversion routine will create a FragmentListModel for part 4 or use an existing Frag-mentListModel for part 4, if it has already been created. As it is impossible to representmultiple musical fragments per part in the old Anton format, all of the notes are just putinto a single fragment that starts at the beginning of the part. If a Fragment already existswithin the current FragmentListModel, the note is appended onto the end of this Fragment,otherwise a new Fragment is created. A new Note is instantiated with the supplied pitchnumber. Because rhythm was not implemented in this iteration, the default duration of4 is passed (this represents a crotchet / quarter note). This process continues inside of aloop until the regular expression matches no further note definitions.

One issue with this approach is that it currently discards the time parameter (the sec-ond parameter). It simply assumes that the Notes are correctly ordered within the inputfile. As no specification of the input file format exists, it is not safe to assume that noteswill always appear contiguously within the file. As such, it would be better to refactor thecode to place all of the generated notes into a sorted buffer using the time parameter asthe sorting key. The notes could then be read from the buffer and added to the Fragment,knowing that they are in the correct, sorted order.

37


This method is also limited to just reading choosenNote expressions (i.e note definitions)at present, if the input file format became any more complicated, the parsing method wouldneed to be rewritten to support reading more expressions.

4.5.4.2 Native Score Format → Answer Set Score

The code that performs the conversion from Native Score to Answer Set score format iswithin the ASConverter (Answer Set Converter) class. Like GUIDOConverter, it supportsthe conversion of entire Score objects, FragmentListModels or simply FragmentModels.A description of the different conversion options are provided below:

Converting a Score The method writes out the mode(X)., style(X). and score length(#const t=X.) statements into a string. These are present in every score file. Thefirst fact declares the mode of the score, the second defines the style of the piece andthe third denotes the total length of the piece (number of notes). After recording thisinformation, it then appends the output of the “Converting a FragmentModelList”procedure below, passing the FragmentListModels within the Score as input.

Converting a FragmentListModel When converting a FragmentListModel, the partnumber is written out in the format part(X)., as is present in all of the suppliedexample scores. All of the child FragmentModel objects are traversed and each oneis subjected to the “Converting a FragmentModel” process mentioned below. Thereturned string is appended into the output. Because support has not yet beenenabled for multiple parts, there is no logic here to determine the spacing that shouldbe present (if any) between FragmentModels (i.e. musical rests).

Converting a FragmentModel Given a FragmentModel, ASConverter will iterate overthe notes within the fragment and extract the part, time and pitch information foreach one. These are written out in the format: choosenNote(part,time,pitch).

4.5.5 Score Composition Workflow

A class called ComposeWorkflow was created to allow the user to create new compositions.It provides a wizard-based interface, using the Workflow framework, to ask all the relevantparameters that are required for the composition task. The workflow contains 4 tasks thatfacilitate composition:

composeTask → gringoTask → claspTask → parseTask

Figure 4.2: ComposeWorkflow - Constituent tasks

composeTask The composeTask spawns programBuilder.pl passing in the values thatwere set by the user within the wizard. The programBuilder.pl script will generate

38


an answer set program that can compose an output piece conforming to the specifiedparameters.

gringoTask The answer set program that was built by composeTask is passed to gringo-Task in order to be ground.

claspTask The ground program generated by gringoTask is passed to claspTask in orderto find the answer sets. Clasp will generate one solution, which will be a validcomposition.

parseTask This task spawns parse.pl which will take the output provided by claspTaskand return a version of the score with any extraneous standard output informationremoved. The output from parseTask can be read by Anton as an input file. Thespecified transposition and fundamental settings are applied at this stage.

The workflow itself allows the user to select the following settings: the fundamental (startingnote) of the piece, any transposition (±1 octave), the style (quartet, trio, solo, etc.), themode of the piece and the length of the piece. WorkflowAttribute objects are created foreach of these fields and then are organised into two different WorkflowStages.

4.5.6 Diagnosis Task

The Diagnosis task is used to determine whether a given score adheres to rules for agiven style and mode of composition. Initially the current score is exported to answer-set score format, as programBuilder.pl expects this as the input file format. UnfortunatelyprogramBuilder.pl does not accept this file via standard input, so it is saved to a temporaryfile and the temporary filename is passed as a parameter to the script. The DiagnoseTaskclass uses 3 Task objects to diagnose a piece.

diagnoseTask → gringoTask → claspTask

Figure 4.3: DiagnoseTask - Constituent tasks

diagnoseTask The diagnoseTask spawns programBuilder.pl passing in the temporary file-name where an answer set version of the score has been saved. The programBuilder.plscript builds us an answer set program that will list any errors present within thescore.

gringoTask The answer set program that was built by diagnoseTask is passed to gringo-Task in order to be ground.

claspTask The ground program generated by gringoTask is passed to claspTask in orderto find any errors.

39


In comparison to ComposeWorkflow (Section 4.5.5 on page 38) there is no final task (i.e.parse.pl) that interprets the results of the diagnosis. Instead, the output from clasp ispassed directly to Anton for interpretation. If any errors are found, clasp returns these inthe convenient format:

error(part, time, error_description).

Figure 4.4: Rule violation error format

A regular expression is used to extract the information from the errors, in the same wayas depicted in Figure 4.1 (on page 37). If no errors are present in the score, the stringUNSATISFIABLE will be present in the output, because this means that no error predicateswere generated. The presence of the string ‘UNSATISFIABLE’ is first checked for, if it isfound then the input score has no errors, otherwise, a regular expression is used to extractinformation from the error messages. If the regular expression still does not match anystrings (i.e. the score has errors, but they could not be printed or the process failed) thenthe procedure must have terminated with some strange output and the user is instructedof this. The results of the diagnosis, including any detailed error messages (if present), aredisplayed to the user in a modal dialog box.

4.5.7 System Architecture

It is now possible to see the overall design of the system. On the input side, a scoreis loaded from either an existing composition on disk or the material returned by theComposeWorkflow. This loaded score is in Anton’s answer-set score format. A new Score(and associated FragmentListModels, FragmentModels and Notes) can then be createdfrom the converted material (Section 4.5.4 on page 37). The ScoreWindow objects arethen bound to the GUIDO representation of the current Score object that is produced byGUIDOConverter. As the underlying data model in the Score becomes dirty (i.e. musicaldata has changed), GUIDOConverter is called again to take the changes into account.

Anton compose taskinitiated by GUI or command-line (AnsProlog de!nitions)

Composition File

ScoreFragmentListModels

FragmentModelsNotes

Import process

GUIDO converter

Internal representation of music

Modi!cations within the GUI are made at this level

Score view representation of music

The input language of the Score Window controls

Export process

GUIDO formatted string

Score Windows

& E& E& E

mode(major).part(1).choosenNote(1,1,37).choosenNote(1,2,37)...........

[\clef<"g2"> \meter<"4/4"> c2 c b1 a g.. ]

Figure 4.5: System Architecture

40

4.6. TESTING CHAPTER 4. ITERATION I

4.5.8 Source Control

The document and source code were both maintained in private Git repositories hostedon GitHub2. The latest binaries compiled for the target operating systems are also madeavailable through the repository home page. Git was selected because it is now widely usedfor open-source projects, which is in keeping with the spirit of this project.

Git has many advantages over SVN and CVS as a distributed source-control system, asit allows an independent local repository to be maintained separately from the definitivemaster repository (in this case located on GitHub). This is useful for this project as itprovides more resilience by having two separate copies of the repository, either of whichcan be committed into. It also allows for “offline working” without sacrificing the abilityto version files by committing into the local repository. It is then possible to synchronisethe repositories when internet connectivity is restored. These features made it easy towork on the repository safely from different locations such as at University, using a laptopwithout internet connectivity and at home.

4.5.9 Screenshots

Screenshots of the features that were completed for Iteration I can be found in AppendixB.1 (on page 73).

4.6 Testing

4.6.1 Testing Methodology

In order to test that the system works as intended, a series of test cases were created basedon the requirements that were implemented during this iteration. The decision was madeto base the tests on the requirements, as opposed to writing large numbers of unit tests,because the requirements are the best measure of whether the user-facing features workas required. Unit testing is particularly effective for bottom-up testing, because all of themethods can be tested individually to ensure that each method returns the expected valuesfor certain inputs. This means that once methods are combined, one can tell that theaggregate behaviour of these methods is as expected.

Unit testing is, however, very time consuming and the success of this project is basedon larger features, which are verified more easily using a top-down testing approach (i.e.scripted tests). Although this will not give method-level test coverage, it is sufficient toprove that the most important features work correctly.

The test scripts were based upon the suggested tests that were supplied for each requirement(see Requirement 4.1.1.7 for an example). More comprehensive test cases were also created

2http://www.github.com/henrythacker

41


for important pieces of functionality that warranted extra testing.

The test cases were also carried out on each of the target operating systems to ensure thatthe behaviour is consistent between the different platforms. While Qt does solve most ofthe difficulties that come from working on a cross-platform deployment, there are certainthings that are still machine dependent. In particular, the communication with the originalAnton scripts involves the execution of processes. The way in which processes are executedand managed varies a lot between the various target operating systems for this project. Assuch, tests involving process execution received special cross-platform scrutiny during thetesting process.

One disadvantage that was noted surrounding the use of tests scripts was that althoughthe development of the scripts is fairly fast, carrying out manual tests, across multipleplatforms, can be extremely time consuming. It was decided that it was better to stilluse test scripts rather than moving towards unit-level testing, because unit tests requirea significant amount of programming which, in itself, is prone to further potential bugsand errors. Despite the comparative ease of running unit tests, especially across multipleplatforms, it was felt that more would be learnt by having a human observe and conductthe tests. Humans, of course, can observe side effects that the test writer may not haveenvisaged.

The testing was carried out at the end of each iteration, allowing time for any issues to berectified during the following iteration. All of the test cases can be found in Appendix E(on page 85).

4.6.2 Testing Environment

The system was tested in several different environments to ensure that the corroborationof test results was not simply a result of consistent hardware being used throughout thetesting process. The precise testing configurations are listed here for completeness.

Mac OS X The developer’s main laptop was used for testing on the Macintosh platform

• MacBook Pro [MacBookPro3,1] - 2.4 GHz Intel Core 2 Duo

• 4GB RAM

• Mac OS X 10.6.3 (Snow Leopard)

• MacPorts Perl - v5.8.9

• E-MU 1x1 USB Xmidi Controller

Windows A virtualised Windows server instance was rented from Rackspace during thetesting phase

• Virtual quad core processor

• 512MB RAM

42


• Windows Server 2003 SP2 - 32-bit• Strawberry Perl - v5.10.1.1

Linux (Ubuntu) Run in a VirtualBox (3.1.6) virtual machine on the developer’s Mac-Book Pro

• VirtualBox machine image• 1GB dedicated RAM• Ubuntu 9.10 (32-bit)• Perl - v5.10.0

4.6.3 Testing Process

At the end of each iteration, each test case (from Appendix E on page 85) was carried out.Only some of the tests could be carried out at each iteration, because some of the featureswithin the tests were only introduced in later iterations. All applicable tests were run, evenif they had been carried out before. The purpose of re-running tests was to ensure thatnone of the later functionality that was added had broken previously working code. Thisacts as a basic form of regression testing. The tests were carried out on 3 different testingplatforms (listed in Section 4.6.2 on page 42).

The test scripts were read and then carried out, checking for the expected behaviour andany unexpected side-effects. Any discrepancies on the tests were noted. The notes havebeen written up in the “Results Summary” section of each iteration along with any stepsthat were taken to rectify the issues.

4.6.4 Results Summary

The tests for this iteration proved mostly successful. A few problems occurred, most ofwhich were attributable to a single test, as detailed below. All issues that were found withthe underlying Anton scripts were raised with the main developers.

Test 1

1. Issue In some instances, Test 1 would fail because some combinations of pa-rameters within the new composition wizard cause an error to occur. Thisis not a problem within the GUI itself, but a limitation of the underlyingAnton rule files. This error can be recreated by composing a quartet ina mode other than major / minor. The issue is not specifically related tochoosing a mode, because pieces can be composed in other modes when thesolo style is chosen.

Resolution Because this error is caused by a limitation in the Anton rule files,this is not something that can be fixed easily from the GUI. No remedialaction could be taken.

43


2. Issue A problem with the supplied Anton parse.pl script meant that the fun-damental and transposition were not applied at the end of the compositiontask.

Resolution Although this is not an issue with the GUI, a fix was made as itwas a relatively simple perl change. The differences between the patchedand unpatched versions are listed in Appendix F.1 on page 104. The testcases were re-run and the patch definitely fixed the issue.

3. Issue On Windows ProcessTask had an issue invoking the Perl scripts.Resolution Originally the perl scripts were called just by executing the ac-

tual scripts themselves, not via a perl interpreter. This worked withoutissue on Unix-based systems because the scripts were marked executableand the perl interpreter was named using a “shebang”3 at the top of eachscript. As Windows does not natively support these conventions, a morecomprehensive solution was required. As the fix was quite involved, it hadto be prioritised and was subsequently added to the Project Control Listfor Iteration II.

4. Issue After fixing the application of the fundamental and transposition settingsin issue 2 above, it was noted that while the transposition is correctly ap-plied, the inspector never shows the amount of transposition that had beenset in the wizard.

Resolution The issue was attributed to the fact that the (newly patched) An-ton scripts simply apply the transposition but do not pass this informationback to the GUI by notating the selected transposition within the gener-ated score. Modifying the original score format to include this informationwas not an option as it would have potentially caused untold side-effects.It was decided that the issue was a very low priority and that due to timepressures, no remedial action would be taken. The presence of the transpo-sition amount within the GUI is not particularly useful without the abilityto actually apply further transposition, which was never a prioritised issue.

Test 2

1. Issue Uncovered in Test 2, the diagnosis feature does not seem to work withpieces that have the mode parameter set to any other value than major /minor.

Resolution This issue has also been confirmed as a problem with the Antonscripts, rather than the GUI, as the same error occurs from the commandline. No remedial action could be taken.

Test 34

1. Issue When carrying out Test 34, it was noticed that the composition wizardstill continued to work, despite the removal of several critical settings in the

3http://en.wikipedia.org/wiki/Shebang_(Unix)

44

http://en.wikipedia.org/wiki/Shebang_(Unix)

4.7. EVALUATION CHAPTER 4. ITERATION I

Preferences window.Resolution This issue was sorted out as part of the current iteration as it

was very simple. The process locations were being cached locally whenProcessTask instances were first created. To solve this, before starting anyworkflow containing ProcessTask objects, the ProcessTasks were passedupdated process locations to take into account any changes made in thepreferences window.

4.7 Evaluation

The first iteration was instrumental in implementing a lot of the core, critical features andproviding a stable platform upon which the features from Iterations II and III were built.The strict deadline still allowed enough time to implement many of the core functions inthis iteration. Items 1-8 were completed from the Project Control List (Section 4.3 on page28) during the first iteration, which constituted a majority of the project. The enforcementof the iteration deadline was advantageous as it made it easier to focus on the core featuresand prevent scope creep.

The UI design and subsequent implementation set high standards for the remaining itera-tions.

An important decision was taken at the beginning of the first iteration to not implementAnton 2.0 features, such as support for rhythm. The actual implementation of the rhythmfeatures would have taken a long time to carry out and have detracted from the original aimsof the project. While support for the new Anton features was not implemented, variouscritical places within the code have been developed with the features in mind. For instance,the Note object supports the storage of note duration, which would be a pre-requisite forintroducing the rhythm features in the future.

Although several issues were found in the testing phase, a majority of these issues wererelated to Anton rather than the new features within the GUI. Time pressures meant thatthe resolution of one of the test failures was deferred to the next iteration.

45

Chapter 5

Iteration II

5.1 Project Control List

The items on the Project Control List are those which were not completed during the firstiteration. The fixes to enable the execution of perl scripts under Windows, picked up asa problem during the first iteration tests (Section 4.6.4 on page 43), were added to theProject Control List for this iteration.

1. Window perl execution fixes (from the first iteration testing summary, Section 4.6.4)

2. Serialisation feature (allowing for future data to be saved / queried from the file)(from Requirement 4.1.1.2)

3. Composition buffer list (from Requirement 4.1.1.6)

4. Ability to purge entries in composition buffer (from Requirement 4.1.1.6)

5. Ability to alias equivalent compositions in buffer (from Requirement 4.1.1.6)

6. Ability to deduce whether current score is equivalent to one already in the buffer(from Requirement 4.1.1.6)


5.2 Further Design and Implementation

The two main features that were added during this iteration were score serialisation (fromRequirement 4.1.1.2) and the ability to save and restore scores from an in-memory buffer(Requirement 4.1.1.6). A brief discussion of the fixes that were implemented to enable theexecution of perl scripts on Windows is also given.

46

5.2. FURTHER DESIGN AND IMPLEMENTATION CHAPTER 5. ITERATION II



5.2.2 Score Serialisation

Score Serialisation allows the pieces created and modified in the Anton graphical userinterface to be saved and loaded. This means that after a new session of Anton is started,a previously saved piece can be restored from a file on disk. Unlike Java, Qt has no in-built support for serialisation so there were no relevant, existing Qt classes that could beleveraged. This section details the design and implementation choices that were involvedin creating flexible serialisation routines.

5.2.2.1 Serialisation Data

When embarking on a design for a serialisation system, it is important to know whatdata needs to be saved. In Anton, the important data to save are the “properties” of thein-memory score representation objects (Section 4.4.3 on page 31). These properties arepieces of data such as the number of parts in the Score, the pitch of a Note, etc. While itwas easy to decide what data should be stored (Table 5.1 shows the data that was chosenfor serialisation), Requirement 4.1.2.1 specifically stipulates that the architecture shouldbe extendible. Future developers working on this project might want to store additionalinformation into the file format, so these requirements had to be considered during thedesign phase.

Score FragmentListModel FragmentModel NoteTransposition Amount Track Number Fragment Offset Pitch

Number of Parts Track Colour DurationMode Track NameStyle Clef Type

Title of PieceComposer

Table 5.1: Serialised score data

5.2.2.2 Determining What Data to Serialise

Initially the properties to serialise were just stored in private variables, accessed by standardaccessor methods and modified with mutator methods. While this approach works fine if theserialisation process is hardcoded to look at the relevant accessor methods, more flexibilitywas desired. To achieve a little more flexibility, two different options were considered.

47


Method Names To support the serialisation of custom data into the save files, one poten-tial method would be to enforce a naming scheme on accessor functions that providedata that should be serialised. For instance, if a developer wanted to add the dateof composition into the Score object, they could create an accessor method called_getDate. The serialisation procedure could then have looked at all method namesthat are prefixed with _get and called them as part of the serialisation process.

Qt provides the ability to inspect an object and its methods at runtime. This processis known as object introspection (also called reflection in Java). Object introspectionin Qt is possible because the Qt Framework assigns each QObject derivative a specialQMetaObject. This metaobject allows for the introspection of methods, constructors,destructors on its assigned object.

With this option, when serialise() was called for an object, a list of its methodswould be retrieved from its QMetaObject. Each method would be examined to see ifit started with the _get prefix. If so, the relevant method would be called and thevalue would be written out into the file.

The disadvantage of this approach is that it is necessary to name each method inthis special way. It might not be obvious to someone browsing the codebase that the_getMethodName naming convention is related to serialisation, but simply a previousdeveloper’s coding style.

Qt Property System The Qt Framework provides a property system, similar to thatfound in Microsoft C#.NET. Properties are wrappers around private variables whichprovide accessor and/or mutator methods for the variable. Properties essentiallyprovide access these private member variables using just a simple property name. InQt, one registers a property using the syntax seen in Figure 5.1.

Qt allows access to the list of properties, for a given object, through the QMetaObjectsystem. Anton uses these Q_PROPERTY definitions for serialisation as it is almost assimple as just creating a few methods, but it does not force the developer to usespecial naming conventions unlike the first approach that was mentioned. Thus theserialisation method simply retrieves the list of Q_PROPERTY definitions for the objectto serialise and saves the values of all properties into the save file. This makes it easyfor future developers to extend the data that is saved, simply by registering additionalproperties.

48


// Basic Property SyntaxQ_PROPERTY(

PropertyType propertyNameREAD accessorFuncSignature()[WRITE mutatorFuncSig(PropertyType)]

)

// Colour property in FragmentListModel ExampleQ_PROPERTY(QColor colour READ colour() WRITE setColour(QColor));

Figure 5.1: Colour property definition in FragmentListModel

5.2.2.3 File Format

Another consideration was the format that the serialised file would use. Generally serialisedfiles tend to favour the use of proprietary binary formats. These binary files have severalkey advantages over plain text implementations, the major of which tends to be a largespeed increase in reading the files. Some of the other benefits include smaller file sizes andthe fact that users are unlikely to be able to tamper with the contents of the files in atext editor. The main disadvantage comes with the more complex design of the internalstructure of a binary file. If the file will be manipulated using a stream, one needs to setprecise byte boundaries for the different fields in the save file, so the developer knows atwhat offsets particular fields are located at within the file. This is an inherently inflexible,because without clever design, it is difficult to adapt the file structure to introduce newfields without breaking compatibility with previous file format versions.

Despite the shortcomings of using plain text formats (slower read speeds, larger file-sizesand easy editing in a text editor), the flexibility of being able to easily alter the file structurewas the reason that a plain text format was selected.

It was also necessary to choose a file format to use within the body of the plain text file.It was decided that XML would be used with a custom Anton namespace, because Qtprovides good XML parsing libraries as standard.

5.2.2.4 XML Schema

XML files need some concept of structure to determine how data will be stored and readfrom the file. To provide this, all objects that support serialisation have to provide thefollowing two methods:

exportTagName() exportTagName() returns a QString which describes the XML tagname that should be used for serialising objects of this type. The following list detailsthe tag names that are used for the existing serialisable objects.

49


Score Serialises under the “score” XML tag

FragmentListModel Serialises under the “fragment-list” XML tag

FragmentModel Serialises under the “fragment” XML tag

Note Serialises under the “note” XML tag

exportSaveDependencies() exportSaveDependencies() returns a list of QObjects thatshould be saved whenever the current object is serialised. This is useful for storinghierarchies of objects. The XML that is produced by serialising these children isnested within the tag that is created for the current object. This is used throughoutAnton as by its definition the Score hierarchy is naturally represented in this hierar-chical way. The following list details the child dependencies that are returned for theexisting serialisable objects.

Score Returns a list of the FragmentListModel objects for this score as requiredchild dependencies

FragmentListModel Returns a list of the FragmentModel objects for this part asrequired child dependencies

FragmentModel Returns a list of the Notes for this musical fragment as requiredchild dependencies

Note Has no dependent children

The resultant XML that is produced, in conjunction with these schema helper methods,can be seen in Appendix C.2 (on page 79).

5.2.2.5 Deserialisation

The serialisation process successfully writes out object state to XML format on disk, butAnton has to be able to load these files when requested to by the user. The deserialisationprocess is the inverse of the serialisation process and helps to recreate the objects thatwere persisted. Unlike a true serialisation system (such as Java’s implementation), thedeserialisation process in Anton is not able to restore objects completely automatically. InJava it is possible to load the previously serialised file and retrieve the deserialised objectwithout any developer input on the process. Because Anton makes extensive use of Qt’sslot and signals mechanisms to implement MVC behaviour (Section 4.5.1 on page 83), itwould make it difficult for a truly automated deserialisation process to know how to connectthe correct signals back to the correct slots. As a result, the developer has to provide somecode to perform deserialisation, but information is provided to help the developer with thistask.

When a file is deserialised, the XML nodes are converted into an in-memory tree, followingthe structure of the XML file. This tree is made up of custom PropertyNode objects.Each PropertyNode object contains a hash of property values that were retrieved fromthe save file (Appendix D.3 on page 83). The object also contains a pointer to its parent

50


PropertyNode and any children nodes. Each PropertyNode in the tree represents a singleobject that was serialised. Methods are provided to retrieve a list of children PropertyNodeobjects with a specific XML tag.

Score handles the deserialisation of all musical information from the save files (not justScore objects) in its initialiseFromProperties method. This method expects a validPropertyNode object to be passed to it representing the save file. PropertyNode ob-jects are created by the deserialiseFromFile method in the AntonFileIO class. Afterthe PropertyNode object tree has been created, initialiseFromProperties determineswhether the supplied PropertyNode contains all of the necessary information for the deseri-alisation of the entire score. For instance, the PropertyNode describing a Score object hasto contain the “transpose”, “style” and “mode” properties (see Table 5.1 on page 47). Op-tional properties are those such as “title” and “author” (composer). The method continuesthe process down the hierarchy looking for FragmentListModel objects, Fragment objectsand finally Notes. As the traversal continues, the relevant objects are allocated, propertiesare set and slots/signals are connected. If all of the essential properties are found on eachobject and at least one part was found, then the deserialisation process was successful.

To anticipate future, breaking changes in the file format, a simple versioning system is alsoused. Every score that is serialised has the corresponding version number of Anton writteninto the file. Anton will refuse to load any score that was created with a newer version ofAnton and assumes that the deserialisation process can cope with files created with anyolder or equal version of Anton.

5.2.3 Composition Buffer

The second major feature that was implemented during this iteration was the CompositionBuffer. The Composition Buffer allows users to “snapshot” the state of the active score.This can be particularly useful before users perform destructive tasks such as using theRegenerate Fragment (Autofill) feature. This feature works by building on top of theserialisation framework to add support for serialising / deserialising from strings in additionto files. The initialiseFromString method was added to the Score object to supportrestoring a Score from a serialisation string. The Composition Buffer can be seen as a listwhich keeps all of the user’s snapshots in one place. There are a few interesting features inthe implementation of this list that will be mentioned in Section 5.2.3.1 (on page 52).

The feature consists of several different classes:

BufferListModel BufferListModel provides access to all of the data stored within thecomposition buffer.

BufferList This class provides a dockable, draggable window in which the rest of the userinterface is housed. BufferList acts as the controller layer for the composition bufferfeature, as all of the data changes are co-ordinated by this class between the model(BufferListModel) and the view (BufferListWidget).

51


BufferListWidget This class provides the main user interface features. It displays atoolbar which allows the user to select the main operations, such as adding the currentScore state into the buffer, purging an existing saved state and removing all ofthe entries within the buffer. It also displays a list which contains a listing of thepreviously saved scores.

5.2.3.1 List implementation

The implementation of the BufferListModel is interesting because it has several efficiencymeasures. The main efficiency measure, as per Project Control List entry 5 for this iter-ation, is that entries within the buffer can be aliases of another score within the buffer.This is needed because there are times when a user might try to save a snapshot, but thesame score is already present within the buffer. This can happen, for instance, when a userregenerates a Score as sometimes there are only 1 or 2 musically valid replacements thatthe auto-fill procedure can select from. Thus the chances of the same composition beinggenerated is quite high. While a naıve implementation of the composition buffer couldsimply store the duplicate scores, it was decided that a better implementation could bedeveloped.

The chosen approach uses two hash tables, _scores and _bufferList. The _scores hashstores a mapping between the MD5 hash of the string describing a score (XML format asin Appendix C.2 on page 79), which is the key of the hash, and the score XML string itselfas the value. The _bufferList stores a mapping between the snapshot number (the firstsnapshot is 1 and is incremented with each snapshot) and the MD5 hash of the score towhich this snapshot refers.

When a snapshot is taken, the MD5 hash is calculated for the score. If this MD5 hash is notfound as a valid key within the _scores hash, then it is added as a new entry along with theXML score string. If it does already exist, no action is taken. Finally, an internal counteris incremented (_scoreNumber) and a mapping is stored within _bufferList between thisnumber and the MD5 hash of the score. Thus, we end up with a mapping between thehashes which ensures we do not need to store multiple copies of a single score and we havethe lookup efficiency that a hash map provides. QHash provides O(n) worst case lookupand insertion efficiency, but is constant time on average.

An alternative approach would be to use a QList of QString pointers. The use of pointerswould still allow one score to alias another, so storage would still be fairly small - especiallywithout the overhead introduced by having two containers. However, the process of ascer-taining whether a given score is equivalent to another within the buffer would be expensive.On each equivalence check, in the worst case scenario, every item within the QList wouldhave to be checked and then a string comparison would have to be done between the valueat that position and the new Score. As a result, it was decided that this approach wouldbe too slow for large numbers of scores within the buffer list.

Appendix D.4 (on page 84) shows the selected approach in diagrammatic form.

52

5.3. TESTING CHAPTER 5. ITERATION II

5.2.4 Windows Fixes for Perl Scripts

As discovered in the first iteration, ProcessTask was unable to execute perl scripts whenrunning on Windows. The problem was that, unlike on Unix-based operating systems,Windows does not understand how to execute perl script files directly from the commandline. The solution to this problem was to call the perl interpreter, passing the script filenameas a parameter.

To implement this fix, the Preferences window was updated to require that the user specifiesthe path to a valid perl interpreter. After prefixing the calls to the Anton script files withthe perl interpreter, the scripts were able to run without any further problems. As part ofthis work, a previously neglected notice on the QFile documentation1 meant that changeswere made to the SettingsManager class so that all slashes in path names are automaticallyconverted to Unix-style forward slashes, as per the Qt recommendations.

These changes were made in such a way that no platform independent code was introduced.Unix-based operating systems fully support this method of executing perl scripts in additionto Windows.

5.2.5 Screenshots

Screenshots of the features that were completed for Iteration II can be found in AppendixB.2 (on page 74).

5.3 Testing


No new issues were discovered during the testing phase for this iteration. The fix to makeperl scripts work on Windows solved the issues from the first iteration.

5.4 Evaluation

During Iteration II two key features were developed, the ability to serialise scores and thecomposition buffer.

Some optimisation choices were made during the creation of the composition buffer throughthe use of hashing. The benefit of the chosen approach was that storage space of scoresis minimal as no duplicate scores are stored and lookups can be performed in, on average,constant time. An alternative method was discussed of using a QList with pointers to thescores (stored as strings) within the buffer. While this approach would remove the necessity

1http://doc.trolltech.com/4.6/qfile.html

53

http://doc.trolltech.com/4.6/qfile.html

5.4. EVALUATION CHAPTER 5. ITERATION II

of having a second QHash container and the added complexity of the MD5 hash procedure,it would also introduce worse, on average, buffer lookup characteristics.

It is difficult to say whether the right approach was taken, because there was no time toconduct experiments comparing the practical, relative expense of the different approaches.A limit was set on the number of entries that could be stored within the buffer (to simplifythe user interface and constrain memory usage) and as a result, the size of the buffer isguaranteed to be small. An experiment to compare the approaches would therefore have tobalance the expense of the MD5 hashing procedure, the overhead of having two containersversus one, how expensive QString comparison is and whether C++/Qt points lexicallyequivalent QString objects to the same underlying memory. Although the approaches werenot compared, the chosen approach did not highlight any performance concerns duringtesting and the limited size of the buffer would likely render any differences negligible tothe end user.

Another issue with the composition buffer was that, although buffer entries can be removedfrom the _bufferList hash, the underlying string representation of the scores are neverremoved from the _scores hash. Although this is wasteful on memory and could definitelybe classified a memory leak, the removal of scores from the _scores hash is quite anexpensive operation. Because multiple buffer list entries can point to the same underlyingscore, when the user asks to remove a buffer list entry, Anton cannot remove the underlyingscore without first verifying that no other buffer list entry points to the same score.

To determine if an underlying score can be removed, this would require a full traversal ofthe _bufferList structure to count how many remaining references there are to the samescore. If there are no further references then the score can also be removed at the sametime as the buffer list entry. This traversal, however, can be expensive because hashesare not optimised to provide access to data values without first specifying a key value. Abetter approach altogether would be to create a naıve reference counting system. A thirdstructure could be introduced which, for each score, keeps track of how many references aremade to it. When an alias is made to a score, this reference count would be incremented,whilst removing a buffer list entry would decrement the reference counter for its associatedscore. Thus when a user asks to remove a buffer list entry, if the reference count ofthe associated score is zero, the score can also be deleted without the added expense ofhash-value traversals. This approach was not thought of during the design phase for thisiteration, but could be easily introduced in the future.

Several requirements (specifically Requirements 4.1.1.6 and 4.1.1.7) indicate that the com-position buffer should auto-persist the score at key points, for instance before the start ofdestructive operations. This auto-persist feature, however, was not implemented. Becausethere is only a limited number of spaces within the composition buffer, if Anton was toauto-persist, the composer might potentially lose scores from the end of the buffer thatthey wanted to keep. Instead of trying to second-guess the composer, Anton leaves thecomposer in control of when they wish to persist score state.

The testing for Iteration II was successful and no further remedial work had to be completed

54

5.4. EVALUATION CHAPTER 5. ITERATION II

for the final iteration.

55

Chapter 6

Iteration III

6.1 Project Control List

The only original item remaining on the Project Control List is the MIDI input feature.No further items were added to the Project Control List for this iteration.


6.2 Further Design and Implementation



6.2.2 MIDI Input

The final, original feature from the Project Control List was the ability to extend themusical material within a Score. During the background research for the literature survey, itwas noted that the Canorus project (Section 2.5.4.3 on page 17) selected the RtMidi libraryfor implementing their MIDI I/O features. After reading through the documentation, thedecision to use RtMidi was taken as the API1 looked easy to work with.

The MIDI input facility is provided within a modal dialog box, defined in the InputDialogclass. The interface can be launched by the user after selecting a Fragment in the arranger.The Fragment object’s associated FragmentModel is updated based on the MIDI messagesthat are received.

1Application Programming Interface

56

6.3. TESTING CHAPTER 6. ITERATION III

RtMidi requires a static callback method to be defined that is called to handle MIDIevents. The method that was created for this purpose is called midiCallback. The origi-nal intention was to have this callback function directly insert the relevant Note into theFragmentModel that is currently being edited. This method did not work because of Rt-Midi’s insistence on the callback method being static. As a static method, the callback isunable to access the FragmentModel which is defined as an instance member. Additionally,it was decided that having the callback directly update the FragmentModel may lead toperformance issues if lots of MIDI events are suddenly generated.

To circumvent the problem of accessing instance level members from a static context,the decision was taken to implement an intermediary MIDI buffer. The MIDI buffer isimplemented as a static QList of integers. These integers are the pitch of notes that aregenerated by the MIDI controller. A small amount of filtering is performed in the callbackto discard messages we are not interested in, such as program changes and tempo alterationsetc. If the message is considered useful, it is added to the buffer. A timer within the objectperiodically polls the static buffer looking for new MIDI messages. When a pitch is foundon the buffer, a Note object with this pitch is created and added to the end of the selectedFragmentModel.

One problem with this approach was that the timer may want to access the buffer atthe same time as the static callback method. To solve this problem of “shared-access” aQMutexLocker was used so that reads/writes to the buffer structure can only be performedwhen either the callback method or the timer has exclusive access to the list. If datawas simply being appended to the list, this would not be a problem. However, the timerprocess needs an exclusive lock because it needs to clear the buffer after it has processedthe contents, to avoid the same Note objects being created when the timer is called again.QMutexLocker provides very simple locking/unlocking of an underlying QMutex to ensureexclusive access to a data member. Due to its simplicity, it is not prone to deadlocks andother locking related problems like more complicated, manual uses of mutexes. The use ofa QMutexLocker is roughly equivalent to that of the synchronized keyword in Java.

Notes can also be removed from the end of a Fragment by pressing the backspace key.Unfortunately there was not enough time to implement more advanced editing, such asediting from an arbitrary location within a Fragment, etc.

6.2.3 Screenshots

Screenshots of the features that were completed for Iteration III can be found in AppendixB.3 (on page 75).

6.3 Testing

Unfortunately the MIDI tests (specifically Test 19 - Test 21) could not be run on Windowsor Linux. As the Windows testing was conducted on a remote server, it was impossible to

57

6.4. EVALUATION CHAPTER 6. ITERATION III

plug in any MIDI peripherals for testing purposes. On Linux, there were issues preventingthe MIDI controller from being recognised inside the virtual machine. The test cases ranas desired on Mac OS X.


No new issues were discovered during the testing phase for this iteration.

6.4 Evaluation

This iteration completed the final point on the project control list, MIDI input.

Unfortunately during the planning of this iteration, the need for access to a physical Win-dows and Linux box for testing was overlooked. The MIDI features worked as expected inMac OS X and as RtMidi is used in many cross-platform projects, it should not pose anyproblems on other platforms.

MIDI input was an obvious place to introduce multi-fragment parts, support for whichhas been coded into the Anton GUI from the start of development. All recorded materialcould have be written into a new blank Fragment. Unfortunately time didn’t allow forthe implementation of some of the supplementary functions that were needed to make thiswork. For multi-fragment parts to be useful, it would be necessary to allow Fragments tobe dragged within and between tracks in the Arranger.

The timer that polls the MIDI notes buffer is set to run every 300 milliseconds. This intervalwas finally selected after testing on the main development machine, but the differing MIDIlatency on other platforms / drivers might require this figure to be adjusted. In hindsight,it would have been better to allow the user to adjust this interval in the preferences window.

No issues were found when testing the features from this iteration, although several of theaforementioned tests could not be run on Linux and Windows.

6.4.1 Building and Packaging

Another problem that was overlooked during this final iteration was the packaging and dis-tribution of the software. As mentioned in the initial implementation section (Section 4.5.1on page 33), all software development was done within the QtCreator IDE. While QtCre-ator was incredibly convenient, it made it hard to bundle and compile several dependencies(GUIDOLib, GuidoQt and RtMidi). Also there was no built-in support for packaging thefinished software (except for the macdeployqt tool which is used to build the Anton diskimage for OS X).

During the research into Qt, it was noted that several projects (GUIDO, Canorus and

58

6.4. EVALUATION CHAPTER 6. ITERATION III

even the popular Boost C++ framework) rely on using the cmake2 build system. Usingcmake allows the developer to write a single makefile which automatically generates theappropriate makefile for the current build environment and platform at compile time. Itcan also work out, order and compile all of the project dependencies. QtCreator is alsocapable of creating a QtCreator project from cmake makefiles. This meant that althoughthe build system had to be changed, it was still possible to continue using QtCreator. Thecmake build system also comes with cpack which is capable of packaging the compiledbinaries in several different formats.

At a very late stage in the third iteration, the project was converted from using QtCreatorproject files (still retained in the project repository for review) to using cmake and cpack.Although this conversion was fairly lengthy, it now allows for easy compilation on all of thetarget platforms including the supplied GuidoQt, GUIDOLib and RtMidi dependencies.

2http://www.cmake.org/

59

http://www.cmake.org/

Chapter 7

Evaluation

7.1 Project Summary

The project was successful in many of its original aims. A fully-functional, cross-platformuser interface has been devised which successfully wraps Anton’s expansive feature set.While no time was available to look further into the rule management and generationaspects of Anton, the project provides a solid foundation upon which these features couldbe added. The interface works on all major operating systems without relying on anyexternal dependencies, such as the Java runtime.

Prior to the completion of this project, Anton would have had limited appeal to those out-side of the computer-music community. The new user interface provides a real alternativeto those who want to generate original pieces. Making a user interface for Anton has notjust been about making the existing features more accessible, but also the creation of novelfeatures that extend Anton’s musical capabilities.

The composition buffer is a new feature that capitalises on Anton being run within a GUIand could be really beneficial to musicians who use automated composition. Another use-ful addition is the ability to combine algorithm-generated and composer-selected materialthrough the use of the MIDI input features. Without the user interface, composers wouldhave had to manually move around Csound snippets to achieve this kind of flexibility, copy-ing each change they make into a temporary text file to emulate the composition bufferfeature.

On top of the many added features, composers are now able to access a live preview of thecomposed material using the embedded score views. Previously, the main method of seeingthe composition as a score was to start Lilypond, importing a previously exported Lilypondformatted score. The user interface has removed the necessity of running many of thesecomplicated, manual workflows. Scores can now even be directly printed from within theuser interface, which was previously one of these non-trivial, multistep operations. Throughthe developer’s use of the MVC paradigm throughout, composers can also choose to look at

60

7.2. LIMITATIONS CHAPTER 7. EVALUATION

several parts of the score simultaneously, which is useful for incorporating musical themesand motifs into other areas of a score.

The iterative methodology that was selected was very helpful in ensuring that focus onthe core features was maintained throughout. Splitting the implementation up into threeiterations meant that it was clearer how much time could be spent on each individual part ofthe project, while still allowing for flexibility through adding items to the “Project ControlList”. Although the control list was only altered once during the project to add a bug fix,the ability to reorganise the project in this way was very beneficial. The segregation of theiterations has been carried through to this report, so it better represents the way that theproject was carried out. A large portion of the successful outcome of this project can beattributed to the development approach that was taken.

Some issues were encountered that can be attributed to deficiencies in the organisationof the project. The first issue was that considerations surrounding the packaging anddistribution of the software were never considered at the start of the project. Had theseissues been fully resolved at the start of the project, it might have avoided the necessity ofmigrating all of the QtCreator project files to cmake makefiles at the last minute duringIteration III (Section 6.4.1 on page 58 describes the issues in greater detail). The othermain issue was the lack of available hardware to test the Linux and Windows MIDI features(see Section 6.3 on page 57). The required hardware list was created before the projectcontrol list was completed, so the inclusion of the MIDI feature was not known at thispoint. Had previous decisions, such as the hardware list or build system choice, beenrevised continually throughout the project, such issues may not have been overlooked orpicked up early enough to rectify at an earlier point.

If the project was to be carried out again, more time should be spent at the start of eachiteration rationalising previous decisions that were made. Various different improvementscould have been made to Anton: the implementation of a fully-functional user interface,concentrating on the development of rules within a GUI and further improvements toAnton itself. While all of these projects were equally valid, the selected approach waschosen because it was believed that it would yield the greatest amount of feature-relatedbenefits within the allotted project time. While beneficial work could have been carriedout into the implementation of a rule-management interface, the design/implementationphases would have been sufficiently complicated that the amount of progress that couldhave been made within the limited project time would have been called into question. Theselected project strikes a good balance between new innovation and project progress.

7.2 Limitations

One of the main limitations within the user interface is that although multiple fragmentsare supported in each part, none of the features actually make use of this yet. Another issueis that fragments cannot be dragged around within the user interface. Ideally fragmentsshould be able to be dragged within a track and even to other tracks. This would better

61

7.3. FUTURE WORK CHAPTER 7. EVALUATION

replicate the features that are available in other packages, such as Logic Studio.

The second main limitation is the lack of rhythm support within the GUI. With the intro-duction of Anton 2.0, Anton is capable of composing rhythm in addition to melody andharmony. While the concept of note duration has been encoded wherever possible withinthe user interface, it would take a lot of work to actually make it work flawlessly.

Another limitation is that while notes can be appended or deleted from the end of aFragment, the MIDI input screen provides no method of editing at arbitrary locationswithin a fragment. This is problematic because a composer might want to change just asingle note in the middle of the track. Currently that is not possible without deleting allof the notes from the end of the Fragment, modifying the single note and playing all of thedeleted music back into Anton.

While Anton has started integrating MIDI input into the workflow, there is no capabilityto play back the composed material using MIDI output. Certain composers might prefer tobe able to hear the music on-demand, while others will likely prefer the freedom of playingthe scored music on a physical keyboard/piano.

A future aspiration for Anton is that it might be extended to a variety of different musicstyles. As this avenue was not really explored in this project, it has not been decided howdifferent banks of styles will be managed in Anton. As such, the user interface makes theassumption that only one style is available until these decisions have been made.

Other limitations include the lack of undo/redo and copy/paste functionality. These fea-tures would all become more important, if the limitations on multi-fragment parts were tobe removed.

7.3 Future Work

Although Anton could be taken many different directions in the future, a few different ideasfor future work are suggested.

Musical Styles Although this suggestion would require a lot of discussion with the origi-nal developers of Anton, the GUI could lead the way by incorporating a methodologyof storing and utilising “banks of styles”. There would have to be a method of de-ploying banks of styles with potential dependencies on other styles. The GUI couldprovide methods of editing these styles graphically and deploying the new style bun-dles.

Rhythm Support While preliminary support exists in the GUI for supporting rhythm,there is a fairly long way to go. The new Anton 2.0 file format would first have tobe supported within the GUI, parsing out all of the rhythm choices for the notes.GUIDOConverter would have to be updated to support translating GUI rhythm intoGUIDO rhythm. Support for time signature selection would also have to be included.

62

7.4. PERSONAL REFLECTION CHAPTER 7. EVALUATION

Finally, the MIDI input screen would have to be updated to allow the user to specifyrhythms for the notes they are playing. The GUI could also attempt to guess therhythm of the inputted notes based on the duration that the notes are played for onthe MIDI controller.

Multiple Fragments The MIDI input feature would benefit greatly from being able torecord music into new, empty fragments rather than recording onto the end of exist-ing fragments. This concept is already partially supported by the offset property inthe FragmentModel class. There are several other features that are connected withthis extension and would require more work. The facility to drag fragments withinthe main arranger window would be necessary. As fragments are dragged, the frag-ment offset would have to be adjusted accordingly. Another useful feature would bethe ability to split one fragment into two, using the mouse cursor to determine thesplit point. Adding copy and paste features would also make working with multiplefragments much easier.

Export Types While support exists for outputting legacy Anton scores, the range ofexport formats should be increased. While it is possible, a composer is unlikely towant to use the Anton GUI as their sole composition tool. As such, composers wouldbenefit greatly by providing a range of different output formats. Some of the existingtranslation work has already been done within the core Anton scripts, so implementingCsound and Lilypond output would not be too difficult. Another particularly usefulformat to support for interchange purposes would be MIDI files.

Localisation In line with the requirement to make Anton accessible to as wider audienceas possible, one could localise the Anton GUI into different languages. The projecthas followed Qt standard practices, which means that the localisation of any stringwithin Anton should be easy with the supplied Qt Linguist tools.

Mobile The selection of Qt has opened the possibility of one day making a mobile versionof Anton available. Although mobile processors probably would not be powerfulenough to drive the composition scripts, a mobile device could certainly be used todrive the scripts running on a backend server.

Different Instruments GUIDOLib already fully supports the display of drum scores,so percussion composition might be a potential area into which Anton might beexpanded.

7.4 Personal Reflection

I feel that the project was incredibly successful, not only in meeting the original aims,but also providing a new direction and potential audience for Anton. The project was,in my opinion, very worthwhile as Anton has so many unique features that can now bebetter demonstrated. It was particularly enjoyable augmenting Anton’s feature set with

63

7.4. PERSONAL REFLECTION CHAPTER 7. EVALUATION

new ideas such as the Composition Buffer. Music and technology are two areas that I amreally interested in, so the project was a perfect combination of these two areas of personalinterest.

The iterative methodology that was chosen was really beneficial to the project and was, Ifeel, a contributing factor to the success of the project, helping it keep on track. AlthoughI think that the majority of decisions that were made were correct, it would have beenbeneficial to review some of my earlier decisions throughout the project. Additionally itwould have been helpful to have planned the packaging and build phases better at the startof the project.

To avoid some of these problems in future projects, I would seek to apply the iterativemethodology to the entire development process rather than just the features and code.This would hopefully resolve the few, minor issues that were encountered with this project.

Although, at times, progress was hindered by the learning curve of Qt and C++, I reallyfeel that it was the right choice to make. The quality and feature set of GUIDOLib wasunmatched by any other library that was detailed within the Literature Survey. Whilecomplications in the build process could have been avoided by using Java, this would havemeant that Anton would have continued to lack a score view. Without a score view theresultant user interface would have been of lower quality, detracting from the main aim ofcreating a musician friendly interface. Java would have also added the requirement thatthe user installs another dependency, the Java runtime. The fact that Qt/C++ producesnative binaries is an advantage. The skills that were picked up during the course of theproject will be greatly beneficial. As a result of this work, my C++ and Linux skills havereally improved.

I think that this project has shown that it is possible to bring Anton’s advanced compositiontechnology to a new audience. The transition into adopting a graphical user interfacehas also allowed for development of several innovative new features, complementing thosealready available in Anton. I hope that the output of this project can be used as a startingpoint for further innovation in this area.

64

Bibliography

[Anders, 2007] Anders, T. (2007). Composing Music by Composing Rules: Design andUsage of a Generic Music Constraint System. PhD thesis, Queen’s University, Belfast,Department of Music.

[Anders et al., 2005] Anders, T., Anagnostopoulou, C., and Alcorn, M. (2005). Multi-paradigm Programming in Mozart/OZ, chapter Strasheela: Design and Usage of a MusicComposition Environment Based on the Oz Programming Model (pages: 277 - 291).Lecture Notes in Computer Science. Springer Berlin / Heidelberg.

[Ariza, 2005] Ariza, C. (2005). Navigating the Landscape of Computer-Aided AlgorithmicComposition Systems: A Definition, Seven Descriptors, and a Lexicon of Systems andResearch. In International Computer Music Conference, pages 765–772.

[Ayers, 2008] Ayers, L. (2008). Computer music synthesis and composition. In Handbookof Signal Processing in Acoustics, pages 333–358. Springer New York.

[Baral, 2003] Baral, C. (2003). Knowledge Representation, Reasoning, and DeclarativeProblem Solving. Cambridge University Press, Cambridge.

[Blostein and Haken, 1991] Blostein, D. and Haken, L. (1991). Justification of printedmusic. Commun. ACM, 34(3):88–99.

[Boenn et al., 2009a] Boenn, G., Brain, M., De Vos, M., and ffitch, J. (2009a). Anton:Composing logic and logic composing. In LPNMR ’09: Proceedings of the 10th Interna-tional Conference on Logic Programming and Nonmonotonic Reasoning, pages 542–547,Berlin, Heidelberg. Springer-Verlag.

[Boenn et al., 2009b] Boenn, G., Brain, M., De Vos, M., and ffitch, J. (2009b). Auto-matic composition of melodic and harmonic music by answer set programming. In LogicProgramming, Lecture Notes in Computer Science, pages 160–174. Springer Berlin /Heidelberg.

[Brain and De Vos, 2008] Brain, M. and De Vos, M. (2008). Answer set programming - adomain in need of explanation: A position paper. In ExaCt, pages 37–48.

[Byrd, 1984] Byrd, D. A. (1984). Music notation by computer (formatting). PhD thesis,Indiana University, Indianapolis, IN, USA.

65

BIBLIOGRAPHY BIBLIOGRAPHY

[Chuang, 1995] Chuang, J. (1995). Mozart’s Musikalisches Wurfelspiel. http://sunsite.univie.ac.at/Mozart/dice/#options. [Online; accessed 24-November-2009].

[Ebcioglu, 1988] Ebcioglu, K. (1988). An Expert System for Harmonizing Four-PartChorales. Computer Music Journal, 12(3):43–51.

[Gedan, 2009] Gedan, J. (2003–2009). Chopin: Polonaisen. http://www.pian-e-forte.de/noten/notbsp/109599.htm. [Online; accessed 11-December-2009].

[Hoos et al., 1998] Hoos, H., Hamel, K., Renz, K., and Kilian, J. (1998). The GUIDOMusic Notation Format - A Novel Approach for Adequately Representing Score-levelMusic. In Proceedings of ICMC’98, pages 451–454. ICMC.

[Katzmann, 2009] Katzmann, R. (2009). Developers Guide [for Canorus].http://canorus.berlios.de/wiki/index.php/Developers_Guide#Model-View-Controller_design. [Online; accessed 12-December-2009].

[Krause, 2007] Krause, A. (2007). Foundations of GTK+ Development (Expert’s Voice inOpen Source). Apress.

[Kupper, 1995] Kupper, H. (1995). [Introduction to] Der allezeit fertige Polonoisen=und Menuettencomponist. http://www.musikwissenschaft.uni-mainz.de/Musikinformatik/schriftenreihe/nr15/Kirn.html. [Online; accessed 12-December-2009].

[Lifschitz, 2002] Lifschitz, V. (2002). Answer set programming and plan generation. Arti-ficial Intelligence, 138(1-2):39 – 54.

[Lifschitz, 2008] Lifschitz, V. (2008). What is answer set programming? In AAAI’08:Proceedings of the 23rd national conference on Artificial intelligence, pages 1594–1597.AAAI Press.

[Nienhuys and Nieuwenhuizen, 2003] Nienhuys, H.-W. and Nieuwenhuizen, J. (2003).LILYPOND, A SYSTEM FOR AUTOMATED MUSIC ENGRAVING. In Proceedingsof the XIV Colloquium on Musical Informatics (XIV CIM 2003).

[Nokia Corporation, 2009] Nokia Corporation (2009). Qt 4.6 Whitepaper. http://qt.nokia.com/developer/getting-started/files/pdf/qt-4.4-whitepaper. [Online;accessed 11-December-2009].

[O’Neill et al., 2006] O’Neill, E., Kaenampornpan, M., Kostakos, V., Warr, A., andWoodgate, D. (2006). Can we do without guis? gesture and speech interaction witha patient information system. Personal Ubiquitous Comput., 10(5):269–283.

[Pennycook, 1985] Pennycook, B. W. (1985). Computer-music interfaces: a survey. ACMComput. Surv., 17(2):267–289.

[Shann and Mehl, 2009] Shann, R. and Mehl, A. (2009). Denemo - manual. http://www.denemo.org/doc/denemo-manual.html. [Online; accessed 13-December-2009].

66

http://sunsite.univie.ac.at/Mozart/dice/#options

http://sunsite.univie.ac.at/Mozart/dice/#options

http://www.pian-e-forte.de/noten/notbsp/109599.htm

http://www.pian-e-forte.de/noten/notbsp/109599.htm

http://canorus.berlios.de/wiki/index.php/Developers_Guide#Model-View-Controller_design

http://canorus.berlios.de/wiki/index.php/Developers_Guide#Model-View-Controller_design

http://www.musikwissenschaft.uni-mainz.de/Musikinformatik/schriftenreihe/nr15/Kirn.html

http://www.musikwissenschaft.uni-mainz.de/Musikinformatik/schriftenreihe/nr15/Kirn.html

http://qt.nokia.com/developer/getting-started/files/pdf/qt-4.4-whitepaper

http://qt.nokia.com/developer/getting-started/files/pdf/qt-4.4-whitepaper

http://www.denemo.org/doc/denemo-manual.html

http://www.denemo.org/doc/denemo-manual.html

BIBLIOGRAPHY BIBLIOGRAPHY

[Sommerville, 2007] Sommerville, I. (2007). Software Engineering [8th Edition]. Addison-Wesley Publishers Limited.

[Taupin et al., 2005] Taupin, D., Mitchell, R., and Egler, A. (2005). Using TEX towrite polyphonic or instrumental music. http://tug.ctan.org/tex-archive/macros/musixtex/taupin/musixdoc.pdf. [Online; accessed 11-December-2009].

[The GTK+ Team, 2008] The GTK+ Team (2007–2008). GTK+ - Features. http://www.gtk.org/features.html. [Online; accessed 13-December-2009].

[Wikipedia, 2009a] Wikipedia (2009a). GUIDO music notation — Wikipedia, TheFree Encyclopedia. http://en.wikipedia.org/w/index.php?title=GUIDO_music_notation&oldid=291883425. [Online; accessed 19-November-2009].

[Wikipedia, 2009b] Wikipedia (2009b). Usage share of desktop operating systems. [Online;accessed 18-October-2009].

67

http://tug.ctan.org/tex-archive/macros/musixtex/taupin/musixdoc.pdf

http://tug.ctan.org/tex-archive/macros/musixtex/taupin/musixdoc.pdf

http://www.gtk.org/features.html

http://www.gtk.org/features.html

http://en.wikipedia.org/w/index.php?title=GUIDO_music_notation&oldid=291883425

http://en.wikipedia.org/w/index.php?title=GUIDO_music_notation&oldid=291883425

Appendix A

Designs

68

A.1

.IT

ER

AT

ION

I69

A.1 Iteration I

A.1.1 Main Window

The main interface is a track viewer which displays each of the parts within an Anton composition. Various parameters ofthe selected track / score can be edited using the integrated inspector window.

A.1.2 Other Windows

The score window provides a simple score display and a small toolbar area where it is possible to toggle options such aswhether to display the whole score or just the selected fragment. The preferences window simply displays and allows the userto edit important file locations, such as the Anton script folder and the ASP solver / grounder.

Anton

Track 1

Track 2

Track 3

Track 4

Inspector

Score View Diagnose Autofill MIDI

Title My Chora...

Mode Major

Style Quartet

Author Henry Thac...

(a) User Interface: Main Window

Score Viewer

Show entire score

=======& q q q

(b) User Interface: Score Viewer

Preferences

Anton Location:Clasp Location:Gringo Location:

LocationLocation2Location3

OK Close

(c) User Interface: Preferences

Figure A.1: User Interface: Designs for iteration I

A.2

.IT

ER

AT

ION

II70

A.2 Iteration II

A.2.1 Composition Buffer

The only user interface that will be added in the second iteration is the composition buffer interface, presented in Figure A.2.The user interface allows users to add new entries to the buffer, clear all entries, remove the selected entry and to restore thecurrently selected entry. The entries are presented in a list, with the most recently added entries at the top of the list.

Composition Buffer

Add Entry Clear Remove Apply

Score One

Score Two

Score Three

Figure A.2: User Interface: Composition buffer

A.3

.IT

ER

AT

ION

III71

A.3 Iteration III

A.3.1 MIDI Input

The only user interface that will be added in the third iteration is the MIDI Input interface, presented in Figure A.3. Theuser interface is very minimal for this view, the only visible elements are the score viewer to show the recorded music andsome controls to change the active MIDI input.

MIDI Input

=======& q q q

Midi Controller Refresh

Figure A.3: User Interface: MIDI input

Appendix B

Screenshots

72

B.1.

ITE

RA

TIO

NI

73B.1 Iteration I

B.2.

ITE

RA

TIO

NII

74B.2 Iteration II

B.3.

ITE

RA

TIO

NIII

75B.3 Iteration III

B.4.

CR

OSS-P

LA

TFO

RM

-O

SX

,W

IND

OW

S,O

PE

NSU

SE

LIN

UX

76B.4 Cross-Platform - OS X, Windows, OpenSUSE Linux

Appendix C

Examples

77

C.1

.E

XA

MP

LE

-LE

GA

CY

SC

OR

EFIL

E78

C.1 Example - Legacy Score File

mode( major ) .part ( 1 ) .choosenNote ( 1 , 1 , 2 5 ) .choosenNote ( 1 , 2 , 2 9 ) .choosenNote ( 1 , 3 , 2 5 ) .choosenNote ( 1 , 4 , 2 7 ) .choosenNote ( 1 , 5 , 2 2 ) .choosenNote ( 1 , 6 , 2 9 ) .choosenNote ( 1 , 7 , 2 4 ) .choosenNote ( 1 , 8 , 2 5 ) .part ( 2 ) .choosenNote ( 2 , 1 , 2 5 ) .choosenNote ( 2 , 2 , 1 3 ) .choosenNote ( 2 , 3 , 1 3 ) .choosenNote ( 2 , 4 , 1 2 ) .choosenNote ( 2 , 5 , 1 5 ) .choosenNote ( 2 , 6 , 1 3 ) .choosenNote ( 2 , 7 , 1 5 ) .choosenNote ( 2 , 8 , 1 3 ) .#const t =8.s t y l e ( duet ) .

C.2

.E

XA

MP

LE

-N

AT

IVE

XM

LSC

OR

EFIL

E79

C.2 Example - Native XML Score File

<?xml version=” 1.0 ” encoding=”UTF−8”?><an t on : an t on f i l e xmlns:anton=” ht tp : // cs . bath . ac . uk/anton /1 . 0 . 0 / schema” anton :ve r s i on=” 1 . 0 . 0 ”>

<anton : s co r e anton : t ranspose=”0” anton:partCount=”2” anton:mode=”mixolydian ” an t on : s t y l e=”duet” a n t o n : t i t l e=”” anton:author=””><anton:fragment− l i s t anton : t rack=”1” anton : co l our=”#b5a0c8” anton:trackName=”Track 1” an t o n : c l e f=”1”>

<anton: f ragment a n t o n : o f f s e t=”0”><anton:note anton:note=”32” anton :durat ion=”4”/><anton:note anton:note=”27” anton :durat ion=”4”/><anton:note anton:note=”29” anton :durat ion=”4”/><anton:note anton:note=”27” anton :durat ion=”4”/><anton:note anton:note=”32” anton :durat ion=”4”/><anton:note anton:note=”30” anton :durat ion=”4”/><anton:note anton:note=”34” anton :durat ion=”4”/><anton:note anton:note=”32” anton :durat ion=”4”/>

</ anton: f ragment></ anton:fragment− l i s t><anton:fragment− l i s t anton : t rack=”2” anton : co l our=”#b5a0c8” anton:trackName=”Track 2” an t o n : c l e f=”1”>

<anton: f ragment a n t o n : o f f s e t=”0”><anton:note anton:note=”20” anton :durat ion=”4”/><anton:note anton:note=”20” anton :durat ion=”4”/><anton:note anton:note=”20” anton :durat ion=”4”/><anton:note anton:note=”20” anton :durat ion=”4”/><anton:note anton:note=”20” anton :durat ion=”4”/><anton:note anton:note=”27” anton :durat ion=”4”/><anton:note anton:note=”27” anton :durat ion=”4”/><anton:note anton:note=”32” anton :durat ion=”4”/>

</ anton: f ragment></ anton:fragment− l i s t>

</ anton : s co r e></ an t on : an t on f i l e>

Appendix D

Diagrams

80

D.1

.SC

OR

EE

DIT

OR

-LO

GIC

ST

UD

IO81

D.1 Score Editor - Logic Studio

D.2

.SC

OR

ED

EC

OM

PO

SIT

ION

82D.2 Score Decomposition

Score

FragmentListModel 1

FragmentModel s...Note (1..r)

FragmentModel 1

Note (1..q)

FragmentListModel w

FragmentModel v...Note (1..u)

FragmentModel 1

Note (1..t)

...

D.3

.P

RO

PE

RT

YN

OD

EH

IER

AR

CH

Y83

D.3 Property Node Hierarchy

PropertyNodeScore

PARENT CHILDREN

transpose = 0partCount = 2mode = minorstyle = duettitle = My Pieceauthor = Henry Thacker

PropertyNodeFragmentListModel

PARENT CHILDREN

track = 1colour = #b5a0c8trackName = Track 1clef = 1 [ClefType::Auto]

PropertyNodeFragmentListModel

PARENT CHILDREN

track = 2colour = #b5a0c8trackName = Track 2clef = 1 [ClefType::Auto]

PropertyNodeFragmentModel

PARENT CHILDREN

offset = 0

PropertyNodeFragmentModel

PARENT CHILDREN

offset = 0

PropertyNodeNote

PARENT CHILDREN

duration = 4note = 22

PropertyNodeNote

PARENT CHILDREN


PropertyNodeNote

PARENT CHILDREN


PropertyNodeNote

PARENT CHILDREN


PropertyNodeNote

PARENT CHILDREN


D.4. COMPOSITION BUFFER LIST 84

D.4 Composition Buffer List

& weXML Score String<?xml version="1.0" encoding="UTF-8"?> ....

1 Convert Active Score to XML String format

2 Calculate MD5 hashXML Score String<?xml version="1.0" encoding="UTF-8"?> ....

4bff7d72b215445506ad1839e00208b3

3 Lookup in _scores hash table, insert if necessary

Key Value18438a34df... <?xml version="1.0"...3f923ad829... <?xml version="1.0"...21a118ed9f... <?xml version="1.0"...4bff7d72b2... <?xml version="1.0"...INSERT +

4 Insert into _bufferListKey Value1 18438a34df...2 3f923ad829...3 21a118ed9f...4 3f923ad829...5 4bff7d72b2...

Aliased Scores

INSERT +

Appendix E

Test Scripts

85

APPENDIX E. TEST SCRIPTS 86

Creating New Compositions

Test Script 1

Purpose Ensuring that pieces are represented correctly in the GUI

Test Steps

• Open Anton.

• Create a new composition and vary the wizard parameters, noting the choicesthat are made.

• This test should be repeated several times with different combinations of pa-rameters.

Expected Results

• Verify that these choices are correctly represented within the Score inspectorwindow.

• Ensure that the mode and style properties have been correctly applied by check-ing the score. The last chord should always be a tonic chord (based on theselected fundamental).

Relevant Iterations Iteration I, II, III

Test Script 2

Purpose Ensuring that no errors occur in the stages between the composition script andhow this is interpreted within the GUI

Test Steps

• Open Anton.

• Create a new composition and vary the wizard parameters, noting the choicesthat are made.

• Use the diagnosis facility.

• This test should be repeated several times with different combinations of pa-rameters.

Expected Results

• Verify that the diagnosis facility runs and that no errors are noted within thecomposition.



Import/Export Process

Test Script 3

Purpose Ensuring that the legacy import procedure works correctly

Test Steps

• Open Anton.

• Import one of the existing example scores from the appropriate Anton distribu-tion.

• Open up the LilyPond export from the same score, generated by the commandline version of Anton.

Expected Results

• Ensure that the score output (using a Score Window) from the Anton GUI andthe LilyPond export from the command line version of Anton are consistent.


Test Script 4

Purpose Ensuring that the XML import procedure works correctly

Test Steps

• Open Anton.

• Create a new composition, selecting some different composition parameters.Write down the selected parameters.

• Save the score in the Anton XML format.

• Close and reopen Anton.

• Load in the previously saved file.

Expected Results

• Ensure that the score inspector window lists the expected parameters for thescore.

• Ensure that the Arranger window shows the correct number of fragments.

Relevant Iterations Iteration II, III


Test Script 5

Purpose Checking compatibility of legacy import and XML export

Test Steps

• Open Anton.

• Import an existing legacy Anton score from the Anton distribution examplesfolder.

• Look at the score’s parameters and music notation in a ScoreWindow.

• Save the score as an Anton XML score.



Expected Results

• Ensure that the score inspector window lists the expected parameters for thescore.

• Ensure that the Arranger window shows the correct number of fragments.

• Ensure that the score looks the same in a ScoreWindow.


Test Script 6

Purpose Checking compatibility of legacy export

Test Steps

• Open Anton.

• Create a new composition with multiple parts.

• Run the diagnosis procedure and verify that the piece is valid.

• Export the score to the legacy Anton score format.

• Manually run the diagnosis procedure using the old Anton scripts on the ex-ported score file.

Expected Results

• Ensure that the diagnosis passes.



Test Script 7

Purpose Ensuring that ClefType import/export works correctly

Test Steps

• Open Anton.

• Create a new composition.

• Open up an inspector window for a particular track and change its ClefType toTenor / Alto.




Expected Results

• Ensure that the ClefType was correctly persisted.

• Ensure that the ScoreView component shows the correct ClefType.


Test Script 8

Purpose Manually verifying XML export

Test Steps

• Open Anton.

• Create a new composition and change several parameters including mode, style.

• In the Score inspector, set some values for the title and author (composer).

• Select some of the fragments and change their colours using the colour dropdown.Also change the name of all of the tracks to something different.


• Close Anton.

Expected Results

• Opening the created Score file in a text editor should reveal all of the settingsthat were changed.



Score Window

Test Script 9

Purpose Ensuring that multiple ScoreWindows can be opened

Test Steps

• Open Anton.

• Create a new composition with more than one part.

• Open up 10 Score Windows and select a different fragment in the user interface.

Expected Results

• Although performance will degrade with so many windows open, the ScoreWin-dows should all update as different fragments are selected.


Test Script 10

Purpose Testing ScoreWindow options work correctly

Test Steps

• Open Anton.


• Open up 3 ScoreWindows. In one window tick the “Entire Score” option, inanother choose the “Lock” option.

• Select another fragment in the user interface.

Expected Results

• Neither of the windows where options have been selected should change, theother ScoreWindow should update with the contents of the selected fragment.


Test Script 11

Purpose Checking that updates are propagated

Test Steps

• Open Anton.


• Load an existing composition.

• Open 3 ScoreWindows, check “Show Entire Score” and select one of the tracksin the Arranger View.

• With the ScoreWindows visible, edit the “Author” and “Title” properties in theScore inspector.

Expected Results

• After typing a new title / author and pressing enter, all of the ScoreWindowsshould be updated with the text that was typed into the inspector.


Test Script 12

Purpose Checking that updates are propagated #2

Test Steps

• Open Anton.


• Open a ScoreWindow and select one of these parts.

• Open the MIDI input window and hit the backspace key to delete several notes.

Expected Results

• After the input window has been closed, the score view should update instantlyto take into account the notes that were deleted.

Relevant Iterations Iteration III

Test Script 13

Purpose Checking that updates are propagated #3

Test Steps

• Open Anton.


• Open 2 ScoreWindows and select one of these parts.

• Choose the “Regenerate Fragment” toolbar button.

Expected Results

• After the regeneration process is complete, the ScoreWindows should both up-date with the new music.


• Please Note: Sometimes there are only a couple of different alternative piecesof music that can be generated to replace a fragment. As such, you might needto click “Regenerate” several times to find another viable alternative that ismusically distinct.


Test Script 14

Purpose Checking that score printing works

Test Steps

• Open Anton.


• Select one of the fragments and open a ScoreWindow.

• Choose the print button.

Expected Results

• Ensure that the print functionality works and that the printed material is afaithful representation of what is on screen.


Inspector Window

Test Script 15

Purpose Checking that changing parameters works correctly

Test Steps

• Open Anton.


• Select a fragment and open the inspector window.

• Try changing the track name and hitting enter.

Expected Results

• The associated track name in the arranger should update immediately.



Test Script 16

Purpose Checking that changing parameters works correctly #2

Test Steps

• Open Anton.



• Try changing the track colour.

Expected Results

• All fragments in the selected track should be updated with the colour that wasselected.


Test Script 17

Purpose Testing stale data

Test Steps

• Open Anton.



• Change some of the settings, including the track name / colour and ClefType.

• Import / Load an existing score file (any type of valid score).

Expected Results

• Ensure that the previous settings are wiped out and replaced with the settingsfor the loaded score.


MIDI Input Window

Test Script 18

Purpose Testing deletion functionality


Test Steps

• Open Anton.

• Import / Load an existing score file with multiple tracks (any type of validscore).

• Select one of the fragments, remembering its length in comparison to the othertracks.

• Open the MIDI input window.

• Hit backspace multiple times.

• Close the window.

Expected Results

• As backspace is pressed, the notes should disappear from the score view.

• Every time backspace is pressed, the score view should automatically be scrolledas far right as is possible, so that the end of the score is visible.

• After the input window is dismissed, the fragment in the arranger should bephysically shorter than it was previously.


Test Script 19

Purpose Testing MIDI Input Functionality

Test Steps

• Open Anton.


• Select a fragment and open the MIDI Input window.

• Plug in a MIDI controller supported by your machine (should already be in-stalled).

• Hit the Reload Inputs button.

Expected Results

• Ensure that the name of the MIDI controller is added to the drop down list.



Test Script 20

Purpose Testing MIDI Input Functionality #2

Test Steps


• Open Anton.



Expected Results

• The name of the MIDI controller should already be present within the MIDIdevices drop down list.


Test Script 21

Purpose Testing MIDI Input Functionality #3

Test Steps


• Open Anton.



• Select your MIDI controller from the list.

• Play a few notes on the controller.

Expected Results

• The notes should be recognised and added to the score view.

• Ensure that the pitches of the notes is correct.

• Ensure that the delay between playing notes and them appearing on the screenis not too large - it should be fairly responsive.



Composition Buffer

Test Script 22

Purpose Checking new entries can be added to the list

Test Steps

• Open Anton.


• Open the Buffer List window and select to add the score to the buffer.

Expected Results

• A new entry should be added to the buffer entitled “Score 1”.


Test Script 23

Purpose Restoring a previous entry

Test Steps

• Open Anton.



• Select a particular fragment and make a note of the music within this part.

• Regenerate this fragment.

• Select “Score 1” in the Buffer List and choose to restore it (using the green tickicon).

Expected Results

• A new entry should be added to the buffer entitled “Score 2” - which is theregenerated score

• The old score should be restored - verify that the music is restored.

• Please Note: Sometimes there are only a couple of different alternative piecesof music that can be generated to replace a fragment. As such, you might needto click “Regenerate” several times to find another viable alternative that ismusically distinct.



Test Script 24

Purpose Clearing functionality

Test Steps

• Open Anton.



• Open some more pieces (XML / legacy format) and store each in the buffer.

• Create a new composition and store this in the buffer too.

• Click on the rubbish bin icon in the Buffer List window.

Expected Results

• All entries in the list should be removed without any further prompts.


Test Script 25

Purpose Selective deletion

Test Steps

• Open Anton.



• Open some more pieces (XML / legacy format) and store each in the buffer.

• Create a new composition and store this in the buffer too.

• Highlight a randomly selected score in the list, hit the red cross.

Expected Results

• That entry should be removed from the buffer list without any further prompts.



Test Script 26

Purpose Maximum buffer size

Test Steps

• Open Anton.



• Keep on pressing the add button 10 times.

Expected Results

• Although the score number will keep incrementing, there should be a maximumof 8 entries in the buffer list.


Test Script 27

Purpose Score number resetting

Test Steps

• Open Anton.



• Keep on pressing the add button 10 times.

• Hit the rubbish bin icon.

• Add the score once more to the buffer list.

Expected Results

• The score numbering should be reset to “Score 1”.


Autofill

Test Script 28

Purpose Autofill with some measures removed


Test Steps

• Open Anton.

• Create a new, multi-part composition with length > 12 notes.

• Open the MIDI input window and delete all but a few notes.

• Close the MIDI input window.

• Ensure that this short fragment is selected and press the “Regenerate” toolbarbutton.

Expected Results

• After a few seconds the selected fragment should be resized to the same size asall of the other parts.

• Verify with the ScoreWindow that new music information is present in the pre-viously deleted region.


Test Script 29

Purpose Autofilling a complete piece

Test Steps

• Open Anton.

• Create a new, multi-part composition.

• Select any fragment.

• Press the “Regenerate” toolbar button multiple times.

Expected Results

• The music should never change for the selected part, no matter how many times“Regenerate” is pressed.


Test Script 30

Purpose Autofill an invalid score

Test Steps

• Open Anton.

• Choose to import one of the old-100th legacy scores from the examples folder ofthe Anton distribution.


• Select any fragment.• Press the “Regenerate” toolbar button.

Expected Results

• The regeneration process should fail with a descriptive error message as theold-100th pieces are not “musically valid” as defined by the supplied rule files.


General

Test Script 31

Purpose Save prompting

Test Steps

• Open Anton.• Create a new piece.• Attempt to close Anton.

Expected Results

• A warning prompt should ask whether you are happy to lose any unsavedchanges. Pressing Cancel should return you back to Anton, pressing No shouldterminate Anton and pressing Yes should prompt you to save the score.


Test Script 32

Purpose Save prompting #2

Test Steps

• Open Anton.• Create a new piece.• Using the MIDI input window, delete a few notes.• Attempt to create a new piece.

Expected Results

• A warning prompt should ask whether you are happy to lose any unsavedchanges. Pressing Cancel should return you back to Anton without any “NewComposition Wizard” appearing. Pressing No should open the “New Composi-tion Wizard” and pressing Yes should prompt you to save the score.



Test Script 33

Purpose Save prompting #3

Test Steps

• Open Anton.

• Create a new piece.

• Select a fragment and hit the “Regenerate” toolbar button.

• Attempt to open/import another piece.

Expected Results

• A warning prompt should ask whether you are happy to lose any unsavedchanges. Pressing Cancel should return you back to Anton without any opendialog appearing. Pressing No should open a file selection dialog and pressingYes should prompt you to save the score.


Test Script 34

Purpose Preference deletion

Test Steps

• Open Anton.

• Open the Preference Window and delete all of the settings.

• Try to compose a new piece.

Expected Results

• A warning prompt should appear at the end of the wizard telling you that itcan’t find one of the necessary settings.


Test Script 35

Purpose First welcome message

Test Steps

• Open Anton on a machine that has never run Anton before.


• Close Anton and reopen it.

Expected Results

• A welcome message should appear only on the first run.


Appendix F

Patches

103

F.1. PATCH TO PARSE.PL [1.5.0] 104

F.1 Patch to parse.pl [1.5.0]

82d81< my $note_value;363,365c362< my $fundamentalStr = $fundamental;< $fundamentalStr =~ s/\+/#/;< if ($noteNames[$i] eq $fundamentalStr) {---> if ($noteNames[$i] eq $fundamental) {687,688c684< $note_value = int($1) + $offset + (int($transpose) * 12);< print "choosenNote($part,$t,$note_value).\n";---> print "choosenNote($part,$t,$1).\n";

Appendix G

User Guide

105

User DocumentationGetting Started with Anton

Overview

Anton is an automated music composition package. It comes with built-in rules to compose pieces in species counterpoint, following the rules of Professor Markand Thakar. The supplied user interface allows new compositions to be made, loading previous compositions and a number of unique features.

Unique Features

Several unique features are included with Anton. Several of these features are detailed below.

Powerful Automated CompositionAnton can compose new pieces in species counterpoint in a variety of different formats (quartets, duets, trios, solos) and modes.

Score RegenerationUndesirable parts of the score can be marked for regeneration. Anton will attempt to compose new material to replace the selected fragment of music.

Composition BufferThe current Score can be saved at vital points, for example before a musical fragment is regenerated or deleted. The previously saved states can be restored at will. This can be particularly helpful if the regenerated piece of music, for example, is worse than the originally selected fragment.

DiagnosisA fully-integrated diagnosis procedure allows musical phrases that violate the species counterpoint rules to be easily identi"ed.

Other Features

MIDI InputThe algorithmically generated music can be extended with your own musical fragments inputted with a compatible MIDI controller.

Cross PlatformAnton is built for platform independence and runs on Windows, Mac OS X and popular Linux distributions.

Anton - Getting Started Guide - 2

This Document

This document helps users to get started with the basic steps of how to use Anton. There are several conventions in this document, reading this section will make these conventions clearer.

OS Speci"c InstructionsOperations that vary on different operating systems will be noted with a header of the operating system type, i.e:

Mac OS XRead here if you have Mac OS X

LinuxRead here if you have Linux

WindowsRead here if you have Windows

Command Line OperationsIn a couple of places within the instructions, you might be asked to type some commands in to the command line. The actual commands to type are written in a monospaced font, such as:

this is a command line command

Some commands require you to press enter after typing them in, such commands will end

with a return character ↵.

Please note: Any character after the return symbol (↵), particularly full stops, should be ignored and not typed in.

FilenamesFolders, "lenames and executable "les are also represented in a monospaced font.

Pre-Installation WarningThe developers of Anton can not take responsibility for any undesired side-effects that may result from the installation/use of Anton, installation/use of any of the dependencies or following any procedures noted within this document. While Anton has been rigorously tested on several platforms, we make no guarantees to the functionality of Anton.


Prerequisites

Before installing Anton and its prerequisites, please make sure you have read and fully understand the Pre-Installation Warning on the previous page.

WindowsPlease install the latest version of Strawberry Perl and note down the installation location of the perl binary (with the default installation settings this is usually: C:\Strawberry\perl\bin\perl.exe)

Linux & Mac OS XPlease open a terminal window (in OS X look in Applications > Utilities folder) and type:

which perl↵. Please note down the returned location (Likely to be /usr/bin/perl). On Linux, you either need to install Qt4.6.1 from source or ensure that it is available within one of your package repositories prior to installing Anton.

All PlatformsPlease download clasp and gringo for your platform from http://potassco.sourceforge.net/. You should also note down the location of the binaries.

You must also download the core Anton scripts from: http://www.cs.bath.ac.uk/~mjb/anton/. You should download version 1.5.0. Extract the contents of the downloaded archive and note the location of the extracted anton-1.5.0 folder.

Required Information

You should now have the following 4 pieces of information:

• Full path to perl binary• Full path to the gringo binary• Full path to the clasp binary• Full path to the extracted anton-1.5.0 folder


Installing Anton

To get started with Anton, you need to download the latest distribution for your operating system from http://www.github.com/henrythacker/.

WindowsAnton is supported on Windows platforms from Windows XP onwards. The Windows package has an integrated installer which will aid you through the installation process. Anton will be available within your Start Menu following the completion of the installation.

Mac OS XAnton has been tested on Snow Leopard (10.6), but should also work on Leopard (10.5) on both Intel and PPC computers. The Mac OS X package is bundled as a disk image. To install Anton, simply drag the Anton logo within the downloaded disk image to your Applications folder. Anton can then be launched directly from your Applications folder.

LinuxDEB and RPM packages are provided for easy Linux installation. Qt 4.6.1 (precise version) must be available for installation within your package manager or the installation will fail. After successful installation, you should be able to run Anton by calling anton from a terminal window.


File Location Settings

In order for Anton to work, it needs to know the location of the Anton scripts, clasp, gringo and perl. Failure to enter these settings will make a lot of the operations within the interface fail with an error.

1) Open Anton

2) Choose the Preferences menu option from Edit → Preferences (Windows / Linux) or Anton

→ Preferences (Mac OS X).3) Enter the "le locations you noted down in the Prerequisites section of this document4) Choose the OK button


Getting Started

Here is a list of the main features which are discussed in this guide.

• Creating a New Composition covers the basics of generating a new algorithmic composition• Viewing the Score covers some of the features present in the Score View• Diagnosing Scores discusses the score diagnosis feature• The Buffer List gives a brief overview of how the composition buffer is used• Regenerating Fragments looks at how fragments may be regenerated• Extending Fragments talks about using deleting notes and the use of MIDI Input in Anton


Creating a New Composition

To generate a new score, please choose the File → New menu option, a wizard will be presented. Please select the options that you want for your score and press Continue when you are done.

After you have answered the questions for the second step (Fundamental, Transposition) please choose Done.

The Wizard will disappear and the Anton scripts will generate the new piece. Depending on the settings you have chosen, this can take anywhere from 2 seconds to over an hour.

After the composition process is complete, the generated track will be shown in the Arranger.


Viewing the Score

The entire score, or a portion of it can be viewed by opening a new Score View by using the button on the toolbar above the Arranger.

Multiple Score Windows may be opened simultaneously. The contents of the Score Window will update as you click a different track within the Arranger. If you do not wish a particular Score Window to update as you change tracks in the Arranger, you can tick the Lock Score Window option in any given Score Window.

If you want a Score Window to display the contents of all tracks together, you can choose the Show Entire Score option.

Scores can also be printed using the Print button in this view.

This view can also be docked anywhere within the main Arranger window.


Diagnosing Scores

The score diagnosis facility is accessed by choosing the Diagnose option on the main toolbar. You do not have to have anything selected, you may choose the option at any time.

The Anton scripts will be called and the diagnosis will be carried out. This may take a variable amount of time depending on the complexity and length of the score.

If errors are present in the score, the composer has the ability to drill down into the errors that were encountered. Each error gives a description and the location of the note within the piece.


The Buffer List

The Buffer List provides the composer the ability to snapshot the current state of a score at a given point in time.

The Buffer List is accessed by selecting the Buffer List toolbar option.

The green addition button is used to add the current score into the buffer

The red deletion button is used to remove the currently selected score from the buffer

The rubbish bin icon is used to remove all scores from the buffer.

The green tick button will restore the currently selected score. The current score you are working on is saved into the buffer before the old score is restored.

The Buffer List supports a maximum of 8 scores at any one time.

The Buffer List is not saved along with the "le and is lost when Anton is closed.


Regenerating Fragments

The Fragment Regeneration tool allows for a particular fragment of music to be replaced with another.

You may wish to use the Buffer List in concert with this function, just in case the regenerated fragment is worse than the previous fragment.

Prerequisite: Your piece must be musically valid (by Anton’s de"nition) or the regeneration process will fail

1) Select a fragment in the Arranger

2) Choose the Regenerate button on the toolbar3) This process will take a while depending on the length and complexity of the music.4) If no errors occur, the piece of music will have been changed. Otherwise an error message

will be displayed

Please Note: Occasionally there may only be a single valid replacement for a piece of music, so the Diagnosis operation may appear to do nothing. Run the procedure several times if the music does not appear to change after the "rst attempt.


Extending Fragments

Fragments may be extended by using MIDI input.

Prerequisite: In order to be used within Anton, the MIDI controller must be compatible with the host operating system and have all of the necessary drivers / software installed prior to starting Anton.

To input new musical material, it must be added to an existing fragment.

1) Plug in a USB / Firewire MIDI device2) Start Anton3) Compose / Load a new piece4) Select an existing fragment in the Arranger5) Choose the Extend Fragment toolbar button6) Select the required MIDI controller from the drop-down menu. The list of MIDI controllers

can be refreshed at any time by pressing Reload Inputs7) Play notes and they will appear at the end of the score view

Notes may also be deleted, but only from the end of the score. Hitting backspace will delete the last note that was entered.


Appendix H

Source Code

Please find the source code on the enclosed CD-ROM. The SOURCEFILES file in the root ofthe CD-ROM describes the layout of the source code tree.

119

A musician-oriented graphical user interface for …mdv/courses/CM30082/projects.bho/2009-10/... ·...

Documents

Transcript of A musician-oriented graphical user interface for …mdv/courses/CM30082/projects.bho/2009-10/... ·...