It Could Be Very Fresh:
Structure, Repetition, and Reception in Einstein on the Beach (1999; part 1)
Structure of the Opera
2 Throughout this paper, small caps will be used to denote motives in the opera. These motives can be found in charts in the appendix.
Addition of Wilson's Comment
Visual and Non-musical Structures
To be fair, ‘Einstein’ was a co-creation of Mr. Wilson and Philip Glass, the composer. But most people not only saw it as basically Mr. Wilson’s work—so much so that Mr. Glass was openly aggrieved, and has declined further collaboration with Mr. Wilson—but as the capstone to a series of remarkable large-scale Wilson theatrical creations that dated back to the 1960s. (New York Times, 26 November 1978, p. 5)
The transformations of the train into building and spaceship in Act 4 also have their roots in relativity thought experiments. The building, seen from both the front and side simultaneously, is a demonstration of how observers at rest see light reflected off objects moving at high speeds.11
The spaceship image, in addition to being a standard demonstration of relativistic length contraction (along with a rotating ruler or stick or an oblong clock which are also seen in the opera) hints at the prospects for future nuclear apocalypse which Einstein’s work on nuclear physics made a frightening possibility.12
The length contraction demonstrated by the spaceship manifests itself in several other ways in the opera. The tall, narrow chairs used throughout the opera are examples of this physical phenomenon on stage. Further analysis of how the staging parallels the teachings and life of Einstein will have to await a video viewing of the opera.
Ambiguity and Certainty in Minimalist Processes
Dublin Conference on Music Analysis, June 2005
(2015): The paper began with several definitions of process in minimalism which were given in expanded form in other articles. They will be put in a separate post. It ended with discussions of process in Lucier and Beethoven, which will also be put in a separate post. What remains here are the elements of the paper that fit into the narrow niche of Ambiguity and Certainty. For this reason, Figure numbers do not begin at 1.
I’m mostly going to confine myself to “top 40” minimalist pieces; the hits, in order to keep things in more familiar territory. Let us consider a passage from Glass and Wilson’s Einstein on the Beach, given in a modified score as Figure 4. The music is taken from the connecting passage between the first and second acts, Knee Play 2.
Although the work uses only two rhythmic values (quarter and eighth notes) and simple diatonic intervals favoring stepwise motion and motion by thirds--in a word, simple--the melodic line is constructed with practically no repetitions among various sections. The line has enough distinct material that even very short melodic sections played by any musician and which jump out of the texture give enough information to identify where each instrument is in the melody. Figure 7 gives a list of the places where hearing two or more notes is insufficient to precisely locate a player within the sixty-five-note score.
There are fifteen two-note segments which do not identify the player's location. These represent thirty-three of the sixty-four possible two-note starting places, or about half. If three contiguous notes can be heard from a single instrument in the texture, then there are only five segments that do not identify the location of the player. In fifty-five of the sixty-three possible places, the musician's position in the score will be known to the listener. With four contiguous notes, there are only two places of ambiguity, and with five notes, the listener always can have complete certainty of a musician's location.
I am not saying that Rzewski has purposely arranged his material to create maximum distinctiveness—in fact, I had a computer program generate 1000 random melodies, sharing only Rzewski’s notes and rhythms and his predilection for stepwise and 3rd motion, and the results were similar.5 The distinctiveness of short motives is not a result of his ordering, but rather of his choice of melodic material (non-tonally oriented skips and no apparent reason behind the choice of longer notes) and the lack of any distinctive ordering. We can contrast the 65 notes of Moutons with the first 65 notes of the clarinet entrance of Mozart’s concerto. Hearing any isolated note in Mozart’s work will give you a better idea of your location in the work, but there are many more locations where hearing three, four, or even five or six notes will not pinpoint your location. A movement from a Bach solo ’cello suite would almost certainly have a lower level of distinctiveness by this metric.
A similar effect can be heard in Satie’s oft-cited “proto-minimalist” work, Vexations, whose bass line is given in Figure 8.
Here Satie has composed the line out of extremely distinctive intervals, approaching the construction of an all-interval set. Any two consecutive pitches or intervals in the bass will uniquely identify where the performer is within the line. The piece is thus constantly sending signals about where the performer is in within this short line. The larger form of the piece is completely different, consisting of 360 repetitions of this bass line organized into 840 larger repetitions played over 12 to 24 hours. Maddeningly, these interval-based signals constantly give localized information about the position in the line but give absolutely no information about where we are in the overall form of the work.
In thinking about the future, I find it’s always helpful to reconsider the past. What were the roles of publishing in the age of print and print only? Why was it important to have ideas published? Only publishers could get an idea out to a large audience that would want to read it. Publishers had distribution networks that could take it from a single location (the city that we still cite in footnotes) and make it available throughout the world. The publishers took on financial risk in printing and distributing material: if they did not print ideas that were worth reading, scholars and librarians would stop subscribing to journals or purchasing books, leaving them unsold inventory in the present and less influence in the future. The publishers’ sense of the market would give an idea of how much interest there would be in the idea while peer review would ensure the quality of that idea. Initially, the reputation of a journal or publisher would determine how many people purchased and read it. Later, public review would help individuals and libraries decide which material to pick up after the initial sales.
Errata: 2015-11-20: The original version of this post mistakenly identified the third committee sponsoring the session. It is the Committee on Publications. It also referred to a slide of parallel perfect consonances in Bach chorales that was not included. The text has been adjusted.
MIT Spectrum has an article by Kathryn M. O'Neill on my work, music21, and computational musicology:
“IF I WANT TO KNOW how the guitar and saxophone became the important instruments throughout classical repertory or how chord progressions have changed, those are questions musicology has been unable to approach,” says Associate Professor of Music Michael Cuthbert. Spotting trends and patterns in a large corpus of music is nearly impossible using traditional methods of study, because it requires the slow process of examining pieces one by one. What his field needed, Cuthbert determined, was a way to “listen faster.”Read more at http://spectrum.mit.edu/articles/data-in-a-major-key/.
pip install --upgrade music21
Or download from GitHub.
The first non-beta release of music21 since v. 1.9.3 (June 2014) gives a ton of new features and lots of new speed. But being a major release change number, it also has some changes that every programmer using the system needs to be aware of. The release notes on GitHub gives all the details, but here are the highlights since 1.9:
Changed and Added features
* Duration and Offset now use Fractions when necessary for exact representation of tuplets. Many, many errors from rounding are gone. For now, you can use Duration.quarterLengthFloat and offsetFloat to get the old behavior, but float(Duration.quarterLength) and float(offset) are better.
* Converters support easy to install custom sub converters. MEI is now supported (thanks to McGill university)
* Python 2.6 is not supported. Python 3.4 is highly recommended; 2.7, 3.3, and 3.5 also work.
* Loading cached streams is extremely fast. All streams are automatically cached when loaded from disk.
* Sorting is much more consistent and faster
* MusicXML parsing and showing have been rewritten to use cElementTree and many new features.
* Stream's internal mechanisms have been hugely rearranged. Now offsets are stored inside Streams instead of inside Notes, etc., making lots of things faster and more reliable.
* Streams support filters on iteration using the `.iter` property and the `recurse()` method. These are big changes for speed and reliability.
* Namedtuples replace anonymous tuples in many places
* Music21 is available under the BSD license.
* Musedata files are no longer available in the corpus. However, new files in MusicXML format have replaced several of them.
* Complete rewrite of TinyNotation making it much easier to subclass for your needs.
* If you have MuseScore 2, try sc.show('musicxml.png') to get a beautifully rendered musicxml file. Or use .pdf to get something ready to print. Thanks Nicholas, Thomas, and Walter!
* Builds are automatically tested for errors and documentation coverage.
* Experimental modules moved to the `alpha` sub package. `demos` reorganized.
* Lots of documentation changes!
* Obscure and almost never used (or actually never used) methods and attributes have been removed.
* Did I mention how much better the documentation is getting?
In case anyone is keeping track, since v.1.0 (June 2012), here are the:
Biggest changes between 1.0 and 1.9
* Store complete Streams via FreezeThaw
* Output to Vexflow and `music21j`
* Converters have been moved into packages.
* It takes 1/3 the time to do most operations, and 1/4 the time to start up.
* Capella supported. ABC imports almost everything. Humdrum supports multiple voices. Chords have a better root() algorithm
* Many, many new corpus pieces.
* Layout support.
* Python 3 supported, and now recommended.
* Timespans make .getContextByClass at least an order of magnitude faster, letting music21 handle huge scores.
* Derivations reduce the number of Streams to keep track of.
Oh, and I did more than patch bugs in the last week:
Release notes since 2.0.11
* Streams use .iter and .recurse() in TONS of functions, making many a lot faster, a few a bit slower, but all cleaner to debug and safer.
* Deprecated items now return a deprecation warning.
* Duration objects now have a `.client` which can inform the `Note` of changes to it.
* `.classes` searches are way faster. Returns tuple.
* `deepcopy` is about 30% faster.
* `common` is split into a directory of related functions. Now worth looking through.
* all corpus files, including small .abc files with non-standard additions, now parse. A complete corpus.search().parse() should be possible without any try: statements.
* several bugs in musicxml processing (mainly related to the handling of expressions, noteheads, etc., on chords) have been fixed. Also Finale's `
* code is much more "lint-free" catching many subtle bugs.
* audioSearch is cleaned up, with beta-type code moved to demos.
* Documentation much improved including three new User's Guide sections, and (thanks to bagratte) fixes for UTF-8 errors.
* `io.open` replaces `codecs.open` for better non-Western script handling.
* .egg files are no longer distributed. I'll work on getting .whl (wheel) files soon, but for now use .tar.gz. PyPi no longer supports .egg, so there's no reason for them.
* `.fullyQualifiedClasses` is GONE. No one used it. Instead a new `.classSet` replaces it for rapid class searching.
* sites.Sites and sites.SiteRef are no longer imported into base by default.
* `documentation` modules reorganized, with better examples.
* `stream.core` moves several core modules out of the `stream` module.
* `Volume.parent` renamed `Volume.client` to match `Derivation` and `Duration`
* `.components` on `Duration` now returns a tuple.
What's Next?Today also announces the first commit of music21 3.0 -- for the first time, I'm going to try to do something daring: keep bug fixes and some backwards compatible changes in the 2.1 (2.2, etc.) branch, but go forward with bigger changes in a 3.0-alpha branch. Some things that you might expect to happen:
* All deprecated functions will be gone in 3.0; like immediately; like I'm deleting them as I type.
* Lots of things that currently return a Stream will instead be iterators over Streams. These include: .getElementsByClass(), getElementsByOffset() -- the fact that so many streams get created is one of the biggest headaches and reasons why the system gets slow. You can prepare for the change by examining your usage of these functions and asking yourself, "Am I actually using this as a Stream? Or just as a bunch of objects to iterate over in a for loop or to count using len()"? If the latter, you're fine. If the former, go ahead and add .stream() after it, for instance filteredStream = s.getElementsByClass("TimeSignature").stream(). The last `.stream()` call does NOTHING right now, but it will ensure that your code works exactly the same after the change happens. If you want to use the new features (even in 2.1) add .iter between `s` and `.getElementsByClass()` (but leave off the `.stream()`. You'll find that life will be going a lot lot lot faster.
* I'm going to make a second attempt to use TimeSpans as a general storage engine for Streams. These are the super fast representations of Streams that Josiah Oberholtzer made, that speed up working with large streams by 10-100x. But for very small streams (such as one measure of a Chorale), they are much slower than the current Streams. Now that all the core mechanisms are factored out of Stream into StreamCore, I can play much more easily with switching in any out the backend functions. Using the lessons of Python's TimSort, I'll probably have the TimeSpan core kick in immediately when there are more than 64 elements in a Stream; it should be seamless except for a tiny delay when the 65th element is added (like shifting gears in a car).
* I may make Python 3.4 a requirement. We'll see... I'm sick of coding for Python 2. Python 3 is much more fun from the coder's perspective.
Thanks everyone for great support! -- Myke
Cuthbert received his A.B. summa cum laude, A.M. and Ph.D. degrees from Harvard University. He spent 2004-05 at the American Academy as a Rome Prize winner in Medieval Studies, 2009-10 as Fellow at Harvard's Villa I Tatti Center for Italian Renaissance Studies in Florence, and in 2012–13 was a Fellow at the Radcliffe Institute in 2012-13. Prior to coming to MIT, Cuthbert was Visiting Assistant Professor on the faculties of Smith and Mount Holyoke Colleges. His teaching includes early music, music since 1900, computational musicology, and music theory.
Cuthbert has worked extensively on computer-aided musical analysis, fourteenth-century music, and the music of the past forty years. He is creator and principal investigator of the music21 project. He has lectured and published on fragments and palimpsests of the late Middle Ages, set analysis of Sub-Saharan African Rhythm, Minimalism, and the music of John Zorn.
Cuthbert is writing a book on Italian sacred music from the arrival of the Black Death to the end of the Great Schism.
Download what is almost certainly an out-of-date C.V. here (last modified June 2012)
Bologna Q15: the making and remaking of a musical manuscript, review for Notes 66.3 (March), pp. 656-60.
"Palimpsests, Sketches, and Extracts: The Organization and Compositions of Seville 5-2-25," L’Ars Nova Italiana del Trecento 7, pp. 57–78.
Der Mensural Codex St. Emmeram: Faksimile der Handschift Clm 14274 der Bayerischen Staatsbibliothek München, review for Notes 65.4 (June), pp. 252–4.
"Generalized Set Analysis and Sub-Saharan African Rhythm? Evaluating and Expanding the Theories of Willie Anku," Journal of New Music Research (formerly Interface) 35.3, pp. 211–19. [.pdf]
Unless otherwise mentioned, the writings, compositions and recordings on this site are licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.
Copyright 2010-11, Michael Scott Cuthbert. Web design by M.S.C.
Fonts for musicology: Ciconia (14th/15th c.) and ClarFinger (clarinet music).
In my copious spare time as a junior faculty member on tenure track, I do web design and programming consulting for the National Bureau of Economic Research.
Lectures on the web
enChanting: Musical Artifacts in Unlikely Places, lecture March 3, 2009
Ambiguity, Process, and Information Content in Minimal Music, podcast of a lecture to Comparative Media Studies at M.I.T.
Just for fun...
Mondrian meets Finding Aids in a map of books in my former apartment.
Numeric Deathmatch, a game I coded that was taught to me by Jon Wild. More fun in person, but the web interface encourages trashtalking.
Musicology Buzzword Bingo, useful for AMS meetings (requires Bach and Futura fonts)
Automatic New Musicology Paper Generator based on the Dada engine