Back in 2011, after several years of using either CMN or Sibelius (the latter via MIDI file import), I was considering alternative score output formats for my algorithmic composition software slippery chicken. With its 3.0 version status that year, MusicXML was showing maturity and was definitely a contender for slippery chicken output. After playing around with mainly Sibelius’s MusicXML import functionality, however, I gave up on the idea. Though MusicXML could and still can capture microtonality and many other weird and wonderful things that go way beyond what MIDI can encapsulate, Sibelius didn’t even notate quarter-tone accidentals, never mind various marks and now fairly standard note-heads that my scores required. So I passed, with a view to look again at some point in the future.

Instead of MusicXML I developed Lilypond output instead. I remember I’d taken off to South-East Asia for an extended coding retreat and to work on you are coming into us who cannot withstand you for Ensemble Aventure. I wrote the vast majority of the Lilypond-generating code in 3-4 days in Ko Lanta Old Town, a small village on an island in Southwest Thailand. My room was in a house on stilts jutting out to sea.

Lilypond did and continues to do well for me and a number of other slippery chicken users. The PDFs generated by Lilypond are nothing short of astounding in fact, particularly when it comes to the automatic and almost flawless layout it produces. See below the last system of you are coming, for example, noting the perfect legibility, with no overlapping items despite attached multiline text and custom graphics attached to notes.

Without this near-perfect layout generated by Lilypond I wouldn’t have undertaken my hyperboles series of works. These pieces allow musicians to tweak various fundamental parameters of the generative algorithms to produce a custom score and electronics. Again, notice below the near-perfect layout along with the use of more custom but still algorithmically-placed graphics, colours, note-heads, etc. All of this is generated first by slippery chicken then auto-rendered by Lilypond before being auto-imported into the MaxMSP environment for performance. Stellar work by the Lilypond developers:

Of course there are times when 100% algorithmic score generation is just not possible or desirable. To this end I developed various slippery chicken methods to add/alter score elements “by hand” before generating scores. Still, editing scores via Common Lisp code is not everyone’s dream scenario. This is where WYSIWYG notation software like Finale and Sibelius come into their own of course.

Fast forward to 2017 and a solo violin project I have just been working on for Mieko Kanno demanded just such an editing approach. So I paused, pondered, took a deep breath, then bit the bullet and started coding the MusicXML output from slippery chicken. This turned out to be a considerably longer job than the Lilypond implementation, mainly due to the rather complex nature of MusicXML.

Finale proved invaluable here. Out of the top three candidates, from my perspective at least—Finale, Sibelius, and Steinberg’s newcomer and Sibelius-killer Dorico—Finale imported and rendered the most features of MusicXML. Of course, I would prefer to use an open-source project like MuseScore or an academic/free project like noteAbilityPro. Both of these import and export MusicXML but, to my disappointment, they both failed to deal with nested tuplets so were immediately ruled out.

Finale, then, was instrumental in getting slippery chicken’s MusicXML output working properly. It seems to have the most complete import functionality and, very helpfully, gives informative error messages if there are any problems. Anyone who’s written code to write code knows how tricky this can be. Though well-documented, MusicXML is, like most similar systems, difficult to get your head around at first. Like Lilypond code, it’s nice that it’s a text file format, but being XML the code is extremely verbose (not that that’s a problem for users of course). The tag/property system is well-known from a variety of coding systems but one of the first things that became apparent was that, unlike some more flexible approaches, MusicXML forces a certain tag order (I wasn’t expecting that at all). For example, accidentals must come after the rhythm type, it would seem. Rhythms themselves are their own mini-nightmare, especially when it comes to tuplets and nested tuplets. Just look at the following MusicXML code produced by slippery chicken. It’s all just aimed at defining the rhythmic aspects of a single note, albeit a nested tuplet:

<duration>4536</duration>
<type>16th</type>
<time-modification>
 <actual-notes>65</actual-notes>
 <normal-notes>72</normal-notes>
</time-modification>
<beam number="1">begin</beam>
<notations>
 <tuplet type="start" bracket="yes" number="1" show-number="both">
 <tuplet-actual>
 <tuplet-number>13</tuplet-number>
 <tuplet-type>16th</tuplet-type>
 </tuplet-actual>
 <tuplet-normal>
 <tuplet-number>12</tuplet-number>
 <tuplet-type>16th</tuplet-type>
 </tuplet-normal>
 </tuplet>
 <tuplet type="start" bracket="yes" number="2" show-number="both">
 <tuplet-actual>
 <tuplet-number>5</tuplet-number>
 <tuplet-type>16th</tuplet-type>
 </tuplet-actual>
 <tuplet-normal>
 <tuplet-number>6</tuplet-number>
 <tuplet-type>16th</tuplet-type>
 </tuplet-normal>
 </tuplet>
</notations>

Useful as it was, especially in importing all kinds of goodies like special note-heads and text marks, Finale’s post-import layout was, frankly, appalling. Pretty much everything but the notes was laid out on top of each other, meaning that a massive editing job would be necessary. Compare that to Lilypond, where layout is automatic and carried out along well-established notational principles. Sibelius did a slightly better job than Finale in terms of layout but ignored things like note-heads. Also, despite having used Sibelius for several projects in the past, the parent company’s policies seem to pretty much guarantee its obsolescence some time in the not-so-distant future.

Dorico on the other hand is a brand new notation package from the team that brought us Sibelius. Its very existence is due to Avid’s heavy-handed treatment of the London-based Sibelius team which Steinberg subsequently hired en masse. At first I wasn’t impressed with Dorico because the MusicXML import didn’t seem to be working (and there were no error messages). However, an email exchange with the indefatigable Daniel Spreadbury and Dorico’s in-house MusicXML expert revealed subtle errors in my XML code which weren’t being picked up elsewhere. (Yes, I learned even more about the intricacies of rhythm encoding in MusicXML.) Once I’d fixed these, Dorico did a beautiful job of importing and notating my MusicXML. Although, like Sibelius, it currently ignores a fair amount of encoded data, like note-heads and text marks, the automatic layout is immediately clear and, in my opinion, beautiful. Furthermore, whereas I’ve not much confidence that the Sibelius team will get around to improving import problems any time soon, Dorico promises to be more and more inclusive as it rapidly develops. You can see the results of MusicXML import in Dorico at the top of this post (from the score of my piece for Mieko), albeit after adding some special marks. The layout is all Dorico’s however. This is what convinced me to buy and switch, even though Dorico is still quite near the beginning of its development cycle (version 1.1 has just been released). Some essentials for me are still missing (e.g. artificial string harmonics) but I can find workarounds. I really appreciate the consistent workflow and, up to now, lack of kludges in the fundamental design. MusicXML finally looks really promising for people with special (notation) needs.

Share Button