pubPhotos
LATEST NEWS from my Prolatio and music21 blogs:
[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:
[January 3, 2018 12:35 pm] « » [music21]
The second alpha release of music21 version 5 (Python 3.4+ only) has been released.  There have been 47 new commits since alpha 1 (more on that below) mostly of a maintenance sort.  V5 is still pre-release code, and the syntax is still in flux until the main release next summer, but it is well-tested and good for most hobbyist coding.

Here are the main changes since alpha 1:
  • Better parallel processing system (esp. in terms of docs)
  • Pitches are 30% faster to create, notes are 15% faster.  You do create notes, don't you? :-)
  • Better musicxml support: volume.  Improvements to transposition, glissando, barlines
  • Corpus: added works by Amy Beach, Schubert (Lindenbaum), fixed missing Bach Chorales (thanks Dr. Schmidt!) and error in Haydn op. 1 no. 1 movement 1(thanks Joshua Ballance)
  • Scales, IntervalNetwork: faster and better documented.
  • NeoRiemannian analysis greatly improved (thanks Mark Gotham!)
  • 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.
  • Instrument objects now have their MusicXML v.3 sound tags attached (thanks Luke P.!)
  • 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.

I neglected to post on this forum the announcement of music21 v.5 alpha 1, so the many great improvements there are listed below, with a new installation link:

--
Alpha 1 of v.5 of music21 includes an amazingly faster improved version of Chordify (thanks in large part to work by Josiah Wolf Oberholtzer)
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.
This is alpha code -- I am still formulating the changes for m21 version 5. Some things that have disappeared since v.4 may reappear, but some things that are currently here may be gone or significantly changed by v5 release. YMMV.
Other big 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.
  • Many routines that used to return string filepaths now return pathlib.Path objects.
  • Almost all deprecated functions are removed.
  • Many keyword functions are now keyword only, so no worries about passing in "inPlace" accidentally.
  • parsing of Volpiano (Gregorian chant notation) added.
  • RehearsalMark is added (and in musicxml also).
  • 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.
  • analysis.transposition -- searches pitch lists for number of distinct transpositions (thanks Mark Gotham)
  • 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.
The remarkable work over less than a month has been largely aided by dropping the Python 2 code dependencies, so while upgrading to Python 3.6 might cause some grumbling, my ability to forge ahead quickly I hope will more than make up for it!
This is alpha code. It won't install by default on pip. Use
pip3 install --upgrade music21==5.0.5a2
[December 9, 2017 16:46 pm] « » [prolatio]
In my article “Difference, Disability, and Composition in the Late Middle Ages: Of Antonio ‘Zachara’ da Teramo and Francesco ‘Il Cieco’ da Firenze,” chapter 26 in Oxford [University Press] Handbook of Music & Disability Studies, edited by Blake Howe, Stephanie Jensen-Moulton, Neil Lerner, and Joseph Straus, pp. 517­–28, there is a discussion of Petrus frater dictus Palma ociosaand how his "deformed hand" (Palma ociosa) may have impacted his perception as a singer and a teacher in light of the importance of the (Guidonian) Hand in instructing singing.  In the context of a paragraph of original research, cited articles, and common knowledge not requiring a footnote, this discussion is none of the above.  I should have cited Christopher Page, The 'Summa musice': a Thirteenth-Century Manual for Singers (Cambridge: CUP, 1991), which as Daniel Leech-Wilkinson's Grove article notes, is the place where this theory is discussed (pp. 72, 158, and lines 692-96).  I regret the omission and ask Page's forgiveness for the oversight.

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.