pubPhotos
LATEST NEWS from my Prolatio and music21 blogs:
[June 8, 2019 21:41 pm] « » [music21]
Music21 v5.7 is the fourth and final release in the v5 series. It brings under the hood fixes -- lots of bug fixes and speed ups and some new features -- from 126 commits since last October.
Download by running from command line:
pip install --upgrade music21
This is the last release of the v5 series so that work on v6 which may bring some backwards incompatible changes -- all deprecated features will be removed, as will support for Python 3.5 (by the time v6 is released, Py3.8 will be out and this keeps w/ music21 policy of supporting the last three Python releases). The release of v5.7 also marks the End-of-Life for music21 v4 (the last release to support Python 2.7); if someone wants to continue supporting v4/Python 2.7 in music21, please let me know, but I'm so happy with how quickly almost all of us have moved to Python 3. Looking forward to major tablature improvements, SMuFL support, and much faster development thanks to "f-strings" in v6.
The music21 user community continues to be active and robust as attested by the number of contributed features below. Thanks for keeping me sustained during my non-music Admin time! Among the most notable improvements are (in reverse chronological order):
  • Type hints on major objects and functions in the library and the promise of more (once Py3.5 is dropped) soon. Those who use fancy IDEs like PyCharm will reap major bug checks!
  • The most extensive typo-checking / spell-checking / linting ever done to music21 -- the code now has that new car smell.
  • Stream.measures(4, "5a") -- measure suffixes work in many more places in the code.
  • Pizzicato notes export properly in MusicXML
  • Chorale metadata improved (thanks to @doctor-schmidt!)
  • Improvements to MEI accidental handling (kudos @raffazizzi)
  • KeySignatures work better in multi-voice contexts (thanks @pconerly)
  • Bugs that made .getContextByClass() sometimes inconsistent (especially with forward searches) fixed.
  • Harmony objects (ChordSymbols, etc.) sort before Notes so that the harmony of a note at the offset can be found easier. And proper musicxml offset support (thanks @a-papadopoulos)
  • Chord.notes gives direct access to the underlying Note objects that make up a Chord. Chords also get a good __eq__ test.
  • MuseScore 3 support (thanks @YoWenqin)
  • Accidental fixes for ABC (thanks @dvdrndlph)
  • Added Neo-Riemannian analysis features (thanks @MarkGotham) and triads can now know which hexatonic system they belong to.
  • Fixes to MusicXML chord input.
  • Barlines now use "type=double" instead of "style=double", since in v6 they will get full style.Stylebehavior.
  • User's Guide gets the long awaited Chapter 58 on Sites and Contexts for advanced users.
  • Clefs get a .name property so that the class does not need to be parsed.
  • Grace notes no longer cause obscure bugs in Stream.makeNotation().
  • A bug in Interval.direction for some perfect intervals is fixed (thanks @ryaanahmed and www.artusi.xyzteam for identifying the bug)
As always, I want to acknowledge MIT Music and Theater Arts and the School of Humanities, Arts, and Social Sciences for encouraging the development of music21. Founding contributions to music21 were made by the Seaver Institute and the National Endowment for the Humanities.
[October 29, 2018 11:08 am] « » [music21]
Version 5.5 brings some small but important improvements to music21 and is a maintenance release. V5.5 is the first release to no longer support Python 3.4, so please use Python 3.5 or higher to upgrade.
Important changes and bugfixes.
  1. Chord.commonName gets many improvements, detecting for instance, the differences between dominant-seventh chords and augmented sixths.
  2. much better metadata on Bach Chorals (thanks Norman!)
  3. Stream.voiceToParts() is much improved and gets an optional separateById keyword argument which will only merge voices whose .id matches. -- this is very exciting to me from an analytical perspective and one reason I decided to release now.
  4. Volpiano is upgraded to a full conversion method. Most people will go, "buh??" people who work with Gregorian chant will rejoice.
  5. obj.activeSite is set more reliably.
  6. better error messages if a stream cannot be chordified.
  7. ABC parses all major and minor keys properly -- there were a few bugs especially on sharp keys in minor before. (Thanks @a-papadopoulos )
  8. "Cad64" is now an acceptable RomanNumeral alternative for "I64" for all you theorists out there who cringed when writing it. Resolves to I64 in major context (or as a secondary dominant) and i64 in minor contexts.
  9. bug fixes on rounding approximate durations (such as in MIDI parsing)
  10. converter.parse('tinyNotation: ...', raiseExceptions=True) allows tinyNotation to bubble up anything that prevents reading a token. off by default, but useful for debugging. Expect this keyword to start appearing (w/ default False) for other conversion methods.
  11. Changed: as promised years ago, the default on Stream.recurse() is now NOT to include the caller itself in recursion. Use keyword argument "includeSelf=True" to do so. Recurse keywords are keyword only.
  12. Changed: arguments to Music21Object.contextSites are keyword only. This fixes a few little bugs. Same with Stream.elementsChanged()
  13. MusicXML stores Fingerings properly (thanks @hofst !)
  14. Fixes for extreme pitchbends (very close to wheel minimum) on MIDI.
  15. Dropped bug-fixes for very old versions of Sibelius and MuseScore < 2.0
  16. Added bug catching for MusicXML that gives the shape of the clef ('G', 'F') but no line -- uses sensible defaults. And many other cases in MusicXML where an attribute is empty (as one musicxml writer is now producing)
As always thanks to MIT, the Seaver Institute, and the NEH for funding early development of music21.

Upgrade with “pip install --upgrade music21”
[September 24, 2018 01:39 am] « » [prolatio]
I was rereading Lydia Goehr's The Imaginary Museum of Musical Works the other evening after a long day spent translating several of music21's score-representation code from Python to JavaScript (for music21j).  What struck me when I was reading the introduction, which lays out several pre-existing theories about the work-concept, and the relationship(s) among the musical idea, the building blocks of scores (pitches, etc.), the score-copy, and performances, was my own need to take a stand on the proper relationships of such conceptions when choosing a computational language in which to express musical languages. 

Those who haven't programmed may not know that no modern computer program (or very very few) is built from a single code file, or flowchart leading from input to output.  Instead each program is built from components (a file browser, a set of functions for manipulating canvases for drawing, a module for representing tempo) that can be called upon by other components in a systematized but reusable and testable manner.  These are get bundled or packed or linked together to make a complete or extensible application or library.  Different philosophies exist about which structures (or ontologies, to use a word with related but quite different meanings between the humanities and computer science) can be well-formed or desirable. 

These philosophies about file linking--importing and exporting--lie close to the marrow of the designs of various computer languages and in many cases evolved in response to the environments within which the languages were originally created.  Python, a language run on individual computers that came of age in the era of fast hard drives and, from the user's perspective, near instantaneous loading of small files, aims to put as few limitations on the possible relationships between modules as possible.  JavaScript, on the other hand, which appeared first on the web in the time of dialup internet and unreliable connections, has, even in its most recent incarnations, placed sharper restrictions on connecting resources in the name of efficiency.

Translating music analysis software from the first language to the other has raised complex problems for the representation of music in code.  Python allowed me to interweave different levels of musical thought, such that notes could will into existence a measure (say by asking for the creation of an object to encompass them) while a measure could in another context give birth to notes (for instance by asking for a suitable number to fill it, given some metrical, harmonic, and accentual constraints).  A score could of course be a container to many measures, but a measure could also be linked or contain many scores (for instance as a key or heading to a catalogue of quotations or standard topoi).  As I created the original music21 in Python, I revealed in the multiplicity of possible relationships, in the way some musical philosophers might argue that a score gives rise to a performance which, if transcribed or imagined, gives rise to a new score, which gives rise to a new performance, and so on to infinity.

Rewriting the "same code" posed, and continues to pose, a challenge to my ecumenical notion of musical relationships. (With "same code" in quotation marks since the work-concept-concept for computer works has not been the subject of nearly so much rumination.) In JavaScript, in order to make sure that everything has been loaded before the user closes her browser in frustration, in general if one module (A) uses another module (B) in its code, then the second module (B) cannot use, or import, the first (A) into its code. What some, perhaps those trained as humanists, might exult as a beautiful web of inter-compu-textuality, is called a cyclic or circular dependency and it is easy to find categorial pronouncements that such things are bad or the result of lazy or sloppy thinking.  They resist creating a hierarchy of elements, and prevent creating beautiful tree structures that are, or at least were during the time when computers were problem-solving devices and not enablers of exploration, the key to moving in an efficient manner for point A to point Z without getting into an endless loop somewhere around J to M.  (A programmer--who had apparently gotten too deep into the trenches of coding to remember that the terms which undergird so many computational structures are metaphors--once criticized a part of my code that had many pointers running up and down a hierarchy by saying, "This is absurd! A child cannot have more than one parent.")

In Python, I could say that a Note in the presence of another Note created an Interval. (Like in German, in most computer languages, nouns, or Objects, are capitalized.)  And, I could simultaneously say that an Interval, given a starting Note for reference, could define a second Note that fulfilled it.  Both of these generating relationships seemed not just plausible, but natural and essential to a full representation of the complexity of music.  The ambiguity of which came first, the interval or the note can never be resolved.  In JavaScript, however, the programming musicologist is left with a decision to be made: either Notes can create Intervals or Intervals can create Notes, but not both.  The work creates the score (or performance), or the performance or the score creates the work, but not both.  The one who is able to create both Notes and Intervals is an entity that stands outside the system--the calling program--which is perhaps better named "the observer" in the best literary criticism traditions, since the network of Notes and Intervals cannot operate with knowledge that it exists.

(To be fair, there are some complex and fragile ways to work with circular dependencies in JavaScript, and in Python, true circular dependencies are also impossible: either the Note can only become aware of its ability to create Intervals at the moment of action [an import nested in a method] or vice-versa.)

I have found that programming musical logic has sharpened my awareness of the ambiguities, hierarchies, and underdefined elements of music. By underdefined elements, I suggest: is the interval from E# to Fb an ascending doubly-diminished second or a descending doubly-diminished second? If spelling matters more than sound, such that C-G is consonant but Dbb-G is dissonant, is the bass of a chord beginning on E##-Fbb-Bb the E## or the Fbb? (If it's the Fbb, then is a B###-Dbbb-F# chord in root position or first inversion? If the E##, does that mean that we cannot determine the bass of a chord by ear?)  These may be absurdities to practicing musicians but deciding a "right answer" to them makes all the difference in how standard musical relationships should be represented and encoded.

It is extremely difficult to tell a computer to hold off on making a decision or to leave a paradox in place to solve later.  The human ability (flaw?) in being able to reason around ambiguity, or to hold conflicting ideas without breaking down, is a capacity that those who design practical computing systems have either not been able to replicate or have deliberately chosen not to.  Within the limited choices, I have generally been drawn to computing frameworks that let me come as close as possible to representing multiple perspectives. (Ironically, I've found the closest match so far in Python, despite its community adopting a motto that says there should be only one way to do it.)  There is a danger that when good but still inadequate tools are used to model human behavior and creativity, eventually human behavior will bend to suit the tools, rather than the other way around.  It is a force that those who design and use these tools must be aware of and continually fight against.
[August 12, 2018 19:03 pm] « » [music21]
[March 17, 2018 17:11 pm] « » [music21]
music21 v.5 is PYTHON 3 ONLY
Do not upgrade to this version if you are using Python 2.7 (or better still, upgrade yourself to Python 3.6 instead). It runs on Python 3.4-3.6 only.  music21 v.4 is the last version to support Python 2.
run "pip3 install music21" to install.
music21 v.5 brings with it seven months of determined work by an open-source team to streamline music analysis. The move to Python 3 allowed us to greatly simplify the codebase and to speed up many commonly used features in music21. If you are apprehensive about switching to Python 3, I hope you'll be convinced that it is worth it the first time you run chordify() on a large score v.5. and see that what might have taken an hour can now be done in few seconds. A great number of bugs involving working with non-English text have been fixed.
As a new major release, music21 breaks backwards compatibility where necessary and deprecates underused functions and things that can be done better in other ways. We're always trying to balance bringing new features with keeping the software as simple to use as possible.
Major changes:
  • Python 3 only. Yes, I said that but I'm saying it again. This change has made developing much faster and a lot more fun. Also it's made music21 more powerful and faster.
  • Chordify moves from O(n^2) to O(n) time -- Chordify on large scores works great now.
  • MusicXML roundtrip now preserves much about appearance, style, metadata, etc. -- you can now load a musicxml file into music21 and back into your software and 90% of the time you'll get visually the same result as the original software. Finale roundtrip is especially good!
  • Corpora searching is much better and much faster. Metadata is stored in pickle format.
  • Feature Extraction runs multicore by default. Together with the average of 10x faster chordify, feature extraction on large datasets on multicore systems is now very strong. Parallel processing is easier and much better documented.
  • Features with JSymbolic equivalents much more closely match the spec and new features have been added (thanks Micah Walter!)
  • Many routines that used to return string filepaths now return pathlib.Path objects. Especially useful for people running on Python 3.6
  • Almost all functions deprecated in v. 4 have been removed.
  • Many keyword functions now require the keyword, so instead of makeNotation(True), call makeNotation(inPlace=True), since explicit is better than implicit, this is a good way of being sure that only the right arguments are being changed.
  • parsing of Volpiano (Gregorian chant notation) added.
  • RehearsalMarks are now supported internally and in MusicXML reading/writing.
  • Other musicXML improvements: Volume of individual notes is now imported and exported. Glissandi and barlines and transposition work better. More elements can be hidden. Empty spaces in MusicXML measures are converted to hidden rests, to avoid gapped streams. Pitches in chords on musicxml import are always sorted from lowest to highest. Fretboard diagrams are supported and Instrument objects have the MusicXML v. 3 sound tags attached. (thanks to Luke Poeppel for these last two)
  • Corpora improvments: works by Amy Beach, Schubert (Lindebaum), better Bach Chorales (thanks Dr. Norman Schmidt), and Scott Joplin. Errors in various pieces fixed.
  • Scales and IntervalNetworks run much faster and are better documented.
  • voiceLeading.VoiceLeadingQuartet improved. compatibility change: improperResolution renamed to isProperResolution and improved. Former title implied that False meant it was proper; now the title reflects the output. Many other fixes and improvements thanks to Ryaan Ahmed.
  • analysis.transposition -- searches pitch lists for number of distinct transpositions; neoriemannian analysis improvements (thanks to Mark Gotham for both) Stream alignment tools in alpha.analysis (thanks to Emily Zhang)
  • Copyright and other metadata is preserved in many formats on import. This is just being a good neighbor.
  • Demos and most alpha code has been moved to a new separate repository: https://github.com/cuthbertLab/music21-demos -- they will be updated much less frequently. This will also make code development faster. Thanks to all who have contributed to music21's development. We'll be able to get more demos into the codebase by not needing to update them at every moment.
  • Bugs fixed: chords not in voices in measures with voices were not found in some routines. Instrument objects without midiProgram explicitly set get a program on MIDI output. MIDI no longer inserts a rest at the beginning (thanks KKONZ). Chord.normalOrder fixed (thanks luiselroquero), bugs in Capella parsing. Bugs related to Apple File System High Sierra not sorting files by default. Accented braille characters are exported properly.
  • Docs can be downloaded as a separate zip file.
I have no major backward-incompatable plans for the near future, so I expect v.5 to have a longer life than the last few releases (at least 18 months, and possibly 2-3 years), but work will continue on smaller subreleases to come. Thanks again to MIT, School of Humanities, Arts, and Social Sciences, and the Music and Theater Arts section for their support of music21 and the Seaver Institute and the National Endowment for the Humanities for financial support.
[March 10, 2018 17:02 pm] « » [music21]
The first and hopefully only beta/release candidate of music21 v. 5 has been released.    If no bugs are discovered/reported, I expect this to be the release version to be released next weekend and I’m going to hold off on merging any new pull requests until then.   I expect v.5 of music21 to have a longer than usual lifespan (at least 18 months, possibly more) and don’t have any backwards incompatible changes planned for the future except in the alpha and tree directories.  

Music21 v.5 is the first version to require Python 3 (3.4 required.  3.5 or 3.6 recommended as this will be the last version to support 3.4).

Changes since Alpha 2:
  • braille -- accented characters translate to braille
  • features -- many jSymbolic Feature Extractors match the spec more closely (thanks to Micah W. for the patches). Expect more of these improvements throughout the v.5 lifecycle.
  • Bach chorales -- improvements to naming and texts. Expect more of these improvements throughout v.5. Thank you to Dr. Norman Schmidt for these.
  • Improvements and fixes in voiceleading.py -- thanks to Ryaan Ahmed
  • More objects can be hidden with "hideObjectOnPrint"
  • Joplin, Maple Leaf Rag added to corpus
  • Guitar and other fretboards supported. Thanks to Luke Poeppel
  • Improvements to IPython/music21j MIDI
  • Added stream alignment tools in alpha.analysis. Thanks to Emily Zhang
  • docs for Stream.insertAndShift improved greatly.
  • separate zip file for docs.


Download at:

For older stories visit the Prolatio (general items) or music21 (computational musicology) blogs.

Michael Scott Cuthbert (cuthbert [at] mit.edu) is Associate Professor of Music and Homer A. Burnell Career Development Professor at M.I.T.

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)

2010
Changing Musical Time in the Renaissance (and Today), for Festschrift Joseph Connors (forthcoming)

Bologna Q15: the making and remaking of a musical manuscript, review for Notes 66.3 (March), pp. 656-60.

2009
Ars Nova: French and Italian Music in the Fourteenth Century, edited volume with John L. Nádas (Music in the Medieval World Reference Series vol. 6). London: Ashgate. Reviewed by Gary Towne, The Medieval Review, February 2010.

"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.

2008
"A New Trecento Source of a French Ballade (Je voy mon cuer)," in Golden Muse: The Loeb Music Library at 50. Harvard Library Bulletin, new series 18, pp. 77–81.

2007
"Esperance and the French Song in Foreign Sources," Studi Musicali 36.1, pp. 1–19.

2006
"Trecento Fragments and Polyphony Beyond the Codex", Ph.D. Dissertation, Harvard University (unpublished).

"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]

2005
"Zacara’s D’amor Languire and Strategies for Borrowing in the Early Fifteenth-Century Italian Mass," in Antonio Zacara da Teramo e il suo tempo, edited by Francesco Zimei. Lucca: LIM, pp. 337–57 and plates 10–13.

2001
"Free Improvisation: John Zorn and the Construction of Jewish Identity through Music," in Studies in Jewish Musical Traditions, edited by Kay Kaufman Shelemay (Cambridge, Mass.: Harvard College Library). pp. 1-31. [.pdf]

Creative Commons License 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.