Sunday, January 8, 2012

An Ableton Live Set is gzipped XML + a Ruby gem

Recently I started using git and github.com for version control of my Ableton Live Sets.  I pushed  these files to github to have backups and to be able to rollback to a previous version in case I got carried away on some ill-fated musical tangent.

But I was missing out on a one of the nicest features of git and github, diffs: I could not see the differences between two files or versions of my Live Sets.  Why?

Ableton's Live Set file is binary, not line based text.  I decided to reverse engineer the file:
  $ file Amy.als
  Amy.als: gzip compressed data, from Unix
Hmm.... Then, of course, I tried this:
  $ cp Amy.als Amy.gz
  $ gunzip Amy.gz 
  $ file Amy
  Amy: XML  document text
What!?
Reverse engineering done. Wait. Will Ableton Live read the file if I just gzip it and rename it?
  $ mv Amy.gz AmyTest.als
  $ open AmyTest.als
Poof! There it is. This was very nice of the Ableton developers. Thanks guys.  Now I can add and commit XML files to git and not binary.  It sucks to have to do this by hand for each Live Set each time I want to make a commit so I created the Ruby gem guard-live-set.

From the guard documentation: Guard is a command line tool to easily handle events on file system modifications.  My guard specialization just watches for any changes to a .als file and immediately creates a .als.xml version of it.  There you go, enjoy.

My hope is for more people to start committing their creations so that others can collaborate and then we can all benefit and improve from each other's creations.  I don't need to explain how successful open source software has been, why not open source music?  I'll throw in my Live-Set-github hat in with this: https://github.com/mgarriss/ugly.live.sets.

There is still a lot more work that needs to be done before true barrier free Live Set collaboration can be a reality.  First is the sharing of samples and plugins.  These are large files and not suitable for github.com.  Next we probably need some kind of .als lint program that could do more than indent; maybe it could keep things in a well defined order which would make the diffs cleaner.  An online friend is putting some thought into a Ruby gem for editing these .als files and I've agreed to contribute to that so stay tuned...

6 comments:

  1. I am happy to view your site the giving out various informational ideas on the blog with which it is dealing with github.com and this blog is good about the hacking technology.......

    ReplyDelete
  2. Really interesting workflow you have here. It seems very useful to be able to revert a live set to a previous version. Heaven knows that one can get carried away hacking a set.

    This is also a great solution for creating off-site backups of your files. One of my biggest fears is having my laptop stolen or hard drives fail (despite redundant backups).

    As a fellow Rubyist, I really like how you've tied Ableton + github + Ruby together. Nice work!

    ReplyDelete
  3. You, sir, are a motherfckn GENIUS!! I'm an ableton user and a ruby dev so this is doubly awesome.

    github.com/dcunited001

    ReplyDelete
  4. I came up with this idea at 4 am last night. After a quick internet search it turns out I am not the first.

    This idea is brilliant not just because it backs stuff up, but for two very awesome reasons:

    1. Internet collobaration through Git will make it so a shared set or template can simulatneously evolve in many directions by many users. Also, if enough users know what they are doing with Git, features can be cherry picked and merged in an exciting variety of ways.

    2. Even if you do not want to try and collaborate or share via Github, embracing the Git workflow of branching to try things out and merging individual features, etc should be a big boon to your own local workflow. Being able to experiment and easily revert to other versions should definitely make you less timid about trying crazy stuff out (without a sea of various cryptic filenames from constantly using "save as..")

    Cheers!

    ReplyDelete
    Replies
    1. forgot to mention: If you aren't familiar with Git, my favorite book that gives an idea of the workflow improvements it is capable of is: Pro Git by Scott Chacon

      Delete
  5. An easier solution would be to write a custom git hook that would just rename, extract and commit anything inside of a .als file.

    ReplyDelete