v.2.0.11 (beta)

Ten days since the last release, so time for a new one. Again, speed, stability, and new features. The biggest change is the entirely new MusicXML output system to match the entirely new input system introduced last release.

The second biggest is in the (re)introduction of StreamIterators and RecursiveIterator. I'll need to get some demos up of this soon, but this will be a game changer for some tasks.

Bigger changes

1. MusicXML now uses the faster, more reliable ElementTree output generator. Please report any bugs on import or export, especially if they are regressions from format='oldmusicxml'. oldmusicxml will disappear soon.
2. Better docs (see below), especially for the long under documented recurse function. Everything that was in overview is now in the User's Guide.
3. Streams now support filters on iteration -- if you have been using: for e in s.getElementsByClass('X'), try: for e in s.iter.getElementsByClass('X') for a major speedup, especially if you just want the first one or something of that sort. Recurse() supports the same, so for e in s.recurse().notes.getElementsByGroup('tuba') will be WAY faster than before. You might not notice the difference on your own work, but internally things are getting a lot faster. (obscure non-filter routines will be deprecated and disappear soon).
4. Corpus docs/indexes, etc. are updated with more recent corpus changes (nothing new, but easier to find).
5. Use of deprecated functions now generates a warning. This should help people plan for migration in case you're not reading the documentation religiously.

Smaller changes

1. Documentation is improved and updated working with Jupyter/IPython 4 (note: a bug in nbconvert + pandoc requires pandoc v. 1.33 or older to make; they're working on a patch). Docs build in parallel, so it's very fast -- you'll see updates more often.
2. Documentation is now separated into "source/" and "autogenerated/" folders -- everything in source is user editable. Nothing in autogenerated is.
3. A number of obscure, long deprecated functions are gone, the biggest being n.removeLocationBySite() use n.sites.remove()
4. normalization in features has been fixed (Thanks Frank Zalkow)
5. Parsing of cappella MusicXML files has been improved.
6. Improved parsing of RomanText files; bugs in several encodings of rntxt and abc files have been fixed.
7. common.nearestCommonFraction has been renamed addFloatPrecision to better reflect what it does. This has always confused me.

Music21 v. 2.0.10 (Beta)

It's been a busy week in music21's world.

This post announces the v.2.0.10 beta release of music21, which is moving quickly to the official v.2 release, v.2.1. Some of the changes have already been announced on the music21list Google Groups mailing list. The major changes include:

• New parsing engine for MusicXML (see below)
• DurationTuples replace DurationUnits
• Percussion clefs and No Clefs now are supported properly in musicxml output
• Improvements to the RomanText and clercqTemperly formats (thanks DT!)
• Some obscure modules removed from the main namespace:
  ** intervalNetwork becomes scale.intervalNetwork and BoundIntervalNetwork becomes simply IntervalNetwork.
  ** scala becomes scale.scala
  ** chord becomes a package and chordTables becomes chord.tables
  ** In the next version, expect languageExcerpts to become text.languageDetection and the "xmlnode" module to disappear.
  ** Environment and CapellaXML, which depended on XMLNode now don't. CapellaXML processing is 10x faster.
  ** jsonpickling is upgraded and safer.
  ** Building documentation now works on IPython 4/Jupyter 4.0
  ** MusicXML output with Unicode now works on Py3 (thanks Sarig!)
  ** Spanners on Rests now export properly in MusicXML
  ** VexFlow only supports the music21j based output now. More bug fixes there to come (or will be moved to alpha support). The older version wasn't working with recent VexFlow.
  ** Everything overall is about 30% faster than a month ago.

The biggest change in this version is how MusicXML is processed. When Christopher Ariza joined the music21 team in 2008, music21 had a tiny limitation: it didn't work with MusicXML, at all. Whoops! It was just too big a task to tackle for me when I was still figuring out how Streams, Sites, Durations, etc. would work. Thankfully Chris took it on and extremely quickly produced a great parser for MusicXML. The problem back then was that few people were on the latest, greatest version of Python 2.5, and music21 aimed to support at least back to Python 2.1, and only the newest Python 2.5 had the brand new "ElementTree" Python processing module (and there were still substantial bugs in that module before Python 2.6). We were determined not to make MusicXML parsing require an external library such as "lxml", so that left two choices, xml.minidom and xml.sax.

Anyone who knows anything about the structure of MusicXML and the differences in philosophy between DOM and SAX will know that DOM is the logical choice for MusicXML parsing -- it allows nodes to look at their neighbors, parents, children, and make logical decisions (am I a note, rest, or chord?) based on the context. SAX on the other hand is built on calling functions whenever a particular tag start is encountered, whenever data is encountered, and whenever a stop tag is encountered. Great for certain types of text formatting, insanely difficult for a format like MusicXML (or MEI or just about any music format besides perhaps MIDI). So, if memory serves, Chris wrote a quick DOM processor for MusicXML and it was getting notes, durations, measures, beautifully.

But Chris Ariza is also probably the best programmer I've ever met and before going further he profiled the system and extrapolated what it would be like to work with a large corpus of MusicXML files using it. Slow as slime. The minidom was implemented entirely in Python, not highly optimized, and was not going to make anyone want to use MusicXML in the toolkit.

So, he basically did the impossible: implemented a blazingly fast SAX processor for MusicXML that built a close-to-the-original representation of the file (musicxml.mxObjects) and then processed that in a much more friendly format. Bam! Speed went up by an order of magnitude, and everything that music21 could do with MusicXML was born. In the dozens of releases since he moved on from the project, I've barely had to touch the internals at all even as the rest of the system has expanded and changed dramatically. And there was a system for caching the mxObjects representation for a speedup in the next parse.

Fast forward 7 years. Python has changed. Version 2.7 is now the minimum requirement (it's over five years old already; we just found a check for Python > 2.2 somewhere in the system! removed it) V.3.3 and 3.4 are supported (3.5 should be out this week and of course will be supported). And everyone has access to xml.etree.ElementTree now. And the final representation of all parsed formats is now cached, so there is no need for the mxObjects cache. So in the interest of simplifying parsing (and getting a 40% speedup over SAX + mxObjects), it made sense to rewrite the MusicXML parsing engine.

The new version is called musicxml.xmlToM21. There are a few miscellaneous files in a new musicxml.xmlObjects file, but basically all the parsing takes place in the xmlToM21 file. Every tag in musicxml is now written directly into the file to make it easier to see exactly which tag is causing any particular problem. (Line number properties may be possible to add soon). Because the format of the parser is now much closer to the format of the MusicXML document, a TODO: has been added for every missing tag, or attribute. Expect music21 to support every tag and attribute in MusicXML 3.0 sometime soon. If you've ever wanted to hack additional support into Music21's MusicXML parsing but it seemed too daunting, give another look at the code now.

This is a major change on the most used format for music21. Thankfully, Ariza wrote so many tests into the system that I am relatively confident that everything now works exactly like before. The exceptions are: non-printed notes are no longer skipped (this was to prevent the next bug), notes with incorrect divisions are now corrected rather than skipped, and spanners preceding rests are now attached to the rest rather than the next adjacent note. (My intention was to be 100% compatible with before, but it would've been very hard to replicate this incorrect behavior). The one negative side-effect you will see is that parsing some of the Beethoven files is now slower (rather than 40% faster) because some of those files used a large number of incorrectly notated, non-printing notes to represent playback of trills. For certain files (such as the Große Fuge) the number of notes in the score will almost double with the new system.

Because this change is major, for now you can still use the old parsing system via converter.parse('filename.xml', format='oldmusicxml'). I suggest also adding "forceSource=True" to make sure that you are reading the file from disk and not from Cache.

I'm extremely excited by this change -- we will get the writing of music21 files to use the new system by the next release (a much easier task).

As always, music21 has been supported by the Seaver Institute, the NEH Digging into Data grant, and MIT Music and Theater Arts/SHASS.

Music21 v. 2.0.8 (Beta)

The newest release of the music21 v.2 (beta) developments improves the stability and performance of the system.

The biggest change in this version is the movement of all experimental modules into a new "alpha" sub-package; in the future, all releases that add something useful to music21 but which are not well tested or mostly documented will begin in this folder. They may graduate into the main music21 mainspace at some later point, remain in "alpha", or be removed. Among the modules that are moved include: webapps (system for running music21 as a WSGI service-oriented architecture), trecento (fourteenth-century musical analysis), theoryAnalysis (common-practice error detection), counterpoint/species (first-species counterpoint generator), medren (miscellaneous pre-1600 applications; this will return soon after refactoring), contour (contour analysis), chant (Gregorian chant generation), and analysis.search (find scales inside Streams).

The "demos" directory has also been reorganized. The next release will focus on making this directory easier to use.

Bug fixes and improvements:

• search.lyrics -- modules for searching within lyrics while retaining position information about matches.
• Interval objects have been improved to have additional properties.
• .priority changes will automatically re-sort Streams. This change will make .priority more useful.
• Stream.elementsChanged() is a new method that can trigger a cache clear for Streams.
• Stream.remove() gets a recurse function.
• Lilypond color works again (thanks Ringw)
• Accidental becomes a SlottedObject -- pro: much faster. con: arbitrary attributes cannot be added to Accidentals.
• MuseScore 2 is now discovered automatically in python3 configure.py.
• Tremolo support (including in MusicXML)
• Unlikely bugs in Chord fixed.
• MIDI support for > 16 channels output.
• Fixes for PIL/Pillow support of more versions
• More places taking advantage of exact fractions in music21 offsets and lengths which used to be kludges

Music21 v. 2.0.5 (Beta)

Dear All,

The newest version of the beta 2.0 track of music21 has been released. A reminder that the 2.0 track involves potentially incompatible changes w/ 1.X so upgrade slowly and carefully if you need existing programs to work. Changes are being made to simplify and speed up usage and make the system more expandable for the future.

(the Windows .exe release is marked as 2.0.6 -- it is the same as 2.0.5...really.)

Major Changes

Complete rewrite of TinyNotation. Tinynotation was one of the oldest modules in music21 and it showed — I was still learning Python when I wrote it. It documents a simple way of getting notation into music21 via a lily-like text interface. It was designed to be subclassable to make it work on whatever notation you wanted to use. And technically it was, but it was so difficult to do as to be nearly impossible. Now you’ll find it much simpler to subclass. Demos of subclassing are included in the code (esp. HarmonyNotation, and trecento.notation); a tutorial to come soon.

backwards incompatible changes: (1) you used to be able to specify an initial time signature to Tinynotation as corpus.parse(“tinynotation: c4 d e f”, “4/4”); now you must put the time signature string into the text itself, as corpus.parse(“tinynotation: 4/4 c4 d e f”). “cut” and “c” time signatures are no longer supported; use 2/2 and 4/4 instead. (2) calling tinyNotation.TinyNotationStream() directly doesn’t work any more. Use the corpus.parse interface either with the “tinynotation:” header or format=“tinynotation” instead. If you must use the guts, try tinyNotation.Converter(“4/4 c4 d e f”).parse().stream. (3) TinyNotation used to return its own “TinyNotationStream” class, which was basically incompatible with everything. Now it returns a standard stream.Part() (4) TinyNotation did not put notes into measures, etc. you needed to call .makeMeasures() afterwards. If you need the older method, use corpus.parse(‘tinynotation: 4/4 c2 d’, makeNotation=False)

Musescore works as a PNG/PDF format. First run: us = environment.UserSettings(); us[‘musescoreDirectPNGPath’] = '/Applications/MuseScore 2.app/Contents/MacOS/mscore' or wherever you have it). Then try calling “.show(‘musicxml.png’)” and watch the image arrive about 100x faster than it would in Lilypond. Thanks MuseScore folks! This is now the default format for .show() in iPython notebook. Examples using lily.png and lily.pdf will migrate to this format, so that lilypond can be moved to deprecated-but-not-to-be-removed status. (I just don’t have time to keep up)

demos/gatherAccidentals : a good first test programming assignment for students. I use it a lot in teaching.

musicxml parses clefs mid-measure (thanks fzalkow)

installer.command updated for OS X (thanks Andrew Hankinson) — let me know if this makes a problem.

postTonalTools demo in usersGuide.

DataSet feature extractor gets a .failFast = False option for debugging.

Under the hood / contributors

music21 now uses coverage checking via coveralls.io. We are at 91.5% code coverage; meaning when the test suite is run, 91% of all the lines of code are tested. Aiming for 95% (100% is impossible). Adding coverage checking let me find a lot of places that weren’t being tested that, lo and behold!, had bugs. What it means for contributors: any commit that is longer than 20 lines of code needs to improve the coverage percentage and help us get to 95%. So make sure that at least 92% (better 99%) of your code is covered by tests.

the romanText.objects module has been renamed romanText.rtObjects to not conflict with external libraries. It’s an implementation detail.

added qm_converter.py demo of how to subclass SubConverter.

Minor Changes

measure number suffixes in musicxml output, not just input.
language detector can detect Latin and Dutch language texts now.
fix pitch class errors in microtones.
midi files with negative durations no long crash the system.
bugs in tonalCertainty. You can be more certain that it works.
cPickle is used in Python3 now. Faster.
midi parsing can specify quantization levels.
music21.__version__ gives the version (maxalbert did a lot this commit; forgot to shout out before!)
better detection of lilypond binaries.
certain Sibelius MusicXML files with UTF-16BOMs can now be read.
rests imported from MusicXML would not have expressions attached to them — fermatas, etc. fixed
serial.ToneRow() now has the notes each as quarter notes rather than as zero-length notes; it makes .show() possible; backwards incompatible for the small number of people using it.
colored notation now works better and in more places.
better docs.
about a trillion tiny bugs and untested pieces of code identified and fixed by glasperfan (Hugh Z.)

Music21 v. 2.0.0

We're happy to announce that the first public alpha of music21 v.2 has been released!

Version 2 is the first version of music21 since v.1 to make substantial changes in the code base that introduce backwards incompatibilities in order to make going forward faster and smoother. It doesn't change anything super fundamental à la Python 3's print function, so most code should still run fine, but definitely test in a separate environment before upgrading on any code you have that needs to run without problems. The system is still changing and more backward-incompatible changes could be included until v.2.1.

We have had 420 commits since the last release, so there is a lot that is new!

Substantial changes include:

• Offsets and quarterLengths are now stored internally as Fractions if they cannot be exactly represented as floating point numbers. A lot of work went into making this conversion extremely fast; you probably won't ever notice the speed difference, but you can now be sure that seven septuplets will add up to exactly a half note. For instance:

    >>> n = note.Note()
    >>> n.duration.appendTuplet(duration.Tuplet(3,2))
    >>> n.fullName
    'C in octave 4 Quarter Triplet (2/3 QL) Note'
    >>> n.quarterLength
    Fraction(2, 3)
    >>> n.quarterLengthFloat # if you need it...
    0.6666666666666666

• Converter structure has been overhauled for more easily adding new converters in the future. If you've wanted to write a converter or already have one for a format not supported but have been daunted by how to include it in music21 now is a great time to do it. Speaking of which...
• MEI format is supported for import (thanks to Chris Antila and the ELVIS team at McGill university for this great enhancement)
• Python 2.6 is no longer supported. All tests and demos pass and run on Python 2.7, 3.3, and 3.4. (3.2 and older are not supported)
• FreezeThaw on Streams works much better and caching loaded scores works great (some of this was included in 1.9, so definitely upgrade at least to that.
• Much improved Vexflow output using music21j, Javascript/Vexflow rendering engine. Was in 1.9, but improved here.
• Lots of places that used to return anonymous tuples, now return namedtuples for more easily understanding what the return values mean.
• Integrated Travis-CI testing and Coverage tests will keep many more bugs out of music21 in the future.
• Many small problems with Sorting and stream handling fixed.
• Corpus changed: for various licensing reasons, v.2.0 does not include the scores from the MuseData corpus anymore. This change mostly affects Haydn string quartets and Handel's Messiah. However, new replacement scores are being included and 2.1 will have as many great works as before. The MuseData scores are still available online. MuseData is now a deprecated format and no further testing on it will be conducted; only bug fixes that are easily implemented will be accepted.
• music21 is now available under the BSD license in addition to LGPL!

We will try to stick to something close to the semantic versioning model in the future once v.2.1 is released. In other words, after 2.1, we'll try very hard not to break anything that worked in v.2.1 until v. 3.0 is released. This will probably mean that the version numbers are going to creep up faster in the future.

Still todo before v.2.1 is a major change in how elements are stored in Streams. Stay tuned if you care about performance tweaks etc., otherwise ignore it -- we'll keep the interface the same so you might not notice anything except speed improvements.

Smaller backward-incompatible changes include:

• Stream repr now includes a pointer rather than a number if .id is not set. This change will make filtering out doctests easier in the future.
• TinyNotation no longer allows for a two-element tuple where the second element is the time signature. Replace: ("C4 D E", "3/4") with ("tinynotation: 3/4 C4 D E")
• Obscure calls in SpannerBundle have been removed: spannerBundle.getByClassComplete etc.
• Convenience classes: WholeNote, HalfNote, etc. have been removed. Replace with Note(type='whole') etc.
• Old convenience classes for moving from Perl to Python (DefaultHash, defList) have been removed or renamed (defaultlist)
• Articulations are marked as equal if they are of the same class, regardless of other attributes.
• common.almostLessThan, etc. are gone; were only needed for float rounding, and that problem is fixed.
• duration.aggregateTupletRatio is now aggregateTupletMultiplier, which is more correct.
• scala.ScalaStorage renamed scala.ScalaData
• common.nearestMultiplier now returns the signed difference.
• layout -- names changed for consistency (some layout objects had "startMeasure" and some "measureStart" - now they're all the same); now all use namedtuples.
• rarely used functions in Sites, base, Duration, SpannerStorage, VariantStorage, have been removed or renamed. I'd be surprised if these affect anyone outside the development team.

Improvements and bug fixes:

• common.mixedNumeral for working with large rational numbers
• common.opFrac() optionally converts a float, int, or Fraction to a float, int, or Fraction depending on what is necessary to get exact representations. This is a highly optimized function responsible for music21 working with Fractions at about 10x the speed of normal Fraction work.
• Rest objects get a .lineShift attribute for layout.
• staffDetails, printObject MXL had a bug, writing out "True" instead of "yes"
• staffLines is now an int not float. (duh!)
• better checks for reused pointers.
• lots of private methods are now ready for public hacking!
• Lyric.rawText() will return "hel-" instead of "hel" for "hel-lo".

Music21 v1.9.3

We are proud to release music21 v1.9.3, the latest and last release in the 1.x series.

There have been 147 commits in the two months since v1.8; here are some of the highlights:

• MUCH faster .getContextByClass (KUDOS to Josiah Oberholtzer for this). Even if you don't use .getContextByClass in your own code, you're definitely calling something that calls it. This method figures out where the most recent key signature, time signature, clef, etc. is for any given object, finds relationships between notes in different voices, etc. For analysis of medium-sized scores (say, 3 voices, 100 measures) expect a 10-fold speedup. For larger pieces, the speedup can be over 100-fold.
• A new stream/timespans module that makes the previous speedup possible by representing m21 Streams as AVL trees -- it's used in a few places (needs more docs), forthcoming releases will use it in a lot more places
• Python3 support (3.3 and later). The entire test/multiprocessTest.py suite passes on Python 3. N.B. to contributors -- from now on all contributions need to pass tests on both Python 2.7 and 3.3 and later. Negative -- in the past you could have made music21 run on unsupported older systems (2.6 and sometimes 2.5); now from music21 import * will fail on pre-2.7. 2.7 has been a requirement since Music21 1.7. Fewer than 30% of Macs still in use are running Lion or earlier and thus will need to update to 2.7. This version of music21 runs about 25% faster on Python 3 than Python 2, but otherwise no new features of Python3 are used. Python 2.7 will be supported throughout the Music21 2.x cycle so no panicking -- it'll be years (if ever) before Python 3.3+ is a requirement.
• Improvements to reductions of scores. And to analyzing voiceleading motion (some of this is backwards incompatible)
• Better, faster, and more consistent sorting of elements in a Stream
• Changes to the derivations module that I doubt anyone else was using anyhow...
• Removed obsolete files.
• Stafflines import and export from musicxml (thanks Metalmike!)
• Complete refactoring of converter.py to make it easier for users to write their own Subconverter formats (that can eventually be put into the system)
• Complete serialization of Streams via a new version of jsonpickle. This has big implications down the line; for now it affects...
• Vexflow output is much improved (unless you were counting on Voices; in which case do not upgrade) using the alpha version of music21j -- Javascript reimplementation of music21's core features.
• IPython improvements, allowing for robust and persistent communication between Javascript and Python. This will eventually (once I document it...) let you use the web browser as a UI for music21 python apps including live updating of music notation. It's too complex for most users right now, but I can attest that this will be one of the biggest perks of the 2.x development.

The usual bug fixes, documentation improvements and fixes, etc. are implemented. Thanks to MIT, the NEH, and the Seaver Institute for funding the project. (and to MIT for tenuring me in part on the basis of music21). This is the last release that Josiah Oberholtzer was lead programmer for; his considerable talents will still be on display in Abjad and many other projects he works on, and the implications of the new storage system he has developed will continue to pay off for years.

What's next?

Starting work on music21 2.0 today. That release will have some backwards incompatible changes that developers will need to deal with -- just as the path to 1.0 meant that some things that were originally thought of as good ideas were thrown out, the path to 2.0 will rely on 8 years of using music21 to fix some things that really should've been done differently from the beginning. Having just spent 2 weeks making m21 compatible with Python 3, I will give my assurance that as few incompatibilities as possible will be introduced. Most of the major changes will be on the core -- so if you've never messed with Sites, SpannerStorage, etc., you'll be fine.

• Problems with 5 quintuplets = .99999999 of a beat will disappear. Music21 2.X will store offsets and quarterLengths internally as rational numbers (actually a custom MixedNumeral class, so that the repr is nicer...). All music21 objects will gain four properties: ".offsetRational, .duration.quarterLengthRational, .offsetFloat, and .duration.quarterLengthFloat" -- in music21 2.0, .offset and .duration.quarterLength will be aliases for offsetFloat and .duration.quarterLengthFloat -- so no changes will be needed to existing code. This will give a period of time (6 months?) to switch .offset either to .offsetFloat or .offsetRational. We'll have a tool to make the switch automatically. Then at a certain point, .offset will become an alias for .offsetRational. By music21 3.0 .offset will only support Rational numbers.
• Streams will store the position of notes, etc. in them. Right now this is all stored in the Note object itself. There are some great reasons for doing it that way, but significant speedups will take place by shifting this.
• inPlace will be False by default for all operations on Notes, Streams, etc. -- you can plan for the migration by explicitly setting inPlace for every call now.
• Some changes to boundary cases in .getElementsByOffset will take place -- it will not change much, but for a few users this will be crucial.
• NamedTuples and OrderedDicts will appear in a lot of places

that's all for now, but more examples to come soon.

• Myke

Music21 v. 1.8.1.

Corrects a bug in corpus.search that arose with an empty core.json being created (and committed) in the distribution process.

Music21 v. 1.8.0.

A new release of music21 focusing on Speed and Stability improvements.

Biggest improvement: Streams are now cached on disk after a parse. The first parse of a file will take the same amount of time as before (actually 10-15% slower), but after the first parse, subsequent parses will take 1/10th the time as before. This should be a great savings for software that parses the same files more than once (not necessarily in the same session). This speed improvement comes from two related improvements:

1. Memory footprint of music21 is greatly reduced due to the use of Python slots on many frequently created objects that are rarely edited or expanded by users. (Thanks Josiah!)

2. FreezeThaw works well to store or recall the current state of any stream on disk.

Moved from GoogleCode to GitHub (in case you hadn't noticed).

Improvements to Braille processing (Thanks to Mario Lang) and the Vexflow (thanks "Shimpe")

Better handling of local corpora and the Core corpus (and better docs).

Clearer documentation on how to contribute to music21. (Thanks Carol Willing)

Lilypond output now gets the version of lilypond directly.

BETA: work on automatic chord reduction is ongoing. Please let us know if you want to test anything.

Security improvements in a few places.

Added support for Vibraphone in instruments (thanks Chris Culy) and initial support for tablature six-line staves (thanks metalmike).

Lots of bug fixes and improvements (mainly Josiah's great work under the hood). Thanks also to the NEH, the Digging into Data Challenge, the Seaver Foundation, and MIT for support of the project.

Music21 v. 1.7.1.

In the three months since v. 1.6 some good changes and improvements have been introduced. We focused primarily on stabilizing features that were already in music21 in some form but were too experimental to advertise widely.

A noCorpus version of music21 has also been released, the first since v.1.0. This version can be used in pure Free/Libre projects since files that were licensed for music21 only or non-commercial use have been removed. If you are not sure which version to download, definitely get the full version. But maintainers of Debian Linux and others can update to 1.7 noCorpus.

Music21 v 1.7 (actually 1.7.1) will be the last version to support Python 2.6. Python 2.7 is over three years old and is supported by other flavors of Python including Jython (which skipped 2.6), PyPy, IronPython and is an easy upgrade for Python on Windows. Mac users have had 2.7 since Mountain Lion and we're happy to report that with Mavericks being free and supporting systems that can run Snow Leopard, we're happy to be able to use this opportunity to take advantage of the latest features and start a roadmap to supporting Python 3.3 as well. This is also the last release to use SVN. We are moving to GitHub. Updates soon.

The most important improvement for users is a much improved system of metadata searching (thanks to Josiah Oberholtzer). See:

http://web.mit.edu/music21/doc/usersGuide/usersGuide_11_corpusSearching.html

for more details. LocalCorpus objects are elevated to equal status as the Core corpus so you can now build searchable indexes on any data you have and find the file you want much faster. Try corpus.search('haydn') and read the docs above to see what's possible.

Among the other 150+ changes since 1.6 include:

• Chord.inversion(2) will take a root position chord and put it in second inversion. (this is a change of behavior from before, where .inversion(2) would specify that the chord was in second inversion and override default inversion reporting (for things like Jazz 6 chords). To get the old behavior, use .inversion(2, transposeOnSet=False)
• Fixes for abc parsing (N.B. the next version will rename the "abc" module to "abcNotation" to avoid the occasional name clash with the python AbstractBaseClass (abc) module).
• Stream.getElementsByOffset(4.0) can now find a zero-length object at 4.0 -- bug fix.
• Many modules are now packages (Stream, for instance). This should not affect your code. Existing packages with X/base.py can now find their files in X/init.py. Again, this should not affect your code.
• Page break support in Lilypond.
• MIDI translate works better with instruments (thanks to Christopher Antilla)
• Improvements to Braille Music Code output (thanks to Mario Lang; more to come)
• Bug fixes in measure copying involving pivot chords and secondary dominants in RomanText
• Roman numerals for VII, VI, viio/vii, vi/vio in minor are made more robust. It6, Ger65, Fr43, are now supported.
• Many many many bug fixes. Thanks to community help!

Thanks as always to the NEH, Digging into Data program, the Seaver Institute, and MIT for their support of the project.