White.Steve.Blog : Music theory

Scales

stevewhitepsfd — Sat, 12 Mar 2005 20:59:00 GMT

So I’ve talked about classes representing the ideas of note and interval. This post I’ll cover Voices.ScaleClass, Voices.Scale and Voices.KeySignature.

A scale is an interesting interplay between notes and intervals within an octave. As an example, the notes C D E F G A B constitute the C major scale. But it is the set of intervals between these notes (the sum of which is an octave) which defines the essence of what it is to be a major scale. Specifically, these intervals are: maj2 maj2 min2 maj2 maj2 maj2 min2. Typically the intervals are summed cumulatively with the initial perfect unison and the final perfect octave assumed, so: maj2 maj3 per4 per5 maj6 maj7. That set of intervals, measured out above a tonic note, locates and names the notes of any major scale.

Although a scale can be viewed as a series of notes or as a series of intervals, it’s practical to see the notes as the scale and the intervals as the scale class. So a scale can be defined as a sequence of notes, chosen out of the possible notes in the octave, and beginning on a tonic. And a scale class can be defined as the class of scales between whose notes appears the same sequence of intervals. As I’ve said, that sequence of intervals sums to an octave no matter what the scale class.

So, let’s look at a C# class representing scale class. Greatly simplified, Voices.ScaleClass looks like:

public class ScaleClass

{

static ScaleClass()

{

_majorScale = new ScaleClass("Major", "2 3 4 5 6 7");

_dorianMode = new ScaleClass("Dorian Mode", "2 b3 4 5 6 b7");

...

_bluesScale = new ScaleClass("Blues Scale", "b3 4 b5 5 b7");

}

public static ScaleClass MajorScale { get { return _majorScale; } } static ScaleClass _majorScale;

public static ScaleClass IonianMode { get { return _majorScale; } }

public static ScaleClass DorianMode { get { return _dorianMode; } } static ScaleClass _dorianMode;

...

public static ScaleClass BluesScale { get { return _bluesScale; } } static ScaleClass _bluesScale;

internal ScaleClass(string longName, string intervalsString)

{

_longName = longName;

_intervalsString = intervalsString;

}

internal string _longName;

internal string _intervalsString;

}

The only real value this class provides is a place to store the _intervalsString field. This field contains a string representation of the sequence of intervals which give the scale class its identity. These intervals have the format of an optional sharp or flat symbol followed by a digital interval quantity. Alternatively they can be the solfeggio symbols: do, di, ra, re, ..., te, ti.

The class Voices.Scale has a constructor with the signature:

public Scale(ScaleClass scaleClass, Note tonic)

What this constructor is interested in is the tonic note and the _intervalsString from scaleClass. It String.Splits intervalsString into a string[] the elements of which it then takes in turn and obtains an Interval from by means of the following method on Voices.Interval:

internal static Interval Interval.LookUp(string abbreviation)

The constructor proceeds to add each resulting Interval in turn to the tonic Note, thus obtaining the degrees of the scale. It’s a little more complicated than than because Voices.Scale is actually composed of a doubly-linked cyclic list of Voices.ScaleTone.

So, of the list nodes (i.e. the tones) in a Scale, those which are ScaleDiatones are the ones corresponding to the tonic note and the notes reached by adding the intervals of the scale class to it. All the rest are plain old ScaleTones.

In order to support enumeration, Voices.Scale implements IEnumerable and its implementation of IEnumerable.GetEnumerator simply returns a new instance of the Voices.ScaleToneEnumerator class. As is typical, ScaleToneEnumerator Resets its Current state to ‘one before the first element’ which in this case is the tone at the 11-o’clock position. It implements MoveNext by moving to ScaleTone.Sharp until the 11-o’clock position is reached again.

The last class I’ll talk about in this post is KeySignature. A key signature is a pattern of sharp or flat symbols written at the beginning of a musical staff to indicate which degrees of the scale are not natural. Strictly speaking, distinct key signatures exist only for fifteen major scales. Minor scales and the remaining modes re-use the key signatures of their relative major scale. I omitted this detail above for the sake of clarity, but one of the arguments to the ScaleClass constructor is a value from the ScaleClass.Mode enumeration, which looks like this:

public enum Mode

{

Major = 0,

Dorian = 6,

Phrygian = 5,

Lydian = 4,

Mixolydian = 3,

Minor = 2,

Locrian = 1

}

There is a field for each mode. The value given to each field represents the degree of the corresponding mode on which the mode’s relative major begins. For example, you may know that the major mode begins on the minor mode’s third degree. This is why Minor has the value 2 (where 0 means first). The constructor of the class Voices.Scale reads n, the integer value of its ScaleClass’s Mode, and then finds the nth degree of the scale being constructed. This way it identifies the major scale on which the scale is based and it is that scale which donates its key signature.

The important parts of the KeySignature class are:

public Note[] Accidentals

{

get

{

return _accidentals;

}

internal Note[] _accidentals;

public bool Sharps

{

get { return _sharps; }

}

internal bool _sharps = true;

The Accidentals property returns an array of Notes in key signature order, and the Sharps property tells us whether the accidentals are sharps or flats.

Starting over with Voices.Interval

stevewhitepsfd — Fri, 18 Feb 2005 08:18:00 GMT

In the previous post in the Voices category I showed my re-imagined Voices.Note class and its close relatives. You can already see that the new design has a useful separation of tone from note. I had also mixed solfeggio and scale into my initial, abandoned, design. I’ll come to scale in the future but, in this post, I’ll show why solfeggio is, and should remain, distinct from note. At the same time I’ll introduce the second fundamental of music - interval. By the way if you want to know more about music theory check out the articles I’ve posted under the Voices Help category. These articles will be developed further over time.

So, the reason I’d made a horrific hybrid of solfeggio and note the first time round (like Seth Brundle spliced with the fly) was because I hadn’t appreciated what solfeggio is, or at least what the best way to interpret solfeggio is. Warburton’s Harmony is not alone in presenting solfeggio as a kind of algebra for notes. You’ll find many definitions describing the solfeggio syllables as the ‘notes of a scale’, and very few point out that they’re more usefully thought of as aliases for intervals above some scale tonic. So do is equivalent to perfect unison; di is augmented unison; me is major third; mé is minor third, and so on.

With solfeggio and interval neatly unified, I’ll now turn to interval itself and show how I implemented and optimised it in the Voices.Interval class. The kind of client code I want the Voices class library to be able to support is:

Note n1 = Note.C;

Interval interval = Interval.Second.Major;

Note n2 = n1 + interval.Inverse;

If you have experience of music theory you’ll know that an interval has two components – quality (e.g. major) and quantity (e.g. second). In my first, abandoned, version of Voices.Interval I gave the class just such fields. On top of those I gave it fields storing the number of compound intervals (for intervals greater than an octave) and the number of times the interval was diminished or augmented (which could be zero). It took me a long time and about 900 lines of C# to get the Interval class correct in its first version. Its methods (e.g. DecrementQuantity and IncrementQuantity), properties (e.g. Octaves) and operators were long and full of tortuous boundary condition logic.

What I’d missed is that there was no need to represent the state of an interval so literally. It eventually occurred to me that every note is some interval above or below C4. And you can represent the private state of any interval – ascending or descending, simple or compound – by the note which is that interval away from C4. It only remained to implement the properties in terms of that internal state by reusing the Voice.Note class and the methods, properties and operators I’d already implemented on it. This change was done surprisingly quickly and it was a real education to me that note and interval really are two aspects of the same idea. In lines of code the new class is well over a third shorter than its first incarnation. An extreme example is the Octaves property’s set clause which was reduced from 64 lines to 1 because Voices.Note has its own Octaves property.

The new Voices.Interval class, plus its nested and ancillary types, is around 2,500 lines of C# and it looks like this:

public class Interval : IComparable

Public Ancillary Types

class IntervalException : ApplicationException

enum IntervalQuantity

enum IntervalQuality

Public Nested Types

class GeneralIntervalList : IList, IEnumerator

abstract class GeneralInterval : IList, IEnumerator

class Unison : GeneralInterval

class Second : GeneralInterval

...

class Fifteenth : GeneralInterval

Public Fields

static bool NameIsAbbreviated

static bool NameIncludesCompoundText

static bool NameIncludesDirection

Public Constructors

Interval(Interval)

Interval(Interval interval, Int32 additionalAlteration)

Interval(Interval interval, Int32 additionalAlteration, Int32 additionalOctaves)

Interval(Interval interval, Int32 additionalAlteration, Int32 additionalOctaves, bool reverseDirection)

Public Properties

static Unison GeneralUnison { get; }

static Second GeneralSecond { get; }

...

static Fifteenth GeneralFifteenth { get; }

bool IsImmutable { get; }

bool IsAscending { get; }

Interval Complement { get; }

Interval Inversion { get; }

Interval Reverse { get; }

Int32 Alteration { get; set; }

Int32 Octaves { get; set; }

IntervalQuantity Quantity { get; set; }

IntervalQuality Quality { get; set; }

string CompoundTextTextual { get; }

string CompoundTextDigital { get; }

string AlterationText { get; }

string Name { get; }

Int32 Semitones { get; }

bool IsCompound { get; }

bool CanBePerfect { get; }

Interval SimpleInterval { get; }

Public Methods

void DecrementQuantity()

void IncrementQuantity()

void Diminish()

void Augment()

string GetName(bool abbreviated)

string GetName(bool abbreviated, bool includesCompoundText)

string GetName(bool abbreviated, bool includesCompoundText, bool includesDirection)

static bool Exists(IntervalQuantity quantity, IntervalQuality quality)

string ToString()

static Interval operator+(Interval lhs, Interval rhs)

static Interval operator-(Interval lhs, Interval rhs)

static bool operator==(Interval lhs, Interval rhs)

static bool operator!=(Interval lhs, Interval rhs)

static bool operator>(Interval lhs, Interval rhs)

static bool operator>=(Interval lhs, Interval rhs)

static bool operator<(Interval lhs, Interval rhs)

static bool operator<=(Interval lhs, Interval rhs)

bool Equals(object obj)

bool Equals(Interval rhs)

bool IdenticalTo(Interval rhs)

int GetHashCode()

int CompareTo(object arg)

By the way, I made Voices.Note a value type as I know I’ll be using a lot of Note[]. I don’t suspect I’ll be doing that with Interval, so I’ll leave it a reference type until there’s any good reason to change it.

Starting over with Voices.Note

stevewhitepsfd — Wed, 02 Feb 2005 04:20:00 GMT

So this year I threw away my code and started again. I believe that the two fundamentals of music are note and interval and that all else (scale, chord, etc) is build from them. Rhythm (i.e. time) is an orthogonal dimension and I’ll save that for much later. This post I’ll talk about my Note class.

So, last post I showed a diagram of how I’d modelled a circle of notes. You can see the circle and peanut shapes in that diagram: the peanuts are there to show notes with enharmonic names. I think I’d failed to separate out the ideas of tone, note, solfeggio, and scale in my original classes. A static class diagram of just a few of them looks like:

Furthermore, I’d written a ChromaticScale and a MajorScale class built from ScaleToneNames. The MajorScale doubled as a representation of the natural note names (i.e. the white piano-keys). I then used CodeDom together with a set of IntervalCycle instances with hardcoded intervals to generate classes for another ten scales including the modes and the minor scales.

My interval class left a lot to be desired and had few operators; the logic for generating a scale of ScaleToneNames from intervals was tortuous; the code which allowed Notes and Intervals to interact was not general; and the project was bloated with too many classes and too much code. I needed a re-think.

So, what’s the definition of a note? What comes to mind? A physical division on an instrument (piano-key, fretted guitar-string)? Or is a piano-key only a note when it’s played? Maybe you feel a note is something theoretical so that the same piano-key is sometimes the note C# and sometimes Db whether it’s sounded or not? Is a note something you can point at, press, and finger; or something you hear; or something you distinguish by its name and notate on paper? All these ideas are important but I think it’s necessary to give them unique names for the sake of clarity.

In 12-TET (twelve-tone equal temperament), the octave class is divided up into twelve pitch classes. Just like in the abbreviation TET, you’ll almost always hear these pitch classes referred to as tones so I’ll do the same to distinguish them from the idea of note.

Since an octave rolls around into its neighbours, it’s useful to consider only the octave class and to present it visually with its twelve tones arranged like the hour positions of a clock-face.

I’ve called this arrangement, and its corresponding C# class the TwelveToneClock. It’s composed of twelve Tones. As you can see, some tones have names and some don’t. So, derived from Tone are NamedTone (with a Name property) and UnnamedTone. Although the unnamed tones can be named in relation to the named ones (any of them in fact, but typically a neighbour), it’s also important to the theory of tonal harmony that a natural name can be overridden. For example, the tone at the twelve o’clock position is typically used as the note C natural, but a good musical model should allow for it to theoretically become the note B# or even Dbb. It’s in this (en)harmonic sense that I’ll define the Note class.

A Note, then, is defined as a reference to a NamedTone along with scalar properties representing the note’s octave number (approximately 1-8 on the piano, but capable of being much wider) and how many semitones that NamedNote has been sharpened or flattened (therefore a signed integer, typically in the range -1 to 1) known as its alteration. And here’s the relevant portion of the new static class diagram:

My first (false) start at the Voices project

stevewhitepsfd — Sun, 30 Jan 2005 09:36:00 GMT

So, the middle of last November I started doing some thinking and designing and putting some C# classes together in a library. It was a bit of a false start as I’ll explain, so this year I started the project afresh with the benefit of what I’d learned. I’ll get to the starting-over in later posts but first I’ll talk about what I did wrong the first time around and what I failed to understand correctly at the time.

It was a combination of note names and solfeggio that conspired to confuse me. It wasn’t about how notes are named in a diatonic scale, because I was only considering notes roaming untethered in their wild state. I was thinking about the possible names a note could have as it sat on the piano or on the guitar, and I came up with a good idea but then made a schoolboy error. The good idea was to abstract the notes away from their instrument and visualize them in a circle so that I was working with an instrument-agnostic format. My error followed from something I misunderstood in Annie O. Warburton’s book Harmony.

In her book, Warburton introduces the solfeggio names do, re, mi, fa, sol, la and ti (although she spells them her own way) as a kind of algebra for the seven notes in any major scale. For example, the C major scale begins C-D-E-F, and the B major scale begins B-C#-D#-E-, but what those two sequences of notes have in common – what makes them both major – is the pattern of musical intervals between neighboring notes. So we can represent the notes of any major scale as the algebraic symbols do-re-mi-fa- and so on, so long as we define the musical intervals between neighboring symbols as being those of the major scale. So far, so simple.

But there’s a scale called the chromatic scale. It’s arguably not a true scale as it’s nothing more than all twelve notes of the octave in sequence. Its intervals are all the same size – physically a semitone; some are augmented unisons, some are minor seconds. Warburton writes that the solfeggio names in the ascending chromatic scale are do-di-re-ri-mi-fa- and so on, and in the descending chromatic scale they end fa-mi-mé-re-ra-do. With do (the tonic) as the note C, these names become C-C#-D-D#-E-F-, etc., ascending and end F-E-Eb-D-Db-C descending. So some notes (e.g. C, D) have the same name in either direction and some (e.g. C#/Db, D#/Eb) change their name. Distracted and charmed by the altered solfeggio notes such as di (which can be thought of as do sharp and represents C# in C major), I believed that the solfeggio names had all the possible note names covered – and that was mistake number one. I also believed, taking my lead from Warburton’s note spellings in the chromatic scale, that whenever you sharpened a C you got C# and whenever you sharpened C# you got D. Descending, I thought that whenever you flattened a D you got Db and whenever you flattened Db you got C. Of course, not all those are correct. It led me to a diagram of a note-circle like this:

The dotted arrows show the direction a note moves when it is sharpened or flattened by a semitone, and their destination shows what I thought the resultant name had to be. In fact, if you sharpen C# you do get a note with the same pitch as D but you call it C double-sharp (C## or Cx). There’s actually a lot more to sharpening and flattening notes than I’m telling here because the only meaningful harmonic operation on a note is to add a directed interval. But more on that in the future. In any case, I realized my design wasn’t quite right.

The diagram implies that there’s something special about the peanut shapes because they have two possible names. But I’d forgotten the existence of notes like Cb (same pitch as B), B# (same pitch as C) and Ebb (same pitch as D). In fact, theory allows for any note to be given many names. A diagram showing all the possible theoretical note names and arrows between them would be far too large and busy to be useful.

Next time I’ll look at the right way to model notes and intervals. Incidentally, what Warburton’s book doesn’t say explicitly, but you can figure out, is that the solfeggio names are not simply algebra for note-names. What’s important about them is the interval between one name and the next. But you can also accumulate those intervals and know what interval any solfeggio name is above the tonic of the scale. If you know a sequence of intervals above a tonic note then you know everything you need to know about a scale class and you can place the tonic on any of twenty-one note names and know twenty-one scales of that scale class. Therefore what solfeggio really represents is a set of aliases for intervals. If you’re unsure what an interval is then have a look at my music training articles.