Durations and DurationTuples

If you don’t do a lot with Tuplets (Triplets, etc.) and have never heard of a DurationUnit, this is a post to skim. :-)

Music21 has the ability to consider two different incompatible ideas of a note as a note.Note (or note.Rest, chord.Chord, etc.): a note on a page and a note as heard.

(1) When we write a note on a page, it has certain properties: stems, flags, beams, dots, ties, tuplets, etc. Consider a half note tied to an eighth note.  On the page these are definitely two notes — we read them as two notes and then sound them together because of the tie.

(2) Now consider a single sound from a trumpet, at quarter note = 60, which lasts 2.5 seconds.  This is a note.  One note.  But try to notate it.  You’ll find that it takes two notes on the page to notate it: a half note and an eighth note, tied together.  But when we hear this sound, it sounds like one note.

How can we represent the second type of note in music21 even though it can’t be notated as a single note (well, not normally; more on that below)? Simple, we create a single Note object, which has a single Duration object.  That Duration object, however, has two elements in its “.components” list — a component corresponding to a half note, and a component corresponding to an eighth note.  The note’s overall duration has a type of “complex”.  When sending this Note out to MusicXML, Lilypond, etc., we split it into two notes (you guessed it, a half note and an eighth note).  We then look at something called “linkage” to see that each of these notes should be connected by a Tie.  (Rests have no linkage, for instance).  When we send it out to MIDI, on the other hand, we can leave it alone as one Note, since MIDI doesn’t support ties, but does support arbitrary lengths of notes.

So, this has been the music21 model since alpha 1, and in general it remains the model.

What has changed in the newest GitHub repository and will change in the next 2.X release is what these “.components” are.  Up until now they’ve been an object called DurationUnit — an amazingly flexible object created by Chris Ariza that can represent everything that a “simple” duration does; DurationUnits can have tuplets, dot-groups (an obscure medieval term), and just about everything else you can think of.  They’re extremely cool, and I’m going to miss them.

In music21 2.X, the components of a complex duration are called DurationTuples.  They are much simpler objects that only store three pieces of information: the type (‘whole’, ‘half’, ‘16th’, etc., plus ‘zero’), the number of dots, and the quarter length of that component.  They don’t have tuplets, dot groups, etc.  And they’re called Tuples because they derive from namedtuple which derives from the Python tuple object — in other words they are immutable.  Once a DurationTuple is set, it can’t be changed.  To change a note’s duration from whole to half, the DurationTuple needs to be deleted from .components and a new one created and inserted.  So they do everything a DurationUnit does and much less.

So, why the change?  Amazing flexibility and power, such as DurationUnits offer, comes at a price: speed.  And complexity.  The new DurationTuple makes creating the most common type of Duration with a single component much faster.  The amount of time to do: “d = duration.Duration(1.0); d.type” has been cut by over half.  This makes the creation of Notes about 20% faster than before (well, after the first check of durations), which is a pretty substantial improvement.  And as Dmitri and others have noticed, there are a lot of ways to change the duration of a Note that can affect other things, such as Streams.  This change reduces the complexity by making it so that only the Duration object itself can change its duration.  Changes to underlying .components are impossible to make since DurationTuples are immutable.

The only practical effect that most users are likely to see is in the use of Tuplets.  In the past tuplets lived on DurationUnits.  This meant for instance that a Duration could represent a single duration of “half-note-tied-to-eight-note-triplet” (QL: = 2.333333333).  Now, all the components of a Duration need to have the same tuplet or nested tuplets.  So this duration can be represented as a (dotted-half-note + eighth note) triplet.  Or it can be represented as (do the math, but only when you have time) a single whole-note in an 12:7 tuplet (because the latter is easier to determine for the computer to do, that’s what is done right now, but that could change).  

The other practical change in Tuplets is that there are generally three aspects to a Tuplet (well, four, but we’ll keep it simpler): the number of “actual” notes (3 for a triplet), the number of “normal” notes (2), and the durationNormal (‘eighth’, no dots, for instance).  In theory, once a tuplet was attached to a note, it became immutable (frozen), but because normal note was a DurationUnit, it was possible to create the tuplet and then to change the normal note type, or dots, or whatever.  Now that durationNormal references a DurationTuple, it is immutable; so instead of this:

   t = duration.Tuplet()

   t.durationNormal.type = ‘quarter’

or do this:

   t = duration.Tuplet(‘durationNormal’ = ‘eighth')

or if you must:

   t = duration.Tuplet()

   t.durationNormal = duration.durationTupleFromTypeDots("eighth", 0))

(this may go away, tuplets might become fully immutable in the future)

I hope these changes make using the system faster without much trouble.

Speed, Speed, Speed, ... and news.

The newest GitHub repository contains a huge change to the under-the-hood processing of .getContextByClass() which is used in about a million places in music21.  It is the function that lets any note know what its current TimeSignature (and thus beatStrength, etc.) is, lets us figure out whether the sharp on a given note should be displayed or not given the current KeySignature, etc.  While we had tried to optimize the hell out of it, it’s been a major bottleneck in music21 for working with very large scores. We sped up parsing (at least the second time through) a lot the last commit. This was the time to speed up Context searching.  We now use a form of AVL tree implemented in a new Stream.timespans module — it’s not well-documented yet, so we’re only exposing it directly in one place, stream.asTimespans(recurse=True|False).  You don’t need to know about this unless you’re a developer; but I wanted to let you know that the results are extraordinary.

Here’s a code snippet that loads a score with three parts and 126 measures and many TimeSignatures and calculates the TimeSignature active for every note, clef, etc. and then prints the time it takes to run:

>>> c = corpus.parse('luca/gloria')

>>> def allContext(c):

...     for n in c.recurse():

...         k = n.getContextByClass('TimeSignature')

... 

>>> from time import time as t

>>> x = t(); allContext(c); print t() - x

with the 1.8 release of Music21:

42.9 seconds

with the newest version in GitHub:

0.70 seconds

There’s a lot of caching that happens along the way, so the second call is much faster:

second call with 1.8 release:

44.6 seconds ( = same within a margin of error)

with the newest version in GitHub if the score hasn’t changed:

0.18 seconds

You’ll see the speedup immensely in places where every combination of notes, etc. needs to be found.  For instance, finding all parallel fifths in a large score of 8 parts could have taken hours before. Now you’ll likely get results in under a few seconds.

I have not heard of any issues arising from the change in sorting from the last posting on April 26, so people who were afraid of updating can breath a bit more easily and update to the version of music21 at least as of yesterday. The newer version, like all GitHub commits, should be used with caution until we make a release.

Thanks to the NEH and the Digging into Data Challenge for supporting the creation of tools for working with much bigger scores than before.

In other news: 

Music21j — a Javascript implementation of music21’s core features — is running rapidly towards a public release.  See http://prolatio.blogspot.com/2014/05/web-pages-with-musical-examples.html for an example of usage.  We’ll be integrating it with the Python version over the summer.

Ian Quinn’s review of Music21 appeared in the Journal of the American Musicological society yesterday.  Prior to this issue, no non-book had ever been reviewed. It’s a great feeling to have people not on this list know about the software as well.

Oh, and MIT was foolhardy enough to give me tenure! Largely on the basis of music21.  If you’re an academic working on a large digital project, I still advice proceeding with caution, but know that it can be done.  Thanks everyone for support.

How high do your singers need to sing to do this piece?

Here's one way of figuring it out:

(see the original blog post if your reposting turns this code into goobley-gook...)

import copy
import music21
from music21 import corpus, meter, stream
    
score = corpus.parseWork('bach/bwv366')
ts = score.flat.getElementsByClass(meter.TimeSignature)[0]
ts.beat.partition(3)
    
found = stream.Stream()
for part in score:
    found.append(part.flat.getElementsByClass(music21.clef.Clef)[0])
    highestNoteNum = 0
    for m in part.measures:
        for n in m.notes:
            if n.midi > highestNoteNum:
                highestNoteNum = n.midi
                highestNote = copy.deepcopy(n) # optional
  
                # These two lines will keep the look of the original
                # note values but make each note 1 4/4 measure long:    
                highestNote.duration.components[0].unlink()
                highestNote.quarterLength = 4

                highestNote.lyric = '%s: M. %s: beat %s' % (
                    part.getInstrument().partName[0], 
                    m.measureNumber, ts.getBeat(n.offset))
    found.append(highestNote)

found.show()

... which generates this snippet of notation...



...showing that for at least one piece, Bach was (probably accidentally) using the old medieval authentic, plagal, lower-octave-authentic, lower-octave-plagal, range designations!

This code is still needlessly complicated -- we're still working on simplifying it (notes will know their own clefs and beats; '3/4' will know that it should be divided into 1+1+1), but just a little taste of what's possible.

Oh, and just for fun, all the C#s in the piece with this code snippet substitution:. Or discover that all the raised leading tones in this d-minor composition happen on the two strongest beat of a measure:

             if n.name == 'C#':
                ...
                found.append(n)

Music21 Preview -- Welcome! Creating measures

This is a preview of the music21 system for computer-aided musicology being developed at MIT (Michael Scott Cuthbert, Asst. Prof., Principal Investigator; Christopher Ariza, Visiting Asst. Prof., Development Lead). We’ll be using this blog to showcase some of the features of the system, and to highlight other interesting things happening in computational, statistical, and other empirical methods in musicology.

Although computers have transformed how we listen to, obtain, compose, and notate music, they have not fundamentally changed how we research and analyze music. Though many computer databases have been created for musicology, they are not well adapted for sophisticated music queries. For instance, melodies can be found if exact matches exist. But melodic variations such as the repetition of a phrase or a change in embellishment are extremely common, yet cause searches to fail. More complex investigations, such as finding all melodies that imply a particular underlying harmony, can barely begin to be created with existing software packages. The lack of relevant software for analyzing music hampers scientific attempts to understand what we listen for and how we process what we hear; these activities are little understood despite music’s nearly universal presence in our daily lives.

The music21 project at M.I.T. will give to the music community the set of tools it needs to conduct sophisticated musical and statistical analysis using modern programming techniques. The software framework, written in Python, manipulates music as a collection of symbolic data, such as pitch names and note durations, that can then be classified as higher level musical structures according to the style, region, or period being studied.

Music21 focuses specifically on the manipulation of symbolic music data: it leaves to the many preexisting open-source and proprietary software packages the notation and audio playback of scores (the two areas where computer-aided music research is most developed). By focusing on the points of greatest need to musicology, the framework will give rapid results within a short timeframe.

The music21 framework will be freely available in early 2010 under the LGPL open source license. (Ed. - later changed to BSD license).

Some demos:

from music21 import *

n = note.Note("F#4")
n.quarterLength = 3

a = stream.Stream()
a.repeatAdd(n, 20)  # add 20 copies of n

a.insertAtOffset( 0, meter.TimeSignature("5/4"))
a.insertAtOffset(10, meter.TimeSignature("2/4"))
a.insertAtOffset( 3, meter.TimeSignature("3/16"))
# N.B. they don't have to be inserted in order

a.insertAtOffset(20, meter.TimeSignature("9/8"))
a.insertAtOffset(40, meter.TimeSignature("10/4"))
a.insertAtOffset(50, meter.TimeSignature("29/32"))
a.show()

Click to expand