Can I get an Amen break?

Can I get an Amen break? Photo (CC-BY) MyBiggestFan.

Before there was computer code, there was music notation. And before there was forking code or remixing music, there were centuries of variations to the musical code, stored in notation. So it’s fitting that musicians would begin to use GitHub – built originally as a repository for programmers – to store notation.

And that means that in addition to music software and the like, you can find the WWII-era Nova Organi Harmonia organ accompaniments today on GitHub. Adam Wood, Director of Music with St. Stephen’s Episcopal Church in Hurst, Texas, made the addition, with help from a team including Jeff Ostrowski. The GitHub repository is hosted by the Church Music Association of America.

For musicologists and composers alike, Git seems a perfect fit. It makes it easy to track the contributions of any number of people, to file and manage variations, and to keep track of revisions over time.

In this case, the project uses LilyPond, an open source language for scores I’ve praised in the past. Because it’s text-based, that means you can track changes fairly easily. (The same would be true of interchange format MusicXML.)

Indeed, even for an individual musical user, Git could be a useful way to backup materials, access them online, and keep track of revisions – even before you get into the utility of collaboration.

Wood tells Wired that the project, in its infancy, improves the accessibility of the music, and calls GitHub “a much more stable and content-centric approach than warehousing your creative output on a blog or (good lord) on your own computer.”

I’d love to see what others might do with this. After a recent computer crash during a sound check, I’m now keeping my open source tools and materials for live performance on GitHub – more on that migration soon – and using the cloud for proprietary stuff, too.

What tools do you use online? And are you using GitHub (or other similar repository tools) for music? Let us know in comments.

Holy Octocat! There’s Church Music on GitHub Now [Wired]
Nova Organi Harmonia (Organ Accompaniments) [Corpus Christi Watershed blog - who put these online to begin with]
and: https://github.com/CMAA/nova-organi-harmonia

Oh, and do let us know if you come up with a creative use for this repository, too.

  • Micah Stupak

    I’ve yearned for a music format that’s diffable for a long time now… At one time, I thought the Ableton gang might be able to do it, after Max was added to Live, but it doesn’t look like that’ll happen now. A few years ago, I played around with something that did it for MIDI files, but not quite good enough.

    • http://sequadion.com/ Sequadion

      Once you unzip an Ableton Live set file (.als), you will find that the whole set is described in a huge XML file, which could be a good starting point for diffing. Of course Ableton can and will change the file format any time they see fit, so this approach is somewhat fragile.

    • Micah Stupak

      Oh, well, that’s something. Thanks for the tip, dunno why that never occurred to me…

    • http://pkirn.com/ Peter Kirn

      Yeah, I don’t think doing diffs in Live’s XMLs is going to be terribly useful. But any system that at least stores different versions is a start (Time Machine on OS X, even).

      I can see other cloud services working better for Live.

      Now, MusicXML on the other hand is small enough (for scores) that it might work…

      And GitHub is a great solution for Pd and Max – so your Max for Live Devices, definitely. For Ableton, I’d think more revisions/backup than version control.

    • http://sequadion.com/ Sequadion

      I agree that having some kind of backup with revisions is very useful, and there are many solutions for that out there.

      However, I just started thinking about the potential for merging changes from a collaborator into a Live set. This is certainly not trivial, and I’m also not convinced that anybody would actually want to use it, but it’s a fun technical problem to think about.

    • http://pkirn.com/ Peter Kirn

      It’d probably break the Live set. ;) But I’d be interested to try it.

      Now, what would work (I think) is:
      1. unzip the als
      2. check in the result

      That diff *should* work, in that each time you’ve saved you have a working project. And even despite step #1, successive saves would be smaller.

      Of course, Ableton ought to just do this by default as part of how it manages files. But I think this is straightforward enough to be worth a try.

    • http://sequadion.com/ Sequadion

      Storing the unzipped .als is probably a good first step, but I agree that relying on the built-in generic merge capabilities of any VCS will likely break the file.

      I was thinking more along the lines of a custom tool that would understand the contents of the XML (as opposed to treating it as plain text), and would ask the user what to do in case of a merge conflict. As an example, if both collaborators tweaked the settings of the same EQ Eight instance on the same track, the user doing the merge would have to decide which settings to keep.

      I’m already signed up for the Berlin Music Hack Day, do you think this would be a good project to hack on?

    • Micah Stupak

      XML-aware diffing has always appeared to be hard to handle in most software. I think I’ve tried all the Mac options. (If anyone’s found one that works, let me know, cuz my job would be so much easier.)

    • http://michaelgood.info Michael Good

      Oxygen Developer has some good XML diff-ing on Mac. On Windows I’ve used DiffDog, and Altova did a case study on our MusicXML use: http://www.altova.com/cust_recordare.html

    • Micah Stupak

      Yeah, Oxygen seems to be the best. I haven’t used it in a while, but something about it bugged me…maybe it’s improved recently.

    • Micah Stupak

      It’s not just about merging changes from a collaborator (which I think would be very handy), but also about forking versions of the same track. “Oh, v4 had a good bit, I want to add that to v5.2.”

    • http://sequadion.com/ Sequadion

      Good point, I haven’t even thought of the advantages of branching in a single author scenario. Weird, because I do that all the time, only with code. :)

      I don’t think that generic XML diffing is ever going to be easy. Parsing the application specific XML into an in-memory model and working with that is a much more promising approach. I have done that at work, albeit obviously not for DAW project files.

  • Brian Del Toro

    Anyone using blend.io? More of a remix community, but definitely nice for keeping sessions in the cloud.

    • Brian Del Toro

      Oh hey, a whole article on blend.io. Good timing!

  • haszari

    I’ve been source-controlling my production for a while now – committing WAV stems, samples, SuperCollider source code, Reaper project files to a mercurial repo and mirroring it on bitbucket. Am interested in hearing what others are doing, this is not ideal, as binaries (e.g. wav) don’t work well in most source control systems. SuperCollider code is a great fit for source control though; pd files would work similarly well! Even the Reaper XML diffs are somewhat meaningful ..

    • http://sequadion.com/ Sequadion

      I’m not that familiar with Mercurial, but I know that Git is not very good at handling huge binary files. There are a couple of clever hacks that try to address this (http://git-annex.branchable.com and https://github.com/bup/bup come to mind), but none of them are ready for prime time.
      I’m wondering if there would be enough demand for a service built specifically for storing, sharing, merging and diffing audio and/or video projects. I would very much be interested in building something like that.

    • haszari

      All true, no source control system is very good with binary, though apparently git and svn are slightly more amenable, and some people do use them for binary files.

      I don’t commit many changes to my WAVs, I commit a version early, and then might change a file once or twice. Also I commit smaller hits/loops/samples, which change rarely. It slows down clones/checkouts, and bloats the repo, but it’s worth it to have a self-contained project repo!

      When I last looked at this I found that there are commercial “asset management systems” which are more for the huge media library case, and don’t tend to be designed for versioning and change tracking. I’d be very interested to hear about a project!