A Flexible Toolkit for Computer-Aided Musicology; Michael Scott Cuthbert, creator
Friday, September 11, 2015
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: