{"id":1105,"date":"2017-07-20T13:07:10","date_gmt":"2017-07-20T12:07:10","guid":{"rendered":"http:\/\/michael-edwards.org\/wp\/?p=1105"},"modified":"2017-10-18T13:11:37","modified_gmt":"2017-10-18T12:11:37","slug":"musicxml-output-from-slippery-chicken","status":"publish","type":"post","link":"https:\/\/michael-edwards.org\/wp\/?p=1105","title":{"rendered":"MusicXML output from slippery chicken"},"content":{"rendered":"

Back in 2011, after several years of using either\u00a0CMN<\/a>\u00a0<\/em>or Sibelius<\/em> (the latter via MIDI file import), I was considering alternative score output formats for my algorithmic composition software\u00a0slippery chicken<\/i><\/a>. With its 3.0 version status that year,\u00a0MusicXML<\/a>\u00a0was showing maturity and was definitely a contender for\u00a0slippery chicken<\/i>\u00a0output. After playing around with mainly Sibelius’s<\/em> 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<\/em> 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.<\/p>\n

\"\"<\/a><\/p>\n

Instead of MusicXML I developed\u00a0Lilypond<\/i><\/a>\u00a0output instead. I remember I’d taken off to South-East Asia for an extended coding retreat and to work on\u00a0you are coming into us who cannot withstand you<\/i><\/a>\u00a0for\u00a0Ensemble Aventure<\/a><\/em>. 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.<\/p>\n

Lilypond<\/i>\u00a0did and continues to do well for me and a number of other\u00a0slippery chicken<\/i>\u00a0users. The PDFs generated by\u00a0Lilypond<\/i>\u00a0are 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\u00a0you are coming,<\/i>\u00a0for example, noting the perfect legibility, with no overlapping items despite attached multiline text and custom graphics attached to notes.<\/p>\n

\"\"<\/a><\/p>\n

Without this near-perfect layout generated by Lilypond I wouldn’t have undertaken my\u00a0hyperboles<\/i><\/a>\u00a0series 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\u00a0slippery chicken<\/i>\u00a0then auto-rendered by\u00a0Lilypond<\/i>\u00a0before being auto-imported into the MaxMSP<\/em> environment for performance. Stellar work by the\u00a0Lilypond<\/i>\u00a0developers:<\/p>\n

\"\"<\/a><\/p>\n

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

Fast forward to 2017 and a solo violin project I have just been working on for\u00a0Mieko Kanno<\/a>\u00a0demanded just such an editing approach. So I paused, pondered, took a deep breath, then bit the bullet and started coding the MusicXML output from\u00a0slippery chicken<\/i>. This turned out to be a considerably longer job than the Lilypond<\/em> implementation, mainly due to the rather complex nature of MusicXML.<\/p>\n

Finale<\/i>\u00a0proved invaluable here. Out of the top three candidates, from my perspective at least—Finale<\/i>,\u00a0Sibelius<\/i>, and Steinberg’s newcomer and\u00a0Sibelius<\/i>-killer\u00a0Dorico<\/i>—Finale<\/i>\u00a0imported and rendered the most features of MusicXML. Of course, I would prefer to use an open-source project like\u00a0MuseScore<\/i>\u00a0or an academic\/free project like\u00a0noteAbilityPro<\/i>. Both of these import and export MusicXML but, to my disappointment, they both failed to deal with\u00a0nested tuplets\u00a0so were immediately ruled out.<\/p>\n

Finale<\/i>, then,\u00a0was instrumental in getting\u00a0slippery chicken’s<\/i>\u00a0MusicXML 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\u00a0Lilypond<\/i>\u00a0code, 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<\/em>. It’s all just aimed at defining the rhythmic aspects of a single note, albeit a nested tuplet:<\/p>\n

<duration>4536<\/duration>\r\n<type>16th<\/type>\r\n<time-modification>\r\n <actual-notes>65<\/actual-notes>\r\n <normal-notes>72<\/normal-notes>\r\n<\/time-modification>\r\n<beam number=\"1\">begin<\/beam>\r\n<notations>\r\n <tuplet type=\"start\" bracket=\"yes\" number=\"1\" show-number=\"both\">\r\n <tuplet-actual>\r\n <tuplet-number>13<\/tuplet-number>\r\n <tuplet-type>16th<\/tuplet-type>\r\n <\/tuplet-actual>\r\n <tuplet-normal>\r\n <tuplet-number>12<\/tuplet-number>\r\n <tuplet-type>16th<\/tuplet-type>\r\n <\/tuplet-normal>\r\n <\/tuplet>\r\n <tuplet type=\"start\" bracket=\"yes\" number=\"2\" show-number=\"both\">\r\n <tuplet-actual>\r\n <tuplet-number>5<\/tuplet-number>\r\n <tuplet-type>16th<\/tuplet-type>\r\n <\/tuplet-actual>\r\n <tuplet-normal>\r\n <tuplet-number>6<\/tuplet-number>\r\n <tuplet-type>16th<\/tuplet-type>\r\n <\/tuplet-normal>\r\n <\/tuplet>\r\n<\/notations><\/pre>\n
Useful as it was, especially in importing all kinds of goodies like special note-heads and text marks,\u00a0Finale’s<\/i>\u00a0post-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\u00a0Lilypond,<\/i>\u00a0where layout is automatic and carried out along well-established notational principles.\u00a0Sibelius<\/i>\u00a0did a slightly better job than\u00a0Finale<\/i>\u00a0in terms of layout but ignored things like note-heads. Also, despite having used\u00a0Sibelius<\/i>\u00a0for 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.<\/p>\n
Dorico<\/i>\u00a0on the other hand is a brand new notation package from the team that brought us\u00a0Sibelius<\/i>. Its very existence is due to Avid’s heavy-handed treatment of the London-based\u00a0Sibelius<\/i>\u00a0team which\u00a0Steinberg\u00a0<\/i>subsequently hired\u00a0en masse<\/i>. At first I wasn’t impressed with Dorico\u00a0<\/em>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<\/em> 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,\u00a0Dorico<\/i>\u00a0did a beautiful job of importing and notating my MusicXML. Although, like\u00a0Sibelius,<\/i>\u00a0it 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 <\/em>team will get around to improving import problems any time soon,\u00a0Dorico\u00a0<\/em>promises to be more and more inclusive as it rapidly develops.\u00a0You can see the results of MusicXML import in Dorico\u00a0<\/em>at the top of this post (from the score of my piece for Mieko), albeit after adding some special marks. The layout is all\u00a0Dorico’s<\/i>\u00a0however. This is what convinced me to buy and switch,\u00a0even though\u00a0Dorico <\/i>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.<\/p>\n","protected":false},"excerpt":{"rendered":"
Back in 2011, after several years of using either\u00a0CMN\u00a0or Sibelius (the latter via MIDI file import), I was considering alternative score output formats for my algorithmic composition software\u00a0slippery chicken. With its 3.0 version status that year,\u00a0MusicXML\u00a0was showing maturity and was definitely a contender for\u00a0slippery chicken\u00a0output. After playing around with mainly Sibelius’s MusicXML import functionality, however, […]<\/p>\n","protected":false},"author":1,"featured_media":1106,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,152,108],"tags":[159,157,160,161,156,158],"class_list":["post-1105","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-algorithmic-composition","category-programming","category-slippery-chicken","tag-dorico","tag-finale","tag-lilypond","tag-music-notation","tag-music-xml","tag-sibelius"],"_links":{"self":[{"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1105","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1105"}],"version-history":[{"count":14,"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1105\/revisions"}],"predecessor-version":[{"id":1121,"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1105\/revisions\/1121"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=\/wp\/v2\/media\/1106"}],"wp:attachment":[{"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1105"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1105"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/michael-edwards.org\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1105"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}