Read Anytime Anywhere Easy Ebook Downloads at ebookmeta.

com

Music Representation and Transformation in

Software: Structure and Algorithms in Python 1st
Edition Donald P. Pazel

https://ebookmeta.com/product/music-representation-and-
transformation-in-software-structure-and-algorithms-in-
python-1st-edition-donald-p-pazel/

OR CLICK HERE

DOWLOAD EBOOK

Visit and Get More Ebook Downloads Instantly at https://ebookmeta.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Mousetrap Structure and Meaning in Hamlet 1st Edition P J

Aldus

https://ebookmeta.com/product/mousetrap-structure-and-meaning-in-
hamlet-1st-edition-p-j-aldus/

ebookmeta.com

Data Structures & Algorithms in Python John Canning

https://ebookmeta.com/product/data-structures-algorithms-in-python-
john-canning/

ebookmeta.com

Pro Machine Learning Algorithms: A Hands-On Approach to

Implementing Algorithms in Python and R 1st Edition V
Kishore Ayyadevara
https://ebookmeta.com/product/pro-machine-learning-algorithms-a-hands-
on-approach-to-implementing-algorithms-in-python-and-r-1st-edition-v-
kishore-ayyadevara/
ebookmeta.com

Practical Career Advice for Engineers: Personal Letters

from an Experienced Engineer to Students and New Engineers
1st Edition Radovan Zdero
https://ebookmeta.com/product/practical-career-advice-for-engineers-
personal-letters-from-an-experienced-engineer-to-students-and-new-
engineers-1st-edition-radovan-zdero/
ebookmeta.com
The Tell Tale A Small Town Enduring Love a Web of Secrets
1st Edition Clare Ashton

https://ebookmeta.com/product/the-tell-tale-a-small-town-enduring-
love-a-web-of-secrets-1st-edition-clare-ashton-2/

ebookmeta.com

Birds of New Jersey Field Guide 2nd Edition Stan Tekiela

https://ebookmeta.com/product/birds-of-new-jersey-field-guide-2nd-
edition-stan-tekiela/

ebookmeta.com

Dad Bod Lumberjack Dad Bod Men Built For Comfort 1st
Edition Gia Bailey

https://ebookmeta.com/product/dad-bod-lumberjack-dad-bod-men-built-
for-comfort-1st-edition-gia-bailey/

ebookmeta.com

Following the Northern Star Caribbean Identities and

Education in North American Schools Caribbean Identities
and Education in North American Schools 1st Edition Greg
Wiggan
https://ebookmeta.com/product/following-the-northern-star-caribbean-
identities-and-education-in-north-american-schools-caribbean-
identities-and-education-in-north-american-schools-1st-edition-greg-
wiggan/
ebookmeta.com

Snowed in With the Grump 1st Edition Kat Baxter

https://ebookmeta.com/product/snowed-in-with-the-grump-1st-edition-
kat-baxter/

ebookmeta.com
Renewable energy conversion systems: Technologies, Design
and Operation 1st Edition Kamran Muhammad

https://ebookmeta.com/product/renewable-energy-conversion-systems-
technologies-design-and-operation-1st-edition-kamran-muhammad/

ebookmeta.com
Donald P. Pazel

Music
Representation
and Transformation
in Software
Structure and Algorithms
in Python
Music Representation and Transformation in Software
Donald P. Pazel

Music Representation
and Transformation in Software
Structure and Algorithms in Python
Donald P. Pazel
Fishkill, NY, USA

ISBN 978-3-030-97471-8 ISBN 978-3-030-97472-5 (eBook)

https://doi.org/10.1007/978-3-030-97472-5

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2022
This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole or part of
the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting,
reproduction on microfilms or in any other physical way, and transmission or information sto rage and retrieval, electronic
adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even
in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore
free for general use.
The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true
and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied,
with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains
neutral with regard to jurisdictional claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface

Introduction

Suppose you have an interest in programming computer music and need a starting point. Perhaps you
have tried various music applications or tools, such as mixers, production systems, or notation systems,
but feel a need to dig deeper, to be more hands-on and work with music fundamentals. Perhaps you
have familiarity with concepts of musical notes, keys, chords, scores, and other music elements, but
you don’t know where to begin in designing and programming about them, let alone translating them
to MIDI®1. You want to be able to put all those elements to work through programming, but you need
direction to get to that next killer music app that you have in mind. This book guides you to that sweet
spot of developing and using your programming skills to design and build systems about music.
However, this book does more than provide that kind of instruction. This book takes the reader on a
journey through music concepts in an organized approach that develops music essentials, from the
concepts of tone, pitch, and time, through notes, intervals, chords, and scores while at the same time
interpreting these elements as software artifacts. As these many concepts are covered, we do so with
close attention to the organization of and relationships amongst these concepts and reflect those as
Python classes and objects, and so learn about music from a software design viewpoint. By this process,
we approach this design in a logical and structured way.
The objective for doing this is to make music theory elements programmatically accessible. The result-
ing software should allow you to be able to code in the language of music, letting you to think primarily
in musical concepts about your programming objectives, while leaving various music calculations,
such as key or chord construction, transparent. That is the point behind the software discussion on
music representation in the first part of this book.
The second part of the book is devoted to music transformation algorithms. These transforms comprise
an interesting application of music representation for modifying music through key change, melodic
reflection, and much more. This part of the book is more academic and has more of a research feel.
However, the connection to programming prominently remains with discussions grounded in

1
MIDI is a registered trademark of the Association of Manufacturers of Electronic Instruments
(AMEI).

v
Preface

implementation details and software structure considerations. We hope the reader finds inspiration in
this section for novel applications or advanced interests in the wide area of computer music research.

The Origin of this Book

The origin of this book has its roots in the late 90's. At that time, I had the honor of being a member of
a computer music research team at IBM®2 TJ Watson Research Center in New York. This department
should not be confused with being a club of musicians that jammed after work. Rather, the Computer
Music Center (CMC) focused on MIDI-based composition software and real-time music modification
as full-time work in the Mathematics Department of this esteemed IBM research center. The depart-
ment was technically and principally led by computer music veterans Danny Oppenheim and Jim
Wright. During my tenure there we constructed MusicSketcher [1], a prototype application that demon-
strated a wide range of music transformational capability, including dynamic chord replacement, and
harmony preserving dynamic note shifts, and other capabilities. These transformations went by the
name Smart Harmony [2]. My work experiences in this department served as an introduction to com-
puter music, MIDI, and various music tools. The novelty and creativity behind the work there was very
impressive, and I found the talks, works, and efforts there stimulating in ideas.
Many years and many different careers later, along with finally having freedom of time, I decided to
take a fresh look at a few ideas in computer music research, but now in the context of some 20 to 30
years of technological change. The prior work with which I was familiar was preserved in papers and
memory. This forced me to think through from scratch the foundations for music representations and
transformational capabilities. Additionally, instead of using C/C++ as we had years earlier, I now have
access to Java or Python, computer languages with which I have become more adept through my pro-
fessional industrial experiences. Computing hardware also improved considerable over time. Further,
VST®3 digital audio provided advanced capability in MIDI rendering and provided access to rich
sound samples which are currently plentiful in the market.
I considered building on an idea for music collaboration that I thought about while I was in the CMC
long ago [3]. The idea was to allow multiple people to log into a group-based music session, choose
instruments, insert riffs or melody lines, and dynamically modify them in real time collaboratively. As
I moved forward on this idea, the effort took on many technical challenges. Firstly, and most im-
portantly, I needed a rich flexible music representation with functionality that translates into MIDI and
music performance dynamics. While I thought this was my main concern, I quickly learned that there
are many other critical features outside of music to address. As this project was designed to have a
web-based front end and significantly, real-time collaborative interaction, it required a coordinating
server as well. After much effort, I achieved a prototypical result that was very close to what I wanted.
Multiple players could engage in music performance through a web interface as a shared experience,
much in the way I envisioned. A tune is composed on a shared (web-based) screen using selectable
multi-measure music fragments stitched together. The players take on different instrument roles, say
one on drums, another guitar, etc. Once the playback started, each player controls their instrument’s
pitch (while automatically maintaining harmony) and volume levels. The tempo and harmony (chords)
are also adjusted in real time through a special “conductor” role. A server takes care of all the interac-
tivity and music dynamics, and ensures the players are relatively synchronized to a unified experience.
As these features became demonstrable, the key question became "Where to go from here?" A question
that remains unsettled still. Even as I contemplated the work’s uncertain future, there remained a nag-
ging consideration that I had reluctantly been putting off and needed to consider.

2
IBM is a registered trademark of International Business Machines.
3
VST is a trademark of Steinberg Media Technologies, GmbH.

vi
 Prerequisites and Approach

The problem which with I struggled was that this project was simply too massive for one person to
contain within reasonable time. Although initially I focused on building a proper music representation,
I quickly became absorbed with server architecture details, distributed playback algorithms, client syn-
chronization, web interfaces (JavaScript), and general maintenance. Quickly, the core music represen-
tation became brittle and sketchy with the load of work. What started as a music project, became more
of a “soup to nuts” web application project, a terribly interesting one, but one that left scarce time and
energy for addressing the increasingly insufficient core music representative and transformative issues
on which I wanted and needed to spend much more time and energy.
I took a break from the project for reflection, to reexamine the work that had been done, determine how
to improve upon it, and see to where that circumspection leads. As I realized early on, music represen-
tation is a deep and interesting software modeling exercise in itself. The intuitive concepts of music
require rigorous definition. The closer I looked, it seemed that although we are generally adept with
many music concepts like intervals, scales, chords, and the like, our understanding of these are some-
what superficial and at times not so well structured, if not incomplete, and rough around the edges. It’s
like the many skills we adopt from rote learning. We work with certain skills daily but don’t think
deeply about them nor even understand their foundations with much clarity. Looking at the music
representation I had developed, I found needless complexity that seemed to come more from lack of
foundation (from admittedly a rush to get that component finished as an expense for other needs) than
say sloppy code.
Yet another important aspect surfaced, that music representation comes with a set of algorithms that
are in fact, genuinely interesting. The computation of scales, computing interval end notes, and similar,
are interesting topics, that in a thought-provoking way made me question how as a musician I had done
those things, and if there are better ways to think about those topics, especially, when designing soft-
ware to manipulate them. As an example, the notion of time in music is interesting, that along with the
varied temporal representations comprises an interesting study, including the conversions of one tem-
poral representation to another. It is interesting to think about the properties of a musical note, to ques-
tion why we limit to specific durations, and pitches. These are just a few examples of what came to
light. It speaks to the larger issue of questioning our understanding of music, what restrictions might
be too rigid, and if anything can be done to lessen those restrictions.
I never returned to that initial distributed application. Instead, I decided to focus on music representa-
tion, the related foundational algorithms, and eventually to music transformational issues, from the
perspective of a software engineer and to some degree, a mathematician. This turn of focus resulted in
a sizeable body of study and code that is detailed in this book. The result is a far more fulfilling adven-
ture than I could have imagined.
This experience is what led me to writing this book. After years of working solely on music represen-
tation, and years looking at how to build transformational algorithms with that representation, I thought
I would share that experience here in hopes of motivating others to carry on and perfect that effort and
inspire people towards efforts in computer music.

Prerequisites and Approach

Readers are expected to have basic programming skills, and some familiarity with Python. This in-
cludes familiarity with computational statements, logical structures such as if and loop (for/while)
statements, and function or procedure definitions with calling protocols, including parameter passing.
Also, a familiarity with the concepts of list and dictionary (or maps), embodied as Python lists and
maps or dicts, is also assumed. Unlike many topical introductory books with claims to programming
or a specific programming language training, this book assumes basic programming skills in Python.
If needed, there are many excellent books for learning Python such as [4] [5] or online references such
as [6].

vii
Preface

The reader should have some loosely defined notions of musical elements. That is, the reader should
have notions about what notes, intervals and chords are. However, the book is built around introducing
all these concepts in a methodical structured way. So, unlike the programming prerequisites, the music
prerequisites are less strict.
Object-Oriented design skills are not required but are a critical part of the book’s teachings. This book
places a heavy emphasis on learning object-oriented (O-O or OO) design and thinking. Designing in
an object-oriented manner forces one to step back from a problem space, and pull apart the concepts
and their dependencies, and make judgments on how to approach a programming task. It forces devel-
opers to:

• code a software model that clearly maps to the problem domain’s conceptual model, and in a sense,
“talks in its terms”.
• reflect relationships and dependencies directly in the software model that are relevant in the do-
main’s conceptual model.
• keep in mind efficiencies and inefficiencies, or limitations of programming artifacts used in the
software model.
• stretch for generality where needed, but within reasonable bounds.
What the reader should realize is that like with so many software endeavors, the software design pro-
cess never ends. This is particularly so with the music domain, with, for example, the introduction of
different instruments, different styles of music, and so forth, each introducing their own conceptual
needs. We do not claim to present in this book the best possible music representation but do believe
this model goes a long way on generality and will change over time to be more inclusive, and to intro-
duce the reader to software design in the object-oriented style.
Since music many times involves calculations, especially involving dynamics over time, some mathe-
matics is involved. The reader should be able to understand simple equations for calculations and sim-
ilar and be capable of translating these into code.

What this Book is Not About

As important as describing what this book is about, is mentioning what it is not about. Importantly, this
is not a book about music notation, nor how to build music notation software. Music notation for sure
is important and related to the topic of this book. Notation concerns the visual and textual communi-
cation of music content and instruction for performance. Consequently, notation incorporates a map-
ping of music concepts to text/symbol and/or visa-versa. This book’s concern is with embodying music
concepts as software model objects, something more abstract that could be useful in building a music
notation system but is not one in and of itself. By the way, there are numerous exemplar music notation
systems on the market: Dorico®4, Sibelius®5, Notion®6, and Finale®7 to name a few. As a warning to
more ambitious readers, building a music notation editor is a herculean effort. Entire teams of devel-
opers and testers are actively devoted to such endeavors with extensive time and resource commitments
by a few companies.
Secondly, this is not a book about building MIDI rendering software. MIDI and some of its important
aspects and translation of music models to MIDI are described in detail here and provide a useful

4
Dorico is a registered trademark of Steinberg Media Technologies GMbH.
5
Sibelius is a registered trademark of Avid Technology Europe LTD.
6
Notion is a registered trademark of Presonus Expansion, L.L.C.
7
Finale is a registered trademark of MakeMusic, Inc.

viii
 Intended Audience

educational introduction for readers interested in learning about MIDI. However, construction of MIDI
rendering software is a topic unto itself and is outside the scope of this book.

Intended Audience
A wide variety of readership is envisioned for this book. Primarily it is for students to accelerate their
software development capabilities in designing and building music software. With that, we offer the
following thoughts for the varied reader constituency:

Students
Students should take seriously the technical prerequisites. It is important to be able to program proce-
durally in some programming language. If you already know Python, fine. If not and you pick up
programming languages easily, fine. However, knowing the basics of Python is the expectation of this
book. The book also delivers an introduction to object-oriented principles and how to program to them
in Python. The book applies object-oriented principles to varied music elements and accelerates in
depth rapidly. The algorithms, even in the representation section at times can be complex and intricate,
and in some cases are expressed in mathematical formulae which the user should be able to understand
and translate to code.
In a few instances, advanced computer science concepts are discussed, for example, red-black trees
and constraint engines. Students need not understand the implementations of these concepts in detail,
but should concentrate in understanding the features they provide, how to use them, their interfaces,
and chiefly their strengths and limitations. The more intrigued student may want to invest more time
on theory and implementation details in these areas.
While the primary focus for entry-level students should be on the representation part of the book, the
transformation part could be of great interest and well-worth reading. It comprises a combination of
practical applications of music representation and an introduction to constraint management. Students,
if not guided by an instructor, should read through the transformations and at least understand what
they contribute musically, and understand them technically as best can. Reading through the many
examples should help in providing this understanding.
For representation chapters, the end of chapter questions are mostly for provoking thought about the
range in complexity of what is presented. The student is encouraged to read through the questions and
select a few (if not assigned by the instructor) to think through as best can. For the transformation
chapters, each chapter ends with a “final thoughts” section which highlights both positive and less than
positive aspects of the chapter’s topic. It is meant to be thought provoking, and fuel for further efforts.

Instructors
Instructors can consider using this book for a one semester course on computer music programming.
The representation part could easily occupy a semester. For classes comprised of students with lower-
level programming skills, the instructor could augment the course with a robust Python review. That
said, it is recommended to spend a good deal of time on object-oriented concepts and how to code
Python to an object-oriented methodology. After that, the book can be followed chapter to chapter with
the idea of introducing new music concepts in succession, along with representation and coding prin-
ciples.
If the semester has more time to offer, one can consider introducing topics from the transformation
section, with at least a guide through the transformations and examples. The constraint engine itself
can be technically demanding for students, and the instructor can defer on its implementation details,
and instead highlight its interface and usage. The constraint engine is an interesting topic, and advanced

ix
Preface

students may want to consider augmenting or working with it as an advanced project in this or other
domains.
Practitioners
Practitioners may come to this book for a variety of reasons, and in a variety of ways. If you want to
learn how to approach object-oriented programming with computer music as a domain, then a straight-
forward read is recommended. Otherwise, treating it as a reference text, picking and choosing chapters
in the representation section is useful.
As for the transformation section, there are many topics from which to choose. A few of the transforms
make use of the constraint engine, but many don’t. It is a matter of looking through the transform types
to determine which topics might be of interest.
Experienced Researchers
Experienced researchers may generally find the representation section less interesting than the trans-
formation section, except perhaps for the later chapters of the representation section concerning varia-
ble dynamics and harmony representation. We would expect this audience to be more interested in the
transformation section of the book, on which there are a wide range of topics to study and expand upon.

Regarding the Musical Examples

The reader will find an abundance of musical examples. While music written on a page is not as satis-
fying as listening to it, there are several ways to listen to them.
• Use the score to midi conversion code discussed in this book to generate MIDI files and play
the examples on a MIDI player of choice.
• Although not covered in this book, there is a primitive VST host referenced in the code base
that can be used with Python interface code in the code base.
• The author found copying generated music to a notation application with playback is very
practical and useful, and allows for quickly changing an example’s dynamics, tempo, etc.
• Hands-on playing examples on a musical instrument.
The author is aware that many books of this type go through great effort to provide support for MIDI
playback. The decision was made to invest effort on the main ideas of this book on music representation
and transformation, even at the expense of not providing what would at best be a poorly functional
MIDI playback software package that would only detract from the learning experience.

About the Software

As a bonus this book is associated with an accessible software package that reflects the work of this
text. This software can be found at:
https://github.com/dpazel/music_rep
This software package reflects the class hierarchy and details described throughout this text. It is cov-
ered by MIT license with no guarantees nor warrantees.

x
 About the Software

Readers are encouraged to copy the code locally to their computers and use a programming IDE like
Eclipse®8 or PyCharm®9 to review the code while working through related sections of the book. Im-
portantly, please review the “readme” file which instructs which related software packages (Python
packages) are required for the code to build and run. There are ample unit tests as well in the package
that the reader may find useful towards understanding the code and concepts. The code base uses some
interesting external packages which should be educational and useful to software engineering students.
It is emphasized that running examples in debug mode may be the best way for learning and exploring
the ideas in this book.
Bear in mind that the software was developed from a research viewpoint. The conceptual model on
music was developed with two ambitions. One was to develop a music software model that encapsu-
lates in logical development most basic music theoretical elements. Also, the model’s developmental
aim is to provide a foundation capable of enabling transformations, and in doing so prove strong enough
to sort out a transform’s strengths and limitations that a simpler model might not be able to do.
However, the code is less than industrial in strength and robustness! That is, one is likely to find missing
features or outright errors, or even some intentional missing elements meant for exercises. The code
may occasionally be improved upon over time, so it would be in the readers’ interests to periodically
check for updates.
It is my hope that readers find this book more than helpful in their programming or music careers or
general educational endeavors, but also find the book thought-provoking, stimulating, and encouraging
for interests in computer music programming and research.
To all who venture here, Best of Luck!
Donald P Pazel,
Fishkill, NY
January 2022

8
Eclipse is a registered trademark of Eclipse Foundation, Inc. Ref. http://www.eclipse.org
9
PyCharm is a registered trademark of JetBrains s.r.o. Ref. https://www.jetbrains.com/pycharm

xi
Preface

Acknowledgements
Parts of this text were produced using the MusiSync font, © 2001, 2008 by Robert Allgeyer, SIL Open
Font License10. Also, the overwhelming majority of musical examples were constructed in and figures
extracted from personal Dorico projects.
There are many people who introduced me to the study of computer music, and the problems and issues
behind representing music in software. Of course, much of that starts with the Computer Music Center
members at IBM Watson Labs and especially to Danny Oppenheim and Jim Wright who together em-
bodied the spirit and mind of the project, and Robert Fuhrer, as well as the manager David Jameson,
our fearless tester David Speck, and Jim Cate in a production role. However, a special thanks to Steven
Abrams who as the newly minted manager at the time, served as a crucial catalyst and contributor for
ideas and progress that resulted in pulling together the best ideas in the group, including Smart Har-
mony. Many of these ideas provided inspiration for the follow-on work in this text, and a few of those
seed ideas are borrowed and cited appropriately. I offer my thanks and appreciation to Dr. William R.
Pullyblank for sponsoring that effort as part of his Mathematics department.
Many thanks go to Aries Arditi for many directional conversations and for his review and suggested
changes to the document, and similarly to Daniel Spreadbury and Roger Dannenberg for their kind
reviews. Also thanks to Dr. Stephen Andrilli of LaSalle University for his continued encouragement,
and to Brian Hinman for his sage counsel.
Also, I would be completely lost in this endeavor were it not for the strong musical influences in my
life. I studied piano for many years with Ralph Burkhart who taught me the foundations of music
theory, music performance technique, and music appreciation. Also Dr. Ruth Schonthal taught me
foundations and appreciation for music composition. Both Ralph and Dr. Schonthal are now gone and
are very much missed. I hope they understood how totally in awe of them I am. After many years of
absence from piano, in recent years I continued piano study with Jennifer Gallant Lopez who led me
to an awakening of a renewed appreciation of great music and performance. Also, many thanks to Amy
Baglione for introducing me to the rudiments of jazz and beyond.
A special thanks to Ralf Gerstner, executive editor at Springer, for taking on this book and for his
patient shepherding and steady hand through the publication process.
Some influences are long lasting and unforgettable, and come from a different and indeed magical time
of my life. I am deeply indebted to Br. Hugh Albright of LaSalle University, Philadelphia. His ethereal
yet profound way of conveying the beauty of mathematical abstraction left a lasting influence, and a
life-long love and respect for mathematics. As well, Dr. Thomas Kriete of the University of Virginia
taught me the importance of rigor and clarity of presentation for instruction. I am grateful for their
belief in me. I could only hope that some of those influences show through here.
And the best for last, with love for my wife Joan for the time and patience for making this book happen.
My love and best friend forever!

10
The SIL Open Font License is completely free for personal and commercial tasks. And you don’t
need to pay any single penny for utilizing them commercially. Also, if you get some other license like
OFL, Public domain, and 100% free. They are also free for commercial uses.

xii
Contents
PREFACE ................................................................................................................................... V
INTRODUCTION ................................................................................................................................. V
THE ORIGIN OF THIS BOOK .................................................................................................................. VI
PREREQUISITES AND APPROACH .......................................................................................................... VII
WHAT THIS BOOK IS NOT ABOUT ....................................................................................................... VIII
INTENDED AUDIENCE ......................................................................................................................... IX
REGARDING THE MUSICAL EXAMPLES ....................................................................................................X
ABOUT THE SOFTWARE .......................................................................................................................X
ACKNOWLEDGEMENTS ...................................................................................................................... XII
CONTENTS ..............................................................................................................................XIII

PART 1: REPRESENTATION ......................................................................................................... 1

1 SOFTWARE MODELING AND OBJECT-ORIENTED DESIGN ..................................................... 3

1.1 OBJECT-ORIENTED DESIGN BY EXAMPLE ..................................................................................... 3
1.2 A CONCISE INTRODUCTION TO PYTHON CLASSES .......................................................................... 6
1.3 WHAT CAN GO WRONG IN OBJECT-ORIENTED DESIGN ................................................................. 8
1.4 THE MEANING OF MUSIC REPRESENTATION ................................................................................ 9
2 THE CHROMATIC SCALE AND THE DIATONIC FOUNDATION .............................................. 11
2.1 THE PYTHAGOREAN SCALE ..................................................................................................... 11
2.2 JUST INTONATION AND EQUAL-TEMPERED CHROMATIC SCALES .................................................... 13
2.2.1 The Chromatic Scale Representation ...................................................................... 15
2.3 TONES, PITCHES, AND THE DIATONIC FOUNDATION .................................................................... 17
2.3.1 Diatonic Tone Representation ................................................................................. 19
2.3.2 DiatonicToneCache ................................................................................................. 21
2.3.3 Diatonic Pitch Representation ................................................................................. 22
2.4 EXERCISES .......................................................................................................................... 23
3 INTERVALS........................................................................................................................ 25
3.1 WHAT IS A MUSIC INTERVAL? ................................................................................................ 25
3.1.1 Compound Intervals ................................................................................................ 28
3.1.2 Interval Inversion .................................................................................................... 29
3.2 INTERVAL ANALYTICS ............................................................................................................ 29

xiii
Contents

3.2.1 Negative Intervals ................................................................................................... 30

3.2.2 Interval Reduction ................................................................................................... 31
3.2.3 Inversions ................................................................................................................ 32
3.2.4 Interval Addition ..................................................................................................... 32
3.2.5 Afterword on Interval Operators ............................................................................. 33
3.3 INTERVAL REPRESENTATION AND IMPLEMENTATION ................................................................... 34
3.3.1 Negation, Inversion, and Reduction ........................................................................ 35
3.3.2 Interval Addition and Operator Overloading .......................................................... 35
3.3.3 Exceptions ............................................................................................................... 37
3.3.4 Computing Start and End Pitches ............................................................................ 38
3.4 EXAMPLES .......................................................................................................................... 38
3.5 EXERCISES .......................................................................................................................... 39
4 MODALITY, TONALITY, AND SCALES.................................................................................. 41
4.1 MODALITY AND TONALITY ..................................................................................................... 41
4.1.1 A Traditional Approach to Modality ........................................................................ 42
4.1.2 An Intervallic Approach to Modality ....................................................................... 43
4.1.3 Counterexamples .................................................................................................... 44
4.1.4 Modes, Derived Modalities and Modal Index ......................................................... 45
4.2 MODALITY AND TONALITY REPRESENTATION ............................................................................. 46
4.2.1 Defining and Creating Modality .............................................................................. 47
4.2.2 System Modalities ................................................................................................... 48
4.2.3 Modality Factory ..................................................................................................... 49
4.2.4 Modal Index, Incremental Intervals, and Tonal Scale ............................................. 50
4.2.5 Tonality Representation .......................................................................................... 50
4.2.6 Pitch Scales.............................................................................................................. 52
4.3 EXERCISES .......................................................................................................................... 53
5 TIME IN MUSIC ................................................................................................................. 55
5.1 THREE NOTIONS OF TIME IN MUSIC, AN INTRODUCTION .............................................................. 55
5.2 WHOLE NOTE TIME: MEASURING TIME IN FRACTIONS ................................................................ 56
5.3 TIME SIGNATURE AND TEMPO ................................................................................................ 57
5.3.1 Time Signature ........................................................................................................ 58
5.3.2 Tempo ..................................................................................................................... 58
5.4 WHOLE TIME / ACTUAL TIME CONVERSIONS ............................................................................. 59
5.5 WHOLE TIME / BEAT TIME CONVERSION .................................................................................. 61
5.6 REPRESENTATIONAL CONSIDERATIONS ..................................................................................... 63
5.6.1 Whole Note Time Representation ........................................................................... 64
5.6.2 Position and Duration ............................................................................................. 64
5.6.3 Beat Position ........................................................................................................... 65
5.6.4 TimeSignature and Tempo classes .......................................................................... 66
5.6.5 The Time Conversion Algorithms............................................................................. 67
5.7 EXERCISES .......................................................................................................................... 69
6 THE NOTE AND NOTE AGGREGATES .................................................................................. 71
6.1 NOTES AND THEIR AGGREGATIVE PARTNERS ............................................................................. 71
6.1.1 The Note .................................................................................................................. 71
6.1.2 Beams...................................................................................................................... 73
6.1.3 Tuplets..................................................................................................................... 73

xiv
 Contents

6.2 REPRESENTATION ................................................................................................................. 74

6.2.1 The Note Inheritance Hierarchy .............................................................................. 74
6.2.2 Semantic Clarifications ............................................................................................ 81
6.3 ALGORITHMS ...................................................................................................................... 83
6.3.1 Accessing Notes ...................................................................................................... 83
6.3.2 Adding a Note ......................................................................................................... 84
6.3.3 Reversing a Melody ................................................................................................. 87
6.4 EXERCISES .......................................................................................................................... 88
7 CHORDS............................................................................................................................ 89
7.1 A BRIEF INTRODUCTION TO CHORDS ........................................................................................ 89
7.1.1 Tertian Chord Types ................................................................................................ 90
7.1.2 Secundal Chord Types ............................................................................................. 90
7.1.3 Quartal Chord Types ............................................................................................... 91
7.1.4 Secondary Chord Types ........................................................................................... 91
7.2 CHORD TEMPLATE AND CHORD REPRESENTATION ...................................................................... 92
7.2.1 Template and Chord Class Design ........................................................................... 93
7.2.2 Chord Construction ................................................................................................. 93
7.3 CHORD CATEGORIES: SYNTAX AND EXAMPLES ........................................................................... 95
7.3.1 Tertian Chords ......................................................................................................... 96
7.3.2 Secundal Chords ...................................................................................................... 97
7.3.3 Quartal Chords ........................................................................................................ 98
7.3.4 Secondary Chords .................................................................................................... 99
7.4 EXERCISES ........................................................................................................................ 100
8 INSTRUMENTS ................................................................................................................ 103
8.1 A SIMPLE GENEALOGICAL MODEL FOR INSTRUMENTS ............................................................... 103
8.2 A SOFTWARE MODEL FOR AN INSTRUMENT CATALOG ............................................................... 105
8.3 THE INSTRUMENT CATALOG CLASS MODEL ............................................................................. 105
8.3.1 Articulations .......................................................................................................... 107
8.3.2 Accessing Instrument Data ................................................................................... 107
8.3.3 The Instrument Catalog as Persistent Data........................................................... 109
8.3.4 Instrument Catalog Initialization .......................................................................... 111
8.4 EXERCISES ........................................................................................................................ 112
9 SCORE REPRESENTATION ................................................................................................ 115
9.1 WHAT IS A MUSICAL SCORE? ............................................................................................... 116
9.2 SCORE AS A CLASS MODEL ................................................................................................... 117
9.2.1 Voices and Lines .................................................................................................... 118
9.2.2 Event Sequences for Tempo, Time Signature, and Dynamics ................................ 121
9.2.3 What Happened to Key Signature? ....................................................................... 123
9.2.4 Putting It All Together ........................................................................................... 123
9.3 TIME-BASED NOTE SEARCH ................................................................................................. 124
9.3.1 Red-Black Trees ..................................................................................................... 125
9.3.2 Notes and Intervals ............................................................................................... 125
9.3.3 Interval Search Trees ............................................................................................. 126
9.3.4 Finding all Notes Sounding in an Interval .............................................................. 127
9.3.5 Finding All Notes Starting in an Interval ............................................................... 129
9.3.6 Adding Note Search to Score ................................................................................. 129

xv
Contents

9.4 SCORE MANAGEMENT ........................................................................................................ 130

9.4.1 Interval Tree Update using the Observer Pattern ................................................. 130
9.5 FINAL REMARKS................................................................................................................. 133
9.6 EXERCISES ........................................................................................................................ 133
10 RENDERING SCORE TO MIDI........................................................................................ 135
10.1 AN INTRODUCTION TO MIDI ............................................................................................ 135
10.1.1 Tracks, Channels, and Messages ........................................................................... 136
10.1.2 Time Representation in MIDI ................................................................................ 138
10.1.3 MIDI Messages ...................................................................................................... 138
10.2 MAPPING A SCORE TO A MIDI FILE ................................................................................... 140
10.3 TIME CONVERSIONS ....................................................................................................... 141
10.4 SCORE TO MIDI CONVERSION ALGORITHMS ....................................................................... 142
10.5 CONVERTING A LINE TO A MIDI FILE.................................................................................. 144
10.6 EXERCISES .................................................................................................................... 145
11 VARIABLE DYNAMICS AND TEMPO ............................................................................. 147
11.1 WHAT ARE VARIABLE DYNAMICS AND TEMPO?.................................................................... 147
11.1.1 An Introduction to Variable Dynamics and Tempo ............................................... 147
11.2 FUNCTIONS AND GRAPHS ................................................................................................ 149
11.2.1 The Piecewise Linear Function .............................................................................. 150
11.2.2 The Stepwise Function........................................................................................... 152
11.2.3 The Constant Function .......................................................................................... 153
11.2.4 Generic Univariate Function.................................................................................. 153
11.2.5 Domain Reset with Affine Transformations .......................................................... 155
11.3 USING FUNCTIONS FOR VARIABLE TEMPO ........................................................................... 156
11.3.1 Tempo Functions and the TempoEventSequence .................................................. 157
11.3.2 Tempo Functions, MIDI Generation and Time Conversion .................................... 159
11.4 USING VARIABLE DYNAMICS FUNCTIONS ............................................................................ 160
11.4.1 Details on Variable Dynamics Functions ............................................................... 160
11.4.2 Computing MIDI Velocity Events ........................................................................... 161
11.5 EXERCISES .................................................................................................................... 163
12 FURTHER REPRESENTATIONS ...................................................................................... 165
12.1 HARMONIC CONTEXT ...................................................................................................... 165
12.1.1 HarmonicContext and HarmonicContextTrack Representations........................... 166
12.2 A SYNTAX FOR CONSTRUCTING MUSIC STRUCTURES ............................................................. 167
12.2.1 The Music Parser ................................................................................................... 168
12.2.2 A Music Syntax ...................................................................................................... 168
12.2.3 Invoking the Parser in Code................................................................................... 171
12.3 LITESCORE .................................................................................................................... 171
12.4 EXERCISES .................................................................................................................... 172
PART 2: MUSIC TRANSFORMATIONS ..................................................................................... 173

13 AN INTRODUCTION TO MUSIC TRANSFORMATIONS ................................................... 175

13.1 WHAT IS A MUSIC TRANSFORMATION? .............................................................................. 175
13.2 OUTLINE ON TRANSFORMATIONS ...................................................................................... 176
13.3 A WORD ON MACHINE LEARNING ..................................................................................... 177

xvi
 Contents

13.4 MOVING FORWARD ....................................................................................................... 178

14 A CONSTRAINT ENGINE FOR PITCH ASSIGNMENT ....................................................... 179
14.1 CONSTRAINT PROGRAMMING ........................................................................................... 179
14.2 MUSIC CONSTRAINTS AND SOLUTION SPACES ...................................................................... 180
14.3 MUSIC CONSTRAINT PROGRAMMING ELEMENTS .................................................................. 182
14.3.1 PMaps ................................................................................................................... 182
14.3.2 Constraints ............................................................................................................ 184
14.3.3 Types of Constraints .............................................................................................. 186
14.3.4 Invoking the Pitch Constraint Solver ..................................................................... 187
14.4 EXAMPLES .................................................................................................................... 187
14.5 FINAL THOUGHTS ........................................................................................................... 190
15 SHIFT: A TRANSFORM FOR KEY CHANGE ..................................................................... 191
15.1 AN OVERVIEW OF THE SHIFT TRANSFORM .......................................................................... 191
15.2 STRUCTURAL DESIGN OF THE SHIFT TRANSFORM .................................................................. 193
15.3 TONAL AND PITCH FUNCTIONS ......................................................................................... 194
15.3.1 Tonal Functions ..................................................................................................... 194
15.3.2 CrossTonalityShiftTonalFunction ........................................................................... 195
15.3.3 GeneralPitchFunction ............................................................................................ 197
15.3.4 CrossTonalityShiftPitchFunction ............................................................................ 197
15.4 THE SHIFT TRANSFORM ................................................................................................... 198
15.4.1 Problem Context and Interface ............................................................................. 198
15.4.2 The Main Loop ...................................................................................................... 199
15.4.3 Clarifying Shifting with Mode Change................................................................... 200
15.4.4 Clarifying Shift with Secondary Chords ................................................................. 201
15.5 EXAMPLES .................................................................................................................... 202
15.5.1 Simple Key Shift using Intervals............................................................................. 202
15.5.2 Shift with Modality Change ................................................................................... 203
15.5.3 Modality and Modal Index Change ....................................................................... 204
15.5.4 Modulating Sequence ........................................................................................... 205
15.6 FINAL THOUGHTS ........................................................................................................... 206
16 REFLECTION: A TRANSFORM FOR MELODIC INVERSION .............................................. 207
16.1 AN OVERVIEW OF MELODIC REFLECTION ............................................................................ 208
16.2 PERMUTATIONS ............................................................................................................. 209
16.2.1 Definition and Permutation Composition.............................................................. 209
16.2.2 Using Permutations............................................................................................... 210
16.3 CLASS STRUCTURES FOR THE REFLECTION TRANSFORM .......................................................... 211
16.4 SCALAR REFLECTION ....................................................................................................... 212
16.4.1 Scalar Reflection Details ........................................................................................ 212
16.4.2 TDiatonicReflection ............................................................................................... 213
16.4.3 Examples of Scalar Reflection ............................................................................... 214
16.5 CHROMATIC REFLECTION ................................................................................................. 217
16.5.1 Chromatic Reflection Details ................................................................................. 217
16.5.2 TChromaticReflection ............................................................................................ 218
16.5.3 Examples of Chromatic Reflection......................................................................... 219
16.6 FINAL THOUGHTS ........................................................................................................... 221

xvii
Contents

17 RESHAPE: A TRANSFORM FOR MELODIC SHAPING ...................................................... 223

17.1 INTRODUCTION .............................................................................................................. 223
17.2 A MODEL FOR SHAPING FUNCTIONS .................................................................................. 225
17.2.1 Shaping Functions ................................................................................................. 225
17.2.2 The Pitch Range Interpreter .................................................................................. 226
17.3 A REPRESENTATION FOR SHAPING FUNCTIONS AND PITCH INTERPRETERS.................................. 228
17.3.1 The Pitch Range Interpreters, Description and Examples ..................................... 229
17.3.2 Shaping Classes, Description and Examples .......................................................... 231
17.4 MELODIC FORMS AND CONSTRAINTS ................................................................................. 234
17.5 THE RESHAPE TRANSFORM .............................................................................................. 238
17.5.1 The TReshape Transform API ................................................................................ 239
17.6 EXAMPLES .................................................................................................................... 239
17.7 FINAL THOUGHTS ........................................................................................................... 245
18 HARMONIC TRANSCRIPTION: PRESERVING MELODY OVER HARMONIC CHANGE ........ 247
18.1 INTRODUCTION .............................................................................................................. 247
18.2 MELODIC ANALYSIS FOR SIMILARITY .................................................................................. 249
18.2.1 Harmonic Role Analysis ......................................................................................... 249
18.2.2 Melodic Contour Analysis ...................................................................................... 249
18.2.3 Software Design .................................................................................................... 250
18.3 FURTHER CONSTRAINING THE SEARCH SPACE ...................................................................... 251
18.3.1 The Melodic Window ............................................................................................ 252
18.3.2 Melodic Variance (Tunnel) .................................................................................... 252
18.4 THE HARMONIC TRANSCRIPTION TRANSFORM ..................................................................... 253
18.5 EXAMPLES .................................................................................................................... 255
18.6 FINAL THOUGHTS ........................................................................................................... 259
19 RETROGRADE: REVERSING A MELODY ........................................................................ 261
19.1 INTRODUCTION .............................................................................................................. 261
19.2 THE RETROGRADE TRANSFORM ........................................................................................ 263
19.2.1 The Retrograde Transform Design ........................................................................ 263
19.2.2 The Retrograde Transform API.............................................................................. 264
19.3 EXAMPLES .................................................................................................................... 264
19.4 FINAL THOUGHTS ........................................................................................................... 267
20 MELODIC SEARCH AND PATTERN SUBSTITUTION ........................................................ 269
20.1 MELODIC SEARCH .......................................................................................................... 269
20.1.1 Melodic Search Options ........................................................................................ 271
20.1.2 Melodic Search Technical Details .......................................................................... 272
20.1.3 Melodic Search API................................................................................................ 275
20.1.4 Melodic Search Examples ...................................................................................... 275
20.2 THE MELODIC PATTERN SUBSTITUTION TRANSFORM ............................................................ 276
20.2.1 The Foundations of Melodic Pattern Substitution ................................................. 276
20.2.2 An Approach to Melodic Pattern Substitution ...................................................... 278
20.2.3 Harmonic Context Expression Rules ...................................................................... 278
20.2.4 The Melodic Pattern Substitution API ................................................................... 280
20.3 EXAMPLES .................................................................................................................... 281
20.4 FINAL THOUGHTS ........................................................................................................... 284

xviii
 Contents

21 DILATION: MUSICAL EXPANSION AND CONTRACTION................................................. 287

21.1 A DISCUSSION ON DILATION ............................................................................................ 287
21.1.1 Dilation Dynamics ................................................................................................. 288
21.1.2 The Dilation Transform API ................................................................................... 291
21.2 EXAMPLES .................................................................................................................... 291
21.3 FINAL THOUGHTS ........................................................................................................... 293
22 THE STEP SHIFT TRANSFORM AND SEQUENCES ........................................................... 295
22.1 AN INTRODUCTION TO STEP SHIFT ..................................................................................... 295
22.2 STEP SHIFT DYNAMICS .................................................................................................... 296
22.2.1 Pitch Remap .......................................................................................................... 296
22.2.2 Simple Chord Remap ............................................................................................. 298
22.2.3 Secondary Chords .................................................................................................. 298
22.2.4 The Step Shift API .................................................................................................. 299
22.3 EXAMPLES .................................................................................................................... 300
22.4 FINAL THOUGHTS ........................................................................................................... 303
23 FINAL THOUGHTS ....................................................................................................... 305
23.1 THE QUEST FOR A BROADER MUSICAL SYNTHESIS ................................................................ 305
23.2 THE QUEST FOR REAL-TIME SYNTHESIS............................................................................... 306
23.3 AUTOMATED SCORE ANALYSIS .......................................................................................... 307
23.4 FORWARD .................................................................................................................... 307
APPENDICES .......................................................................................................................... 309

A. MODALITY VARIETIES ................................................................................................. 309

A.1. DIATONIC MODALITIES ....................................................................................................... 309
A.2. PENTATONIC MODALITIES.................................................................................................... 310
A.3. OCTATONIC MODALITY ....................................................................................................... 310
A.4. WHOLE TONE MODALITY .................................................................................................... 310
A.5. BLUES MODALITY .............................................................................................................. 310
B. ORDEREDMAP ............................................................................................................ 311

C. THE OBSERVER PATTERN ............................................................................................ 313

D. CHORDS ...................................................................................................................... 315

D.1. TERTIAN CHORDS ........................................................................................................... 315
D.2. SECUNDAL CHORDS ........................................................................................................ 316
D.3. QUARTAL CHORDS ......................................................................................................... 316
E. A BRIEF INTRODUCTION TO XML................................................................................. 319
E.1. TAGS, ELEMENTS, AND ATTRIBUTES ....................................................................................... 319
E.2. DATA STRUCTURING ........................................................................................................... 319
E.3. READING AN XML FILE WITH PYTHON ................................................................................... 320
F. BINARY SEARCH TREES................................................................................................ 321

G. PROCESSING CONSTRAINTS: THE DESIGN OF A PITCH CONSTRAINT ENGINE ............... 323

xix
Contents

G.1. TWO STRAIGHT FORWARD SOLUTIONS ............................................................................... 323

G.1.1 Depth-First Search ................................................................................................. 323
G.1.2 Breadth-First Search and Chains ........................................................................... 325
G.2. IMPROVEMENTS ON THE CONSTRAINT SOLUTION ALGORITHM ................................................ 327
BIBLIOGRAPHY ...................................................................................................................... 331

xx
Part 1: Representation

The first part of this book focuses on the representation of music in software. We begin with a more
precise definition about the meaning of the phrase “representation in software”. Whenever software
applications are designed, be they music applications, billing systems, or internet chat rooms, etc., they
are broken down at a conceptual level to account for the discrete concepts or entities involved. For
example, invoices, bills, customers in billing systems or participants and discussions in chat rooms,
etc. are discrete concepts that are the subjects of their respective applications. Each of those entities
can be further broken into two key constituents, namely data properties, and algorithmic logic which
we refer to as methods. For example, for a representative entity for a person, data properties might
include name, address, and age. Methods might include accessing or changing these data properties.
What is important is that the data always remains consistent during an application’s execution lifetime.
For example, ensuring the address is correct for the name.
A method is usually referenced by a signature consisting of a method name descriptive of what the
method does, a set of input data, and one or more data that is returned. The set of method signatures
for an entity usually divides into strictly internal, meaning it maintains the data consistency even when
changed, or external, meaning it is meant to be used by other entities or generally by the application
itself.
Discovering the conceptual elements of an application, and further refining each by data property and
methods is what is meant by the term ‘representation in software’ and is further embodied in the process
known as object-oriented (OO) design. The opening chapter of this part of the book describes OO
design and discusses OO programming in the Python programming language.
The topic of this part of the book concerns representation in software for the main elements found in
music theory. Anyone who has attempted to build a music-based software project is aware of how
difficult it is to capture the complex conceptual space of music into software. For example, a note is a
basic entity in music theory that is encapsulated by data properties including pitch frequency, duration,
and volume. One immediately comes across an increasingly complex set of artifacts that add to the
context of a note. Among these are key, time signature, and tempo. Add upon that, chords, measures,
voices, and so forth, of which note is a part, and the complexity multiplies. Following so, we are even-
tually led to score representation, including processes for complex changes such as in time signatures,
tempos, and so forth. There is a hierarchy of music concepts, each layer built upon the lower until we
see the full conceptual space that defines a knowledge base about music, often referred to as music
theory.
Translating these entities into a structured, accurate, and flexible software model is not an easy task.
There are decisions to be made on the conceptual model as structure, the key entities, and their depend-
encies. That is, how does one represent or code all that information using a programming language,
and after that, using that representation, how does one program towards application goals. Each mis-
step, however small, may not necessarily lead to inoperable code, but rather inflexible code, where
Part 1: Representation

doing even the easiest of changes requires, for example, overly complex coding changes. One may also
find suspicious infrequently used procedures that depend on multiple sources of information for per-
haps partial calculations, which overall seem to stick out like a sore thumb in the code base.
The objective of this part of the book is to provide direction to this discussion, to build a music software
model from basic concepts and build towards more complex concepts. Chapter by chapter we introduce
new music concepts and break each apart into data properties and methods. The goal is that by the end
of this book section, we will have developed a relatively complete library of music elements in software
that can be practically useful and for experimentation and provide a foundation for the advanced work
found later in the transformation part of the book.

2
1 Software Modeling and Object-Oriented Design

Software design has been an ever-evolving craft since the beginning of programming. As software
systems became more complex there was more need for discipline in crafting software and organizing
it. It became clear that strict procedural designs and use of data structures, although effective, could
lead to code that easily fractures under the strain of changes, through carelessness or lack of foresight.
Looked at another way, the early programming languages had no implicit capability to assist with
enforcing design principles.
Object-oriented design is a paradigm for programming that evolved primarily through the 1970’s and
into the 1980’s. At a simplistic level, the basic idea behind this paradigm is to think of a software
system as a set of concepts or entities, and for each define a set of data properties that encapsulate the
entity, and as well, a set of procedure-like logic that allow the entity to regulate or maintain consistency
of those data properties, and a set of procedure-like logic that provides public access from other con-
cepts or generally. This approach has been adopted by many programming languages including Small-
talk, C++, and Python, to name a few, and each has inherent support structures and features for object-
oriented design. The design concepts become actualized as classes within which are defined the data
properties and logic methods.
The point of using object-oriented design is to consolidate application data and processes into well-
defined conceptual silos as design. The development becomes more logical as it adheres to the problem
space more precisely at a conceptual level. In using object-oriented design, as we will see, there are
decisions to make about class definition and related class hierarchies, data property and method defi-
nition and so forth. Over time, object-oriented programming has evolved into a rather large topic. How-
ever, many of the basics are easily stated and illustrated. It is beyond this text to develop object-oriented
design theory in detail here. Instead, the basics are described in this chapter, and further aspects are
introduced as needed later.
In this book, we take a journey towards building an object-oriented model for music using the Python
programming language. However, at the same time, we look at music theory very deeply, even to the
point of including some modern music concepts, such as 8 tone scales, and cluster chords. With that,
we transform music theory to software within a broader context, and in doing so, guide ourselves
through a set of decisions and problems in doing the related software design and implementation.

Object-Oriented Design by Example

For a hands-on introduction to object-oriented design, we explore a simple example comprised of a
few related entities from a hypothetical and simple banking system. In this system we have accounts
of different types for different purposes. We have accounts for credit cards, checking, and savings.
Furthermore, suppose our imaginary bank offers two types of credit card accounts, Z1, and Z2. Also,

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 3

D. P. Pazel, Music Representation and Transformation in Software, https://doi.org/10.1007/978-3-030-97472-5_1
1 Software Modeling and Object-Oriented Design

suppose there are two types of checking accounts, basic and enhanced. A diagram depicting the rela-
tionships amongst these entities is shown in Fig. 1.1. Keep in mind that this diagram aims to facilitate
design, indicating what entities are envisioned in our application and how data and code is organized.
The design diagram is abstract in showing the definitions of the application’s entities and relationships,
and not actual instances of the entities. In programming, we instantiate the definitions in that many
Accounts, many Checking accounts, and so forth, based on these definitions are created. Building these
kinds of diagrams is common practice in program design.
The hierarchical diagram shows a box for each entity type discussed above, along with relationship
arrows described below. Let’s look at the element of this application more closely.

Fig. 1.1 Example Object-Oriented Design

Class: Instead of entity we will use the word class, which relates more to its programming embodiment
described later. Classes represent the conceptual elements that comprise our system. It is abstract in
the sense that classes are descriptive or defining elements. For example, there is only one class defini-
tion for ‘Account’, which describes its data and behavior. However, in an actual application, there will
be many account objects or instances based on that definition. Each instance holds real data with be-
haviors based on actual data values and code. This bundling of related data on a common conceptual
entity is called encapsulation.
Properties and Methods: With class being a defining element, at the detail level, a class is composed
of properties and methods. It is easiest to think of properties as data definitions. For example, in the
case of the class Account, one would have a property that names or identities the owner of the account
and name that property ‘owner’. Other properties include the date the account was opened, called
‘opening date’, and the property ‘status’ of the account with values like open, closed, frozen, and so
on. Properties are defined data holders related to what the class conceptually represents.
Methods on the other hand, can be thought of as calculations or actions related to the class that either
other classes can invoke, or that can be invoked external to any class. Returning to the class Account
example, invoking change_owner(), would provide a means to change ownership of the account. More
than simply a name setting action, change_owner() verifies the identity of new owner, as well as checks
if the new owner has permission to ownership and related business role to it, and so on.
Get_Credit_Line() is another method requiring various calculations depending on the type of account,
balances, and so forth. Many methods and properties may be openly accessible, or public, to the appli-
cation. Others may be strictly internal to each class, or in that sense private. These accessibility

4
 1.1 Object-Oriented Design by Example

characteristics, public or private, are referred to as data protection values. Methods are specified in the
form of a signature which provides the name of the method, and the names of both input and output
data.
Inheritance: The arrows between classes in the diagram can best be thought of as denoting “is a” rela-
tionships between the source class and the target class. For example, “Checking is a kind of Account”
or “Basic is a kind of Checking (Account)”, the “Z1 credit card is a CreditCard (Account)”, and so
forth, are clearly marked in the diagram by arrows. Each arrow indicates inheritance, that one class
has the same properties and methods of another and may likely include additional properties or meth-
ods. In an inheritance relationship, the class at the base of the arrow is called a subclass in relationship
to the class at the arrowhead called the superclass. What this means is that all the properties and meth-
ods of the superclass, for example Account, are also part of say, a Checking (account), the subclass.
Similarly, Account’s properties and methods are included in CreditCard and Savings. Superclasses like
Account reduce duplication of data definitions and method implementations for its subclasses. This
makes development much easier since changes and enhancements to superclasses automatically bind
to their subclasses.
Interface: An interface, like a class, is a summary of data properties and methods, but unlike a class
are not directly instantiated. Classes implement interfaces, in that when so indicated, the classes further
define the interface’s data properties and methods. Many classes can implement the same interface. In
that way, interface provides a form of multiple inheritance, allowing instances of different implement-
ing classes to be identified by the interface semantics only. An interface should not be confused with a
class definition wherein the semantics or meaning of these characteristics is laid out, described, and
even coded as properties and methods. In fact, interface instances are not created by themselves but
only in as much as an implementing class is created. What is important about interfaces is that they
encapsulate a set of data properties and methods that can be accessed through the implementing class.
The interface mechanism varies across programming languages. Java provides interfaces to be used at
user discretion. Python and C++ do not. In these latter cases, the class definitions themselves are in a
sense, de facto interfaces. The point behind the notion of interface whether by interface semantics or
by class definition, is that in both cases there is an identifiable encapsulation of accessible data and
methods that can be used as a source for coding activity.
Polymorphism: The object-oriented feature of polymorphism has several different meanings. Inher-
itance relates to a kind of polymorphism, in as much as, for example, CreditCard, Checking, and Sav-
ings are subclasses of Account, and wherever an Account instance can be used, usually so can Ac-
count’s subclasses of CreditCard, Checking, and Savings. In that sense, inheritance leverages a kind of
polymorphism. A more commonly held notion of polymorphism is when a class can have several meth-
ods of the same name but with different parameter types or numbers of parameters that serve to distin-
guish which method is invoked by calling arguments. As a simple example, the Checking class may
have several method implementations for the method deduct(). In one, deduct(owner_name, amount),
a deduction for some amount is made by a specific owner of the account. In another, deduct(amount),
a deduction is made anonymously on an account.
As mentioned earlier, object-oriented design is a kind of science to itself. The brief introduction above
hardly scratches the surface. For more information, reference [7], [8]. A visual representation of many
concepts in object-oriented design can be found in the study of Unified Modeling Language or UML.
The inheritance arrow in the above diagram is the UML symbol for inheritance for example. A refer-
ence for UML is [9]. Finally, to see object-oriented design in light of practice for commonly used
programming motifs, refer to the study of programming patterns [10].

5
1 Software Modeling and Object-Oriented Design

A Concise Introduction to Python Classes

The Python programming language offers ample semantic structures for implementing object-oriented
design and programming. In this chapter, we outline Python’s object-oriented semantics starting with
the class statement, which is the main declarative for defining a class. The class statement typically
includes the following definitional statements in this order:

class ClassName(subclass_1, subclass_2, … ): # Class Declaration Header

class_data1 = value # Class Static Data Definitions
class_data2 = value

def __init__(self, args, …): # Class Instance Initializer

self.instance_data1 = value # Instance Data Definitions
self.instance_data2 = value

def method1(self, args, …): # Method Definitions

def method2(self, args, …):

• Class Declaration Header: This statement provides the name of the class being defined, along
with a list of class names of other defined classes to serve as superclasses. When no super-
classes are specified, the default is the Python system class “object”. So far, we have only
explored classes with only one superclass, and for this text that will typically be the case.
However, a class can have multiple superclasses, and pick up the properties and methods of
all the superclasses. Such a situation is called multiple inheritance. Multiple inheritance has
some complexity and must be defined with care especially in cases where the subclasses share
similarly name methods or data. Further discussion on multiple inheritance can be found be-
low.
• Class Static Data Definitions: A class can define static data variables proper to the class itself,
and independent of class instances. That is, although we may create many class instances,
there is only one value for each of these class data variables, that is, the static values being
singular to the class itself. Access is made through ClassName.class_data1, for example.
• Class Instance Initializer: When a class is instantiated to an instance, that instance requires
proper initialization, with application dependent default values for instance data, and for pos-
sibly building ancillary data for proper instance behavior. That initialization is implemented
in the class’s __init__() method. In code, the __init__() method is automatically invoked at
instance creation, e.g., a = ClassName(args). The first variable in the signature of __init__(),
self, is a reference to the new instance. Additional parameters may be specified for supple-
mental value input to assist in initialization. While, the __init__() method is invoked to ini-
tialize a class instance, note that the subclasses also require initialization as well, and this is
achieved by the subclass’s __init__() invoking the __init__() methods of each superclass.
• Instance Data Definitions: Instance data refers to the class variables that on an instance-by-
instance basis hold values for that instance. They come into existence usually on first usage,
as opposed to a formal declaration of name and type found in many programming languages.
Instance data access is made through the reference self.instanceData1, for example. While
instance data variables can be defined in any method for an instance, doing so in __init__(),
as a policy, establishes an expectation as to where to find all instance data definitions and their
initial settings.
• Instance Method Definitions: Class methods define class behaviors. Each class definition pro-
vides a set of method definitions. A method definition consists of a method name along with

6
 1.2 A Concise Introduction to Python Classes

a set of parameters which together defines the method signature, and an implementation as
code. As for the parameters, the first parameter is “self”, which for the instance access refers
to the class instance itself. Note that, when called, “self” is not explicitly passed, e.g., in-
stance.method1(args). It is worth noting that while method signatures must be unique, meth-
ods can be defined with the same name provided the signatures are unique, e.g., deposit(dol-
lars) verses deposit(dollars, for_account_name).
• Class and Static Methods: Python provide two method variants that have a more global nature,
in that they are called independent of any class instance. In both cases, there is a signature as
described. A class method’s signature has, instead of “self”, a “cls” variable as first parameter
which references the Python class object itself. The other parameters are as before. A class
method is called, e.g., class.method_namer(args). Static methods on the other hand have
neither self nor cls as a first parameter. They are called by object or class as before, but the
again the first argument is neither self nor cls.

Properties
On the topic of instance data definitions, the related topic of Python properties is worth highlighting.
While instance variables are accessible by name both inside or outside the class definition, sometimes
getting and setting an instance variable to some value might require additional processing above and
beyond merely accessing the instance data directly. However, accessing instance variable data along
with the additional processing through new user defined methods would only add to the complexity of
class usage. Python properties is a feature that provides for that extra processing while maintaining
simple user access to instance data. An outline for defining properties is as follows:

@property
def account_name(self):
# Additional processing
return self.name

@account_name.setter
def account_name(self, name):
# Code to determine the name value
self.name = new_name
return

The decorator ‘@property’ is used to declare the getter method, while @name.setter prefixes the setter
method. In usage, for example, one simply calls instance.account_name to get the account name, and
instance.account_name=‘Valerie’ to set the account name.

Multiple Inheritance
In regards to multiple inheritance, it is important during object instantiation to not only initialize the
main object, but each instantiated superclass by calling the __init__() method for each superclass. Con-
sider the following modification on the Account class example. In this case, suppose Account inherits
from both Bank and Client. In that case, Account’s initialization includes initializing data for both Bank
and Client. When an Account is constructed, full data of each is expected in Account’s __init__()
signature, and the Account must then pass the appropriate initialization data to the superclass’ initiali-
zation methods.

7
1 Software Modeling and Object-Oriented Design

Following along to this example, we have Account derive from, or more specifically, inherit from the
classes Bank and Client. This is a case of multiple inheritance. A sketch of how to specify this in Python
is given below.

class Account(Bank, Client):

def __init__(self, bank_record_data, client_record_data):

Bank.__init__(self, bank_record_data)
Client.__init__(self, client_record_data)

We see in this example the two superclasses for Account are Bank and Client and are specified in the
class definition. Also, the __init__() for Account has two additional arguments, one an unspecified
amalgam of data about the bank, and one about the client, which are used to initialize Bank and Client
respectively. Observe that the __init__() methods for both Bank and Client are called with the respec-
tive initialization data within the Account constructor. This is a very important step as it fills in critical
data for the superclass instance for each class.
Python supports many of the characteristics of object-oriented design touched upon earlier, such as
encapsulation, inheritance, and polymorphism. However, there is little to no data protection except by
convention11. Regarding interface, it effectively consists of the data variables and methods defined in
the class and is not a separate abstraction. Nonetheless Python does provide more than adequate object-
oriented support for implementing object-oriented design.
This concise description of Python classes goes a long way toward understanding how to use them,
and to understand how they are used in the context of this book. Further features of Python classes are
discussed as they arise in the text. As always, one can refer to the many excellent textbooks on Python,
such as [4] [5], for further information.

What Can Go Wrong in Object-Oriented Design

Any attempt to debate software design methodologies or discuss comparisons are met with strong opin-
ions and perhaps heated discussion. Besides object-oriented, there are other design methodologies such
as functional design, procedural design, and data-driven design. We will not discuss alternatives here
but remain focused object-oriented design.
Considering prior discussion, one naturally wants to know if object-oriented design has problematic
aspects, or pitfalls to avoid in its usage. We discuss two items along that line. One involves being
overly motivated by object-oriented design ideals, and the other concerns coping with the inherent
complexity one finds in applications/systems design no matter what methodology is seized upon, that
OO design is not a panacea.
Over Abstraction
In looking at an application’s data as class definitions, one might be tempted to detail the layers of
abstraction to an extreme – wherein all application data must live within a large-scale object type
schema. It is very easy when designing in abstraction, to derive many abstract layers even non-obvious
ones, to glean additional relationships amongst object types, with additional data to track or methods
to construct, not for relevance to the application, but for the sake of completeness. One outcome, for

11
One often finds in Python that protected or private data is prefixed with a single underscore, and
methods with two underscores. This is simply a convention for protected data access, and not an out-
right enforcement.

8
 1.4 The Meaning of Music Representation

example, is for the class hierarchy to expand from say three layers deep to five layers deep, even though
the initial model sufficed for the application. Some objects that were single inheritance become multi-
ple inheritance, and so forth. Sometimes these kinds of expansive architectures are quite necessary, and
sometimes they only burden the schema and coding effort needlessly, and in the end make an architec-
ture that becomes difficult to navigate with some largely useless design enclaves.
This happens many times on a first encounter with object-oriented design, when novices “see objects
everywhere”, and end-up coding to an ideal instead of a practical application. Perhaps the best practice
is that when deriving class schemas, watch for object types, relationships and inheritances that lack
relevance to the needs of the application and/or do not fill any application needs. At that point, it is
good to reconsider the current and future goals of the project design. As one simple example, if a
system designer feels a need to derive their own integer or real number class, it might be a good time
to retreat and question the true necessity for making that kind of decision and judge the necessity of
that impact across the application, now and in the future.
Correcting a schema after first application release can be a difficult and thankless task, especially when
removing these kinds of design elements.
Concurrency and Side-effects
It is important as well to not confuse the benefits of object-oriented design with general coding practice.
Depending on the application, you still must deal with for example, concurrency issues. You still must
deal with potential side-effects sometimes stemming from processing side-effects, e.g., unexpected
data value changes during transactions. These don’t go away simply because you use object-oriented
design, and sometimes a correct object-oriented design to address these issues can be difficult.
Still Requires Good Practice
This leads to the final consideration, that object-oriented design is not a panacea for treating all the ills
of programming. Many of those remain. We might point out, that even within the confines of object-
oriented design, you should be encouraged to devise meaningful class, variable, and method names,
and avoid cramming too much semantics into one place, for example, a Python file, i.e., putting multi-
ple classes into a single file.
While much has been accomplished in programming and program design over the last few decades,
application/system design and coding remain difficult tasks, and require skill, continual diligence, and
attention.

The Meaning of Music Representation

Building on the prior sections, the term ‘music representation’ has two aspects. For one, it means ar-
ticulating the comprehensive set of music theory concepts, their semantics, and their relationships. In
another, it means the embodiment of these concepts as software design classes, class relationships,
their associated data properties, and methods. In this book, music representation is a software modeling
exercise, with a focus on thinking and detailing the translation of music concepts to object-oriented
terms.
What this means is that music concepts such as tone, pitch, scale, and chord are to be defined as Python
classes. In all cases, it involves detailing and defining the data each class holds, as well as their behav-
iors as methods. These classes become constituents to a class hierarchy. Among other things, this ex-
ercise involves examining which music concepts are more fundamental than others, and which music
concepts are derivative concepts of others, and so forth. In all, translating music theory into Python
classes is a rigorous effort and a very rewarding one. It forces one to be reflective about domain con-
cepts, to detail what they mean, and how music concepts relate to each other. It forces one to fill in

9
1 Software Modeling and Object-Oriented Design

knowledge gaps, and to acknowledge edge cases that are often overlooked, towards building a complete
and consistent view of the domain.
Music students should find this study interesting in that it necessarily entails rigorous definition of
music theory concepts, even to the point of articulating with precision the most fundamental ideas. For
example, what distinguishes tone from pitch? Many times, terms like these are used loosely and inter-
changeably, perhaps with meaning inferred from usage context. Here however, each concept, like any
of these, is defined with precision and accuracy. It is an essential point in software modeling that con-
cept definitions have well-defined semantics.
Computer science students accustomed to working with class hierarchy definitions will appreciate this
rigorous formalism on music theory.

10
2 The Chromatic Scale and the Diatonic Foundation

Among the most fundamental concepts of music training and music theory education are the sounds of
different tones or pitches12 on one or more instruments. We come to know and identify them and dis-
tinguish similarities and differences among them both within and across instruments. Eventually we
see them in larger coherent organizations, understanding tonal relationships in broader terms, such as
intervals, scales, and chords. Due to certain unvarying and recognizable characteristics about pitches,
these larger concepts have a marked stability that make music possible across the space of instruments.
With the help of educators, we learn the formal and larger organization of these concepts in what we
call music theory, and further apply this theory in music composition, analysis, and performance.
We begin our musical journey similarly with a focus on tones and pitches, and likewise explore their
structure around the chromatic scale as our starting point. From the chromatic scale, we look at seven
tones that become the foundation for naming all tones. As we will see later, these primitives build a
foundation for further music theoretical artifacts such as intervals, scales, chords, etc.
We begin with a brief informal survey of Western music foundations by examining the Pythagorean
scale and its subsequent evolution. Our exploration continues to the 12-tone equal-tempered chromatic
scale which defines the space of tones and pitches that will be used throughout the text. We develop
the diatonic or 7-tone structure that is imposed on the chromatic scale as a larger concept we term “the
diatonic foundation”. This structural relationship between diatonic tones and the chromatic scale is
core to the foundations of scales, intervals, and chords that are discussed in detail later.
We finally pivot to the software modeling viewpoint, developing tone and pitch Python classes as the
foundation of music representation in software. Subsequent music concept representations are built
upon the representations defined here. This co-development of music theory and software representa-
tion returns throughout the remainder of the book.

The Pythagorean Scale

The history of defining tones and creating pitches for music traces back to antiquity. A pitch has a
frequency measured in cycles per second, which can be imagined as the vibrational rate of a plucked
string, say, as in a harp. For our starting point, the Grecian ideas on tone and pitch, in the context of
the Pythagorean scale13, represents a case for building a suite of consonant or agreeable sounding
pitch/frequencies based on vibrational frequency ratios.

12
In informal discussion tones and pitches are many times used synonymously. Later these are more
precisely defined.
13
So named as being attributed to the famous Greek mathematician Pythagoras.

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2022 11

D. P. Pazel, Music Representation and Transformation in Software, https://doi.org/10.1007/978-3-030-97472-5_2
2 The Chromatic Scale and the Diatonic Foundation

The construction of this ancient scale is based on creating pitches with frequencies based on fractions
or ratios one pitch’s frequency relative to another pitch’s frequency. This is sometimes referred to as
an interval, however, intervals have a more precise meaning discussed later. Select a pitch of some
frequency as a root pitch. For the root pitch, intervals relative to the root based on doubling that fre-
quency were considered in some sense related, of having a strongly discernable sameness. Other ratios
to the root pitch were also noted as significant. In particular, the root pitch’s frequency multiplied by
3/2 corresponding to a pitch a perfect fifth interval higher to the root was considered important. Two
pitches a perfect fifth apart were consider in some sense pleasing and were given the characterization
consonant, as were many pitches with intervals expressed as ratios of small integers, e.g., 3/2, 4/3, 6/5.
The root pitch frequency multiplied by 2/3 is the frequency of the perfect fourth to the lower identical
root (1/2 the root frequency). Accordingly, the frequency a perfect fourth above the root is 4/3 (2 * 2/3)
of the root frequency.
The process for generating a Pythagorean scale is based on using the perfect fourth and fifth intervals
just discussed. It involves generating 7 tones successively using each interval, and applying some ap-
propriate powers of 2 or 1/2 to the frequencies to contain the generated pitches within twice the root’s
pitch frequency, that is, making the pitches’ resulting ratios contained in the ratio range [1 .. 2]. This
results in deriving a sequence of notes between the two pitches considered nearly synonymous. In other
words, it derives a scale.
As a demonstration of Pythagorean scale derivation, consider Fig. 2.1 below which outlines the deri-
vation of the Pythagorean 12 tone scale. (We use standard note annotations here for referential purposes
only.)

Fig. 2.1 Pythagorean scale derivation using the factor 3/2 successively to the right, and 2/3 to the left. Each
column shows the doubling or halving necessary to get the ratio to within one octave, i.e., within the interval
[1 ... 2].

Starting at C we derive pitches a perfect fifth higher in succession to the right until F#, making 7 notes.
Then, starting at C, we derive the pitches a perfect fifth lower in succession to the left until Gb, again
making 7 notes. This gives a total of 13 pitches. The frequencies are normalized to C having a ratio 1.
According to construction, all the derived pitch ratios must be in the interval [1 .. 2]. To achieve this,
after applying the appropriate multiplier for the pitch ratio, we then reduce the pitch by applying suffi-
cient factors of 1/2 ( or 2 for fifths lower) so that the resulting ratio per pitch lies in [1 .. 2]. (Shown in
each column) We get our final 13 pitches. Then, sorting the resulting ratio values we have the resulting
scale shown in Fig. 2.2.
In total the construction produces 12 tones, akin to the Western 12 tone chromatic scale. However,
there is an issue. In the derivation of the 7 tones in each direction, there are two tones, F# and Gb, that
are quite close in ratio values but not the same. Ideally, we would like these to match to make a perfect
scale that we could repeat at double or half the root, and so forth. This misalignment causes problems,

12
 2.2 Just Intonation and Equal-Tempered Chromatic Scales

which in that time were relieved with various pitch omissions [11]. In any case, despite its consonant
sounds, the Pythagorean scale is a flawed if not problematic scale system for music.
Fig. 2.2 Pythagorean Scale
Ratios,final ratios after reduc-
tion in Fig. 2.1

The eventual solution involves altering the factors to make the pitches in some sense “evenly spaced”,
while preserving the notion of consonant sounds that the ratio approach of the Pythagorean scale
achieved. As we will see, the eventual solution was to have identical ratios for any two consecutive
ascending pitches. This leads us to the discussion of the equal-tempered chromatic scale.

Just Intonation and Equal-Tempered Chromatic Scales

The awkwardness of the Pythagorean scale was addressed in several ways. A technique called just or
pure intonation was developed that in some ways is a brute force technique to make the scales work
by constructing the other 11 pitches from the root pitch using interval ratios consisting of small whole
numbers, which are considered consonant as discussed above.
Fig. 2.3 Just Intonation Ratios -
small number ratios are a basis for
just intonation tuning.

Fig. 2.3 shows ratios used for just intonation. The downside of this approach is that some instruments
so tuned will only sound good in the key to which it is tuned. Using other tones as keys will be out of
tune, and so the instrument needs to be re-tuned for other keys [12] (See exercise 2.4.1.)
Following to just intonation is the notion of well-tempered tuning, in which slight perturbations on
pitch tuning achieve making major and minor keys sound good on a keyboard. There are many such
schemes, with mixed results. Reference Werckmeister temperaments [13] for an example.
A variant of well-tempered tuning that eventually found widespread acceptance is equal-temperament,
resulting in an improved tuning scale over ancient scales in avoiding consonance issues, while provid-
ing pitch consistency across octaves. The idea behind well-tempering is that through 12 tones, any two
consecutive ascending tones have identical ratios, namely 2!/!# , or roughly 1.059, while by necessity

13
2 The Chromatic Scale and the Diatonic Foundation

successive octave pitches have a ratio of 2. The successive multiplication of each pitch’s frequency by
2!/!# for the successor pitch’s frequency results in evenness in the tonal space, while at the same time
approximating reasonably well the ancient ratio-based pitches providing consonant sounds. The scale
ratio uniformity also provides stability of tuning for other keys, i.e., one tuning is good for all keys,
avoiding the problems of just intonation, in addition to those of the Pythagorean approach. This 12-
tone equal-tempered system is sometimes referred to as 12-EDO or 12-TET.
Why 12 notes and not 10 or 15? In part at least, the answer is that 12 solves an optimization problem
that, remarkably, preserves the benefits of the just intonation consonant pitches while avoiding its def-
icits. In reference to Fig. 2.3, it turns out that “the twelve-tone equal-tempered scale is the smallest
equal-tempered scale that contains all seven of the basic consonant intervals to a good approximation
— within one percent — and contains more consonant intervals than dissonant intervals.”14 [14]
Furthermore, a 12-tone pitch set based on a root pitch can be extended to lower or higher pitch ranges
using the same equal-tempered ratio thereby extending to a larger range of pitches. For the purposes of
this book, any range of pitches derived in this manner from the 12-tone equal-tempered scale is called
a chromatic scale and is the foundation for the tonal space referenced throughout the remainder of the
book.
While the above provides a constructive means for computing chromatic pitches, the precise pitch
range of chromaticism must be determined. More precisely:
• What is the frequency range of the chromatic scale that we will consider? That is, what are
the lowest and highest pitch frequencies?
• Is there one frequency that can be selected as a tonal center for the chromatic range, from
which all other pitch frequencies can be derived using the equal-tempered ratio of 2!/!# ?
Knowing the answer to the second question, lower and higher pitches are easily computed. But how
many? Where does it start and end?
The answer to the second question, based on tuning standards, is 440hz15 [15], which is what we know
as the A above middle C, notated as A4. As to the first question, there is no definitive answer as each
musical instrument is constrained to specific natural ranges. However, the range of the modern standard
keyboard is broad, well established and encompasses the pitch ranges of nearly all other commonly
used musical instruments. The keyboard range is from 4 octaves below A4 to 4 octaves above middle
C (C4), for a total of 88 individual pitches based on the equal-tempered scale. Notationally, these refer
to A0 and C8 respectively. We refer to any two successive pitches of these 88 pitches as being a sem-
itone, or half-step apart.
As an exercise for understanding the chromatic scale structure introduced above, we break down a
pitch reference as tone and octave and address how to index each pitch in the chromatic scale. We then
show how to compute between the pitch’s reference structure and its index in the chromatic scale.
As there are 12 sequential chromatic pitches per frequency doubling, the 88 semitones are divided into
adjacent groupings, each comprising 12 consecutive semitones. The convention we use is for each
group to start on a C pitch. Each group is called a chromatic partition or simply partition, or octave.
In this manner, any semitone in the chromatic scale can be designated by a combination of an octave
number and a 0-based16 offset into the partition. We assume octave numbering is also 0-based in such

14
The basic consonant intervals are octave, perfect fourth, and fifth, major and minor third, and
major and minor sixth.
15
Hz or Hertz is a unit of frequency taken to be one vibrational cycle.
16
0-based means the first offset is 0. In 1-based, the first offset is 1.

14
 2.2 Just Intonation and Equal-Tempered Chromatic Scales

a way that C4’s octave is the fourth octave. We call this pair of numbers the pitch’s chromatic location,
i.e.,
(octave number, offset in octave)
Expressed as chromatic locations, the chromatic scale then comprises the pitches:
(0, 0), (0, 1), ... (0, 11), (1, 0) ... (1, 11), (2, 0) ...
Using this notation, the standard keyboard range is from (0, 9), the lowest A on the keyboard, to (8, 0),
the highest C on the keyboard. Again, we use 0-based numbering for octave and tonal offset, i.e.,
partition 0 is the first partition, and semitone 0 is the first pitch C. Note that (4, 0) corresponds to middle
C, and (4, 9) to the A above middle C that is usually 440hz, as mentioned earlier.
Looking at this another way, the pitches in the chromatic scale are sequential and so can be counted or
indexed, again 0-based. Going with that scheme, (0, 0) corresponding to index 0, and A0 or (0, 9)
having index 9. Fig. 2.4 shows these relationships.

Fig. 2.4 Chromatic Scale and Pitches

Showing the layout of the chromatic scale and the placement of significant chromatic pitches.

Conversions between chromatic location and index are based on the formulas:

(𝑜𝑐𝑡𝑎𝑣𝑒, 𝑜𝑓𝑓𝑠𝑒𝑡) = 12 ∗ 𝑜𝑐𝑡𝑎𝑣𝑒 + 𝑜𝑓𝑓𝑠𝑒𝑡 ( 2.1 )

𝑖𝑛𝑑𝑒𝑥 ( 2.2 )
𝑖𝑛𝑑𝑒𝑥 = ( , 𝑖𝑛𝑑𝑒𝑥 % 12)
12

The division by 12 above is integer division, meaning use the integer part and discard the fractional
part or remainder.
To clarify on terminology, in discussing tones we are talking about any of the 12 semitones of an
octave, regardless of octave. For example, the 3rd tone (D) refers to the 3rd semitone in any partition.
Consequently, there are only 12 tones. Pitch, however, references both the partition number and the
tone’s offset. Recapping, tone references to the offset in any octave location, but pitch is a precise
chromatic location.

The Chromatic Scale Representation

The prior chromatic scale discussion provides an entry to discussion about software representation and
its Python code embodiment. We consider the construction of the ChromaticScale Python class and
translate the location/index conversion logic given above to code.
To start, there is no reason to have multiple instances of a ChromaticScale. There is only one, and we
can reference it as a single object with global access. With that in mind, we develop the ChromaticScale

15
2 The Chromatic Scale and the Diatonic Foundation

class as a static class meaning that it contains only static methods and constants. There is an argument
that static classes make for a less preferable representation of global characteristics, and that instead,
non-class (i.e., global function) based code would be a qualitatively less complex representation with
equal efficiency. However, for pedagogical purposes, we generally insist on looking at the world in
terms of classes and class instances. Besides, global static data and methods wrapped as a class provide
a consolidation of related global elements under a unified theme or concept. The class provides a global
singular reference point for related activity and data. Furthermore, doing so preserves viewpoint con-
sistency over the entire code base, wherein everything is viewed through an objectified lens.
The ChromaticScale class is of limited use in the code base and exists mainly to summarize the topics
of this chapter as well as easing into case studies of Python classes for musical elements. More expe-
rienced programmers may ask why not used the singleton design pattern (refer to [10]) for the imple-
mentation. The answer is that the topic here does not require that level of complexity. For example,
this class does not rely on more complex superclasses, nor does it require cloning or the like.
A portion of the ChromaticScale class definition is shown below. The class consist of constants that
are static to the class as well as a number of methods which are also static. In the case of the methods,
the Python decorator “@staticmethod” declares that the following method is static for the class. As
with chromatic locations discussed earlier, we represent pitches as Python tuples of numbers (octave,
offset). The methods above replicate the two conversion formulas ( 2.1 ) ( 2.2 ) presented earlier.

class ChromaticScale:

NUMBER_OF_SEMITONES = 12
CHROMATIC_START = (0, 9)
CHROMATIC_END = (8, 0)

CHROMATIC_FORM = r'([0-8]):(10|11|[0-9])'
CHROMATIC_PATTERN = re.compile(CHROMATIC_FORM)
. . .
@staticmethod
def location_to_index(pitch):
return ChromaticScale.NUMBER_OF_SEMITONES * pitch[0] + pitch[1]

@staticmethod
def index_to_location(index):
return index // ChromaticScale.NUMBER_OF_SEMITONES, index %
ChromaticScale.NUMBER_OF_SEMITONES

@staticmethod
def parse_notation(notation):
n = ChromaticScale.CHROMATIC_PATTERN.match(notation)
if not n:
return None
return int(n.group(1)), int(n.group(2))

Several constants related to chromatic scale are defined including:

• NUMBER_OF_SEMITONES: indicates the number of equal-tempered tones in a chromatic
scale octave.
• CHROMATIC_START, CHROMATIC_END: in tuple notation denotes the chromatic loca-
tions (octave, offset) for the start and end tones of the full chromatic scale

16
 2.3 Tones, Pitches, and the Diatonic Foundation

• SEMITONE_RATIO: denotes the value 2!/!# , which is the multiplier to derive a tone’s fre-
quency from its predecessor tone’s frequency.
This class introduces a powerful Python means for converting strings to binary information that can be
used within representational objects or for calculations. This technique is used frequently in the code
base. In this simple case, we convert a textual pitch location expression into a Python tuple for chro-
matic scale reference. For example, we can parse the text “4:6” (meaning octave 4, offset 6) into the
Python tuplet (4, 6). Python regular expressions are discussed thoroughly in [16]. The pattern for this
case is held by static variable CHROMATIC_FORM as r’([0-8]):(10|11|[0-9])’. The ‘r’ means the text
should be understood as a regular expression. This expression can be read as “start with an integer
between 0 and 8, followed by a ‘:’, followed by an integer between 0 and 11”.
The seemingly odd positions of 10 and 11 in the regular expression simply give parsing precedence to
10 and 11, where if placed after [0-9], the parser would pick up 1 and ! on the second 0 or 1. The
regular expression is then processed or “compiled” into a Python pattern, the result of which is held by
CHROMATIC_PATTERN. The static method parse_notation() takes a string input, matches it against
the pattern, and returns the chromatic location, octave and offset, as a Python tuple (after conversion
from string to integer).
Here is a simple example of these static methods’ usage:

location = ChromaticScale.parse_notation("4:9") # parse “4:9” to tuplet (4, 9)

print(location)
index = ChromaticScale.location_to_index(location) # convert (4, 9) to 57
print(index)
loc = ChromaticScale.index_to_location(index) # convert 57 to (4, 9)
print(loc)
(4, 9)
57
(4, 9)

To see further examples of ChromaticScale usage, the reader is encouraged to read, run, and step
through the corresponding test file test_chromatic_scale.py.

Tones, Pitches, and the Diatonic Foundation

The diatonic foundation is a way of viewing the chromatic scale through a subset of seven specific
tones, with the remaining five being modifications of those seven. It provides a tonal reference system,
and an organizing tonal filter, that provides a foundation for diatonic scales (e.g., major, minor) and
more. The origin of this filter is not clear but may be related to following from C in major 5ths until,
with the exception of B, only dissonant sounds are encountered.
Fig. 2.5 shows seven distinct semitones per chromatic 12-tone octave. These tones are labelled solely
with alphabet letters, in order {C, D, E, F, G, A, B}, and for referential purposes here are called the
basic diatonic tones. The remaining five tones are considered augmented tone variations of the neigh-
boring basic tones. All 12 tones are called diatonic tones. Each labeled tone is identically positioned
within each octave. In other words, the same label assignments (basic and augmented) are made to the
tones in each octave. It should be noted that any 12 consecutive semitones, regardless of first tone’s
location, is called an octave as well. This convention works well for scales introduced later, but in the
context of the discussion here, octaves have C for their first tone.

17
2 The Chromatic Scale and the Diatonic Foundation

Fig. 2.5 Tonal Positions in the Diatonic Foundation. This figure shows seven
basic diatonic tones (shorter arrows) along with the remaining five tones
(longer arrows being chromatic modifications to the seven.

The position of the basic diatonic tones, i.e., C through B, over a 12-tone octave is given by a list of
distinct semitone offsets {0, 2, 4, 5, 7, 9, 11} from the beginning of the octave, which correspond to
{C, D, E, F, G, A, B}. The remaining five tones arise through augmentations of neighboring basic
tones. The standard augmentations are given by the symbols {bb, b, #, ##} which correspond to { -2, -
1, 1, 2} semitone offsets respectively. These specify deviations on basic tones to derive the augmented
tones.
More precisely, a diatonic tone is specified by a basic diatonic tone label (e.g., C, D, …) in combination
with any one or none of the augmentation symbols (e.g., Ab, C#). For example, F## is a diatonic tone
based on F and the ## augmentation. This tone’s chromatic offset is 5(F) + 2(##) = 7, and Gb is chro-
matic offset 7(G) - 1(b) = 6. For completion, but not shown in the above diagram, for C there is Cb,
Cbb; for B, B# and B##.
Based on the above arguments, diatonic tones are not unique to chromatic offset. In other words, a
chromatic offset may correspond to several tones. To list a few, for offsets 3 and 6 respectively,
D# == Eb == Fbb, F# == Gb == E##
The tones in these equivalences are called enharmonic tones. While the existence of enharmonic tones
may seem problematic, or at worst a flaw to the diatonic system, they provide a solid foundation for
scale construction. Later we will see which enharmonic is used for a tone in a scale is contextually
based and logical and determined by the type of the scale within which one is working.
It is important to point out that the diatonic foundation as described here is a fixed conceptual structure
that provides a map of pitches to sound frequencies, an ordering and structuring of tones within all
octaves and for all pitches, along with tone and pitch naming. It is a foundational artifact for the rest of
music theory as described here. While its layout is observed to be identical to the C major scale, that is
in fact incidental. Major scales are constructed relative to any pitch on the diatonic foundation.
Each octave starts on C and comprises a collection of 12 diatonic tones. Octaves are numbered 0, 1, 2
... The terms chromatic partition, partition, and octave are often used interchangeably and that usage
should be noted particularly in the Python code.
The combination of an octave with a diatonic tone is called a diatonic pitch. A textual representation
for a pitch is “tone:octave”17. For example, middle C is “C:4” and the standard A 440hz pitch is ”A:4”.
An equivalent tuple-based representation more suitable for programming and algorithms is the diatonic
location representation of (octave, diatonic pitch), such as (5, C#), (3, D), (6, Fbb), etc., which will be
seen later.

17
This is synonymous to what is known as Scientific Pitch Notation (ref. ref. https://en.wikipe-
dia.org/wiki/Scientific_pitch_notation).

18
 2.3 Tones, Pitches, and the Diatonic Foundation

For example, computing a chromatic index from a diatonic location becomes:

(octave, tone) —> (octave, (basic_tone, augmentation))
—> (octave, (basic_tone_partition_offset, augmentation_offset))
—> 12 * octave + basic_tone_partition_offset + augmentation_offset
For example,

(4, Db) —> (4, (D, b))

—> (4, (2, -1))
—> 4*12 + 2 - 1 = 49
Finally, the C tone-based orientation for octaves on chromatic partitions is common practice, say, as
opposed to making A the start18. We point out that for transposed instruments, such as horns in F, etc.
that at least notationally, a score marking for C sounds other than given by our discussion. For example,
for a horn in F, a C in a score is a marking for F. In many ways, transposed instruments illustrate the
importance of defining a diatonic foundation as a basis for sounds/frequencies, as opposed to, say,
scales which are simply relative overlays over the diatonic foundation tones and pitches that is shown
later. We will not dwell on this topic right now. Transposed instruments are more fully discussed later.

Diatonic Tone Representation

The class DiatonicTone represents individual tones without regard to octave. This is our first presen-
tation of a non-static music related entity. That is, the user creates instances of DiatonicTone, each with
its own identity and characteristics. Reference tonal_model/diatonic_tone.py in the code base.

class DiatonicTone(object):
# Constructor
def __init__(self, diatonic_name):
diatonic_info = DiatonicTone.parse(diatonic_name)
if not diatonic_info:
raise Exception('Illegal diatonic pitch specified {0}'.format(
diatonic_name))

self.__diatonic_letter = …
self.__augmentation_symbol = …
self.__diatonic_symbol = self.diatonic_letter + self.augmentation_symbol
self.__diatonic_index = …
self.__augmentation_offset = self.__tonal_offset = …
self.__placement = …

We begin by looking the data DiatonicTone keeps per instance that defines what a diatonic tone repre-
sents, shown above. The constructor takes the name of the tone as string, parses it, using a parser much
as was introduced in ChromaticScale. Looking inside the constructor code we see seven fields define
the object. With that, we have the following fields:
• __diatonic_letter: the letter part of the tone e.g., the C in C#.
• __augmentation_symbol: The augmentation part if any, e.g., the # in C#.

18
This is surprising given the significance of the A:4 tuning mentioned earlier.

19
2 The Chromatic Scale and the Diatonic Foundation

• __diatonic_symbol: a standardized textual format for the tone, e.g., C#, using upper case for
the diatonic letter, even if specified as “c#” in constructor input.
• __diatonic_index: index of diatonic letter, e.g., C—>0, D—>1, E—>2, etc.
• __augmentation_offset: numerical value of augmentation, e.g., bb—>-2, ##—>2.
• __tonal_offset: chromatic offset of the diatonic letter plus the augmentation_offset.
• __placement: the actual position (offset) for the note on a 12-tone partition. See below.
The distinction between tonal_offset and placement is very important and deserves explanation. Dia-
tonic locations can sometimes ‘spill over’ to neighboring octaves, as we will see with pitches. For
example, Cb:5 is identical to B:4, and B#:5 is identical to C:6. The attribute tonal_offset provides an
offset relative to the start of an octave. In that case, Cb has -1 as the tonal_offset, and 12 for B#.
Placement indicates which of the 12 tones (origin 0) in an octave the tone represents, accounting for
tonal_offsets that are out of the [0, 11] range. In this case Cb is 11 (B), and B# is 0 (C). The attribute
tonal_offset is useful in calculations across the full chromatic scale, especially for determining the
actual octave a pitch is in. The attribute “placement” on the other hand precisely points out the correct
tone regardless of partition.

class DiatonicTone:
# Basic diatonic tone letters.
DIATONIC_LETTERS = list('CDEFGAB')
# Regex used for parsing diatonic pitch.
DIATONIC_PATTERN_STRING = '([A-Ga-g])(bbb|bb|b|###|##|#)?'
DIATONIC_PATTERN = re.compile(DIATONIC_PATTERN_STRING)
# Diatonic C scale indices
DIATONIC_INDEX_MAPPING = {'C': 0, 'D': 1, 'E': 2, 'F': 3, 'G': 4, 'A': 5, 'B': 6}
# Semitone offsets for all diatonic pitch letters
CHROMATIC_OFFSETS = {'C': 0, 'D': 2, 'E': 4, 'F': 5, 'G': 7, 'A': 9, 'B': 11}
# All augmentations in text representation
AUGMENTATIONS = ('bbb', 'bb', 'b', '', '#', '##', '###')
AUGMENTATION_OFFSET_MAPPING={'': 0, 'b': -1, 'bb': -2, 'bbb': -3, '#': 1,
'##': 2, '###': 3}
DIATONIC_OFFSET_ENHARMONIC_MAPPING = {
0: ['C', 'B#', 'Dbb'],
1: ['C#', 'B##', 'Db'], …

Diatonic tone includes several constants that are useful across the code base, such as:
• DIATONIC_LETTERS: the list [C, D, E, F, G, A, B].
• DIATONIC_INDEX_MAPPING: giving the index of a diatonic letter.
• CHROMATIC_OFFSETS: giving diatonic letters to chromatic offset.
• AUGMENTATIONS: listing the valid set of augmentations as string.
• AUGMENTATION_OFFSET_MAPPING: mapping augmentation (string) to a displace-
ment value.
• DIATONIC_OFFSET_ENHARMONIC_MAPPING: For each offset, the set of enhar-
monic diatonic symbols.

20
Other documents randomly have
different content
TALES of an INDIAN CAMP. In 3 vols. post 8vo. 31s. 6d.

TALES of MY TIME. By the author of "Blue Stocking Hall." In 3 vols.

post 8vo.

STORIES of WATERLOO.—Contents: Waterloo—The Field of Battle—

The Seventeenth of June—Quatre Bras—Ligny—Brussels—The Dead
Dragoon—Napoleon and his Army—The Captain of Grenadiers—The
Detachment—The Route—The Outlaw's Story—The March—Story of
Colonel Hilson—Sarsfield—Maurice Mac Carthy—The Champ de Mai—
Belgium—The Cavalry Picket—Napoleon's Return, &c. &c. In 3 vols.
post 8vo. 28s. 6d.
The CHELSEA PENSIONERS. By the author of the "Subaltern." 3 vols.
—Contents: The Gentle Recruit—A Day on Neutral Ground—Saratoga
—Maida—A Pyrenean Adventure—The Rivals.

Works published by Colburn and Bentley.

1. STORIES of a BRIDE. By the Authoress of "The
Mummy." 3 vols.
2. THE BORDERERS. An American Tale. By the Author of
"The Prairie," "The Red Rover," &c.
3. THE KING'S PAGE. A Novel. 3 vols.
4. THE DAVENELS: or, A CAMPAIGN OF FASHION IN
DUBLIN. 2 vols. 18s.
5. OLD COURT, a Novel. 3 vols.
"This Romance is the work of a very able pen."—Court
Journal.
6. RICHELIEU, A TALE OF THE COURT OF FRANCE. 3 vols.
"A very superior work, and one well calculated for extensive
popularity."—Literary Gazette.
É
7. ECARTÉ; or, the Salons of Paris. 3 vols. 28s. 6d.
8. THE NAVAL OFFICER; or, Scenes and Adventures in the
Life of Frank Mildmay. 3 vols.
9. WALDEGRAVE. A Tale of the South. 3 vols. 27s.
10. RYBRENT de CRUCE. 3 vols. 28s. 6d.
"The production of an intelligent and cultivated person."—
New Monthly Magazine.
"This is a very clever novel."—Literary Gazette.
11. GERALDINE of DESMOND; or, Ireland in the Reign of
Elizabeth. 3 vols.
"The work will take its station among the best historical
romances that have ever been written."—Cheltenham
Chronicle.
12. BLUE STOCKING HALL. Second Edition. 3 vols. 27s.
13. TALES of a VOYAGER to the ARCTIC OCEAN. Second
Series. 3 vols.
14. THE CARBONARO. A Tale, by the Duke de Levis. 2 vols.
15. THE SECTARIAN; or, The CHURCH and the MEETING-
HOUSE. 3 vols.
16. TALES of WOMAN, Illustrative of the Female Character. 2
vols.
17. THE MAN of TWO LIVES. A Narrative, Written by Himself.
2 vols.
18. THE CASTILIAN. A Spanish Tale. 3 vols.
 TRANSCRIBER'S NOTE:
Obvious printer errors have been corrected. Otherwise, the author's original spelling,
punctuation and hyphenation have been left intact.
*** END OF THE PROJECT GUTENBERG EBOOK THE EXCLUSIVES
(VOL. 3 OF 3) ***

Updated editions will replace the previous one—the old editions

will be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States
copyright in these works, so the Foundation (and you!) can copy
and distribute it in the United States without permission and
without paying copyright royalties. Special rules, set forth in the
General Terms of Use part of this license, apply to copying and
distributing Project Gutenberg™ electronic works to protect the
PROJECT GUTENBERG™ concept and trademark. Project
Gutenberg is a registered trademark, and may not be used if
you charge for an eBook, except by following the terms of the
trademark license, including paying royalties for use of the
Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such
as creation of derivative works, reports, performances and
research. Project Gutenberg eBooks may be modified and
printed and given away—you may do practically ANYTHING in
the United States with eBooks not protected by U.S. copyright
law. Redistribution is subject to the trademark license, especially
commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the

free distribution of electronic works, by using or distributing this
work (or any other work associated in any way with the phrase
“Project Gutenberg”), you agree to comply with all the terms of
the Full Project Gutenberg™ License available with this file or
online at www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand,
agree to and accept all the terms of this license and intellectual
property (trademark/copyright) agreement. If you do not agree
to abide by all the terms of this agreement, you must cease
using and return or destroy all copies of Project Gutenberg™
electronic works in your possession. If you paid a fee for
obtaining a copy of or access to a Project Gutenberg™
electronic work and you do not agree to be bound by the terms
of this agreement, you may obtain a refund from the person or
entity to whom you paid the fee as set forth in paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only

be used on or associated in any way with an electronic work by
people who agree to be bound by the terms of this agreement.
There are a few things that you can do with most Project
Gutenberg™ electronic works even without complying with the
full terms of this agreement. See paragraph 1.C below. There
are a lot of things you can do with Project Gutenberg™
electronic works if you follow the terms of this agreement and
help preserve free future access to Project Gutenberg™
electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright
law in the United States and you are located in the United
States, we do not claim a right to prevent you from copying,
distributing, performing, displaying or creating derivative works
based on the work as long as all references to Project
Gutenberg are removed. Of course, we hope that you will
support the Project Gutenberg™ mission of promoting free
access to electronic works by freely sharing Project Gutenberg™
works in compliance with the terms of this agreement for
keeping the Project Gutenberg™ name associated with the
work. You can easily comply with the terms of this agreement
by keeping this work in the same format with its attached full
Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.

1.E. Unless you have removed all references to Project

Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project
Gutenberg™ work (any work on which the phrase “Project
Gutenberg” appears, or with which the phrase “Project
Gutenberg” is associated) is accessed, displayed, performed,
viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the

United States and most other parts of the world at no
cost and with almost no restrictions whatsoever. You
may copy it, give it away or re-use it under the terms
of the Project Gutenberg License included with this
eBook or online at www.gutenberg.org. If you are not
located in the United States, you will have to check the
laws of the country where you are located before using
this eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is

derived from texts not protected by U.S. copyright law (does not
contain a notice indicating that it is posted with permission of
the copyright holder), the work can be copied and distributed to
anyone in the United States without paying any fees or charges.
If you are redistributing or providing access to a work with the
phrase “Project Gutenberg” associated with or appearing on the
work, you must comply either with the requirements of
paragraphs 1.E.1 through 1.E.7 or obtain permission for the use
of the work and the Project Gutenberg™ trademark as set forth
in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is

posted with the permission of the copyright holder, your use and
distribution must comply with both paragraphs 1.E.1 through
1.E.7 and any additional terms imposed by the copyright holder.
Additional terms will be linked to the Project Gutenberg™
License for all works posted with the permission of the copyright
holder found at the beginning of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files
 containing a part of this work or any other work associated with
Project Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute

this electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the
Project Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if
you provide access to or distribute copies of a Project
Gutenberg™ work in a format other than “Plain Vanilla ASCII” or
other format used in the official version posted on the official
Project Gutenberg™ website (www.gutenberg.org), you must,
at no additional cost, fee or expense to the user, provide a copy,
a means of exporting a copy, or a means of obtaining a copy
upon request, of the work in its original “Plain Vanilla ASCII” or
other form. Any alternate format must include the full Project
Gutenberg™ License as specified in paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™
works unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or

providing access to or distributing Project Gutenberg™
electronic works provided that:

• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
 payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project

Gutenberg™ electronic work or group of works on different
terms than are set forth in this agreement, you must obtain
permission in writing from the Project Gutenberg Literary
Archive Foundation, the manager of the Project Gutenberg™
trademark. Contact the Foundation as set forth in Section 3
below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on,
transcribe and proofread works not protected by U.S. copyright
law in creating the Project Gutenberg™ collection. Despite these
efforts, Project Gutenberg™ electronic works, and the medium
on which they may be stored, may contain “Defects,” such as,
but not limited to, incomplete, inaccurate or corrupt data,
transcription errors, a copyright or other intellectual property
infringement, a defective or damaged disk or other medium, a
computer virus, or computer codes that damage or cannot be
read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU AGREE
THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT
LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT
EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE
THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person
or entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set

forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you
do or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status
by the Internal Revenue Service. The Foundation’s EIN or
federal tax identification number is 64-6221541. Contributions
to the Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact
 Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or determine
the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.