A Revision Control System for Tracking? Does one exist?

[bottha]

I'm wondering if anyone is using a Revision Control System (e.g. Git) for versioning their projects. RCSs are an integral tool in software development and I, for one, believe that they could be a very useful tool for production.

In case you're wondering what these tools do: every time a professional software developer changes any aspect of a project (e.g. some C++ code), he "checks in" his changes with comments as to what was changed. The RCS keeps track of these changes and enables the developer or colleagues/collaborators to retrieve older versions of the code. This can be essential when, for example, a bug has been introduced and reversion to an older version of the code is necessitated. These applications are feature-rich and can enable a developer to quickly home in on a salient piece of code that is causing issues. Of course, most professional software environments employ nightly builds followed by test suites to ensure that nothing checked in during the day broke any functionality.

How would this work in the music production environment? Say you're working on a track which involves multiple VSTs and audio tracks. Over time, some of the audio tracks may be modified or removed. Others may be added. VST parameters may change. A month after beginning the project, the producer wants to retrieve a version from 3 weeks prior. Obviously, one could simply save each version as it changes giving it a different name and keeping a separate studio log which details the changes. But this quickly can become unwieldy (this is the reason that software developers use RCSs).

So, does such a system tailored for creative production exist? Has anyone tried using the existing software-centric RCSs?

[doghouse]

In my day job I've used and administered rev control systems for many years so I'll jump in. My gut feel: not that useful.

A big downside with Live would be manually entering each of the (many) files into the rev control system. At the end of every session you would have to navigate through all your directories to identify new files (the rev control already knows which existing files have changed) and enter them.

My feeling is that making regular backups of your hard drive and using the Collect All and Save and Save a Copy features is easier to deal with than a rev control system.

[monobeach]

well, Live features an undo history

Cubase has a edit history, where you can undo actions done in the project window, and a offline process history, where you can remove edits of individual audio clips, including VSTs, for example

[creature]

this is an asset control system for media.

http://www.alienbrain.com/

[bottha]

Thanks, guys.

@doghouse: I know what you mean, but there are a couple of things this doesn't address. What if we're talking about incremental changes to one file? Then we waste an awful lot of hard disk space saving entire projects. If I change one parameter on one VST, I don't want to save the entire project in another version. In addition, how do I identify that version? I could keep a separate log of changes, but that is error-prone. As far as having to enter any new files, I was hoping that a rev control system would keep track of any new files introduced into the project.

@monobeach: Live's undo history is per-session only. Cubase's is similar (though the addition of the offline process history is good). My main concern is that 3 months down the road I'm going to look for a specific version of a project and won't be able to access it.

@creature: I haven't seen that before. Am checking it out now. Looks like it's more geared toward video type editing, but this could be what I'm looking for.

-H

[creature]

you could also use a traditional control system like perforce or subversion if you dont mind managing the files manually and forsaking complete integration.

[colinmcardell]

@bottha
I've been trying to figure out something nice in regards to git versioning my Ableton projects.

Overall, I haven't really seen a huge bonus to doing this unless I'm working on a big sound design project where I'm bouncing a bunch of tracks around and then deleting the originals to lower track counts... Then tagging is super handy and all that kind of stuff. But... that being said, at this point, I tend to version control all of my projects just because Time Machine (I'm on a Mac) or rsync backups on a timer don't catch all of my versions... Anyways.

I've basically resorted to writing a bash script that manages the .als files (gzipped XML file)... as in it gunzips the project file before doing a diff/merge then committing changes. This needs to be done with the very first commit so that the .als is XML in git and not a binary file... Using git hooks to handle this would be nice, but I ran into limitations in the diff vs. merge parts of git.

So far I've made pretty good progress with this setup, however, branching in multiple directions then merging back together is pretty brutal due to the complex nature of the XML info in the .als file. I've basically stuck to a single master branch and occasionally I'm splitting off a single branch at a time for any creative experimental path that I might want to explore... then merging that branch back into the master if the results are positive. Otherwise, kill the branch if my experiments fail.

Basically, not the most collaboration friendly mechanism at this point, but it would be great to be able to publish a repo and have others contribute to it... Open Ableton projects on Github... I'm sure they would be happy about the audio files. Maybe someday... low-res proxy files... Could be done... Dreaming.

Kind of tweaking my script at this point because it's sloppy and I'm not a super experienced BASH scripter... Also working on something that is more Automator/Droplet like so that I can just drag and drop the project folder to update the repo. Would be happy to share if this is of interest to anyone and they are interested in contributing.

[matthews]

Isn't Kapture (http://liine.net/en/products/kapture/) something similar that could used in this regards?

Take a "kapture" of the project initially, and then every so often when you see something you like. Then just recall any of them at anytime you need. If your not liking the way a project is going, just go back however many "kaptures" you need to start over at a place you like.

Of course this is not the same as a traditional Revision Control System used in programming, but it could potentially be utilized in a similar method.