A couple of weeks ago the Music Encoding Conference 2016 was held at McGill University, Montréal, Canada. I attended on behalf of the Keyboard Philharmonic project. I was like a kid in a candy store: so many people with so much experience in representing music notation digitally, so many interesting talks, so much friendliness. I also had the temerity to hold, despite my first-time status, a workshop on the first day of the conference: “Encoding Music at Music Encoding”, where we would follow the Keyboard Philharmonic process to encode a short score. The goal was to release it to the public domain by the end of the conference. Here is how we did.

The annual Music Encoding Conference is put on by the MEI community, but they intentionally welcomed participation from other music notation projects (e.g. the W3C Music Notation Community Group and MusicXML). In that spirit it seemed like they Keyboard Philharmonic would be a worthwhile addition. Essentially, we are a music score publisher. Most of the other attendees are academic musicologists — figuring out how to make notation formats better tools for other scholars, for musicians, and for publishers. A few other software developers for various music notation tools or infrastructure were also there.

Tuesday, 17. May 2016, was the workshops day of the conference. Our “Encoding Music at Music Encoding” workshop ran for the full six hours of that day. My goals were to inject a note of practical application to a conference that might be at risk of staying to theoretical, and also to help the conference take satisfaction in moving musical culture one notch, however small, forward. It also was a way to make the Keyboard Philharmonic’s goals and methods visible to this influential audience.

I selected a score which I judged would be manageable for this size of group to complete in that day: Bach’s Gigue in F-minor, BWV 845, using the IMSLP 06429 score as a reference. It was two pages, or 49 measures long. We had a total of 10 people participate in some or all of the workshop. It was a fantastic collection of skill and experience: a music librarian, a software developer of a music notation tool, an MEI core architect, a musicologist and head of the 2016 program committee, a music librarian and head of the 2017 program committee, university professors, graduate students, and more.

We spent about a 90 minutes introducing ourselves, and walking through the plan of the day. I didn’t want to impose the KeyPhil process on this group, I wanted to hear if they had better ideas first. The resulting discussion covered many of the strategic points of the KeyPhil approach, including the focus on MusicXML before MEI, the availability of tools, the need for a transcription true to the reference score, and so on. I came away with confidence that the KeyPhil approach is on the right track.

We then divided the score among ourselves to make a 433 edition of the Gigue. This is a digital score which corresponds measure-for-measure and page-for-page to a specific source printed score, but each measure consists of rests only, no notes. Each person did a system or two of the 13 systems in the score, using their preferred notation editor, and then uploaded a Music XML score with that fragment. I opened the fragments in the MuseScore notation editor, copied their measures, and pasted into a master score document. By lunchtime, we had assembled and proofread the 433 edition.

I tracked all edits in a Github repository, bach-j-s_gigue-f-minor-bwv845_bga-1840.

In the afternoon, we had a slightly different set of participants, and a few more hands overall. We set to work making a Fidelio edition of the score.  This corresponds faithfully, note-for-note and page-for-page and error-for-error, to a specific source printed score. It is distributed in the MusicXML format, because that’s what most musicians are able to import into their notation editors.  (MEI is under consideration, and this was a continuing topic throughout the conference). The faithful correspondence to the source score permits easier distributed proofreading. The Fidelio edition of the score is intended to be the the primary product of the KeyPhil work.

We encountered a number of interesting difficulties with the notation:

  • The mid-bar repeat in measure 24 was difficult to enter in most notation editors. We had one person figuring out how to persuade MuseScore to enter it, and another figuring out how to make Finale comply. Eventually, we got it. (The trick is to have two measures, separated by a repeat bar line; one with 11 of 12 beats, and the second with 1 of 12 beats and omitted from the measure numbering.)
  • MuseScore was not able to copy and paste notation reliably; it dropped notes and formatting
  • The task revealed bugs in some of the contributing notation editors
  • Proofreading was difficult, and even after two passes, some errors remained
  • Proofreading lead to bug reports, and the bug reports piled up faster than I could correct in real time in MuseScore. I made an informal bug list, and had to address the bugs later.
  • a participant made an interesting point: in collaborative workflows, bugs are best fixed either by the discoverer, or pushed back to the person causing the bug to fix. The bug list model I was using was not as effective a workflow. This will be interesting to look at as the KeyPhil process matures.

By the end of the workshop day, we had all notes from all measures entered, and a draft Fidelio edition of the Gigue checked in.

None of us made any progress on the score for the next two days. The time was too full of interesting talks and evening banquets. The final day, Friday 20. May, was an “unconference” with an open agenda. I took a few hours of this day for doing proofreading and formatting. An unexpectedly time-consuming task was figuring out how to present metadata in the Fidelio edition. I wanted to document the work, the edition of the reference score, the transcription details and contributors, and the CC0 licence. The final MuseScore document with the Fidelio edition, and corresponding PDF format and MusicXML format scores, were finally committed on Fri May 20 23:40:39 2016 -0400.

So, the first Keyboard Philharmonic work product is available! Bach’s Gigue in F-minor, BWV 845, with the 1849 Bach-Gesellschaft Ausgabe, Breitkopf und Härtel 1840 edition as reference, retrieved from IMSLP 06429, in the following editions:

This digital score is dedicated to the Music Encoding Conference 2016, in tribute to how the conference welcomed the Keyboard Philharmonic project, and to the conference participants who did the transcription. They were (alphabetically): Jorge Calvo-Zaragoza, Richard Chesser, Jim DeLaHunt, Timothy Duguid, Jose M. Ifiesta, Franz Kelnreiter, Johannes Kepper,  Christina Noel, David Rizo, and Sonia Wronkowska.

Is work on this score complete?  Certainly not. There are drawbacks and flaws in each of the above work products. I expect that readers will report bugs, which will require revisions to correct. The process has exposed bugs and inadequacies in the MusicXML  format, the way MuseScore and other tools export MusicXML and PDF. It has exposed bugs within MuseScore itself. The files need to be contributed to IMSLP and archive.org, among other locations. We need to experiment with MusicXML to MEI conversion. We need to see how faithfully the MusicXML files import into other notation editors than MuseScore.

Was the workshop a success?  Absolutely. A digital score is transcribed, proofread, and freely available. The process of performing the transcription was educational for all the participants, and a great test of the Keyboard Philharmonic goals and workflows. I think the conference was enriched the the practical exercise. My thanks to all involved.

No Comments »