Patches serve as the glue for performing with open controllers like the monome. With proper version control, you can manage their evolution – and share your creative process more easily. Photo by me.

If you’ve worked at all with patching your own creations for music, visuals, and control, this has probably happened to you: you’ve made some change, and forgot what you did. You think of something you did some time ago – and forget what it was. Or you want to be able to easily collaborate with other people, and that means a lot of files flying around and no idea which file has which change. All of these problems are familiar to programmers. The solution: a technique called version control. Sounds fancy, but it’s really accessible to anyone, not just advanced programmers. And once you try it, you’ll never go back.

Git is a popular version control system that’s all the rage these days – aided by the star power of Linus Torvalds, its creator (who uses it for Linux kernels, not Max patches, sadly). Mormo aka Tomasz comes to the rescue of patchers with a complete guide to applying Git to patch management. Now, I’m a big fan of Subversion (“svn”) myself — but even then, you can follow the basic guidelines here and get something going.

Aside from the technical details of how this works, Tomasz gets into some of the deeper issues of what this is really about: sharing, collaboration, and openness.

Basement Hum: Version Control and Max/Msp. Part 1: Delegate Versioning to Git
Basement Hum: Version Control and Max/Msp. Part 2: Fragmentation vs Collaboration

Before you get scared away, just trust me on this: if you make patches, even simple ones, if you have zero programming experiment, you’re going to wind up loving version control. Naturally, this kind of version control could eventually be applied to musical materials and not just code and patches – and that’s when things get really interesting.

This works well for Max (and Pd) because it uses text-based patches. (Code will work nicely, too, lovers of Processing or Csound or SuperCollider or Chuck.) If you have binary files, it’s going to be tougher to do things like merges — sorry, Reaktor.

Tomasz writes:

Hi, I posted the first two parts of a three part series on why and how a version control system (git) can be relevant to musicians creating software devices for their music. The monome application-creating community and its use of max/msp form the case in point.

SVN would work fine too. I chose git partly because i’ve started using git lately at my day job (web development) and i’m interested to get to know it better. Also i really like that its trivial to put an existing project under git control, just a couple of command line instructions and no need to explicitly configure a repository.

There have been complaints lately from certain bloggers that Git makes it harder to share a repository online. I asked about that specifically, and Tomasz responded:

From your git managed directory it can be as easy as running:
git push

This will work if you’ve cloned a github repository as described here:
(though in the article i typed a more verbose version)

Previous post

The Art of Noise: Sonic Insanity with Hans and the Blippoo Box

Next post

Tonight: Electric Junkyard Gamelan Sounds at Handmade Music

  • I can definitely vouch for this approach. I've been using github for my Max object library for a few months and it works great:

    Having used cvs, perforce, svn, and git over the years, git is by far my favorite and is pretty awesome. I have no idea why people would think git makes it hard to share a repository online, it's really easy! Maybe if you've never used a version control system before… there is a learning curve. But compared to the other options, definitely easy.

    The one minor issue (not specific to git) is that the text format of Max 5 patches tends to rearrange itself a lot when you move some objects around, so diff'ing with older versions is often not particularly useful. Really not a big deal since we don't think of Max patches in terms of their text format.

  • Hey Adam,
    Well, I had used svn before … I just found it easier to use svn in shared environments. That seems to be the gist of the blog here, which I forgot to link:

    — a bit hot-headed, of course, but maybe you can sort out the problem? 😉

    I'm not familiar enough to know whether this is a deal-breaker with Git or not. I think the important thing is to find any version control system and use that — if you like it, if it's working, great! Just like backup — something is better than nothing, and beyond that, lots of choices.

    (If I had Git integration in NetBeans/Eclipse as I do svn, I'd be more into Git, personally…)

    One question: Max patches generally will get rearranged if you move the objects around, right? Are you saying Max 5 is worse?

  • afro.d

    ive been using svn for this, works great

    also using it for general protools/logic sessions … not useful for "going back" after small changes .. but it does work for sharing media and such .. i collaborate with someone across the US this way.

    also with svn i can use versions for osx, which is awesome.

  • "Max patches generally will get rearranged if you move the objects around, right? Are you saying Max 5 is worse?"

    It's the same problem, however the format is much more verbose in Max 5 so it seems worse… Maybe it's because the format is now fairly readable by a human, but because of the rearrangement issue diff'ing isn't as useful as it could be. Plus because of the larger size, it Max 5 patches will use significantly more space in the repository over time. Meh, disk space is cheap, so this is just an observation not a complaint.

    Not having an Eclipse plugin for git is a bit of a bummer, but there are some good graphical frontends like GitX (not sure about Windows).

    I try not to get all religious about what tools I use. I sample a variety of tools and stick with whatever one works best *for me*. So yeah, what you said 🙂 Who cares which is better an an absolute sense. That discussion is a waste of time IMO.

    Looking at that git-sucks article… I agree the distributed model (git,bazaar) is better than client-server (svn) and that's why I like it better. Maybe Bazaar is better, but github is now an important part of my development process and I don't see anything like that for Bazaar. The end to end git+github system is slick. It's easy to watch other people's projects for updates, branch your own version of anyone else's public code, submit patches to people. All my needs are met to my satisfaction.

    To help with any learning curve issues for people interested in git, I recommend this book:
    That publisher is pretty awesome in general.

  • Pingback: MaxMSPのバージョン管理 | nullblog*()

  • Max5 uses text-based patches. Max4 actually had two formats (based on an internal data structure called binbuf): one was textual, one was binary.

    I've not looked at the Max5 structure that closely (except to note that it's all JSON-based), but for Max4 the patchers laid down instructions for a stack machine when assembling object graphs, so line-by-line source control wasn't terribly useful when comparing differences; even a small change would rearrange the object graph drastically.

  • Jaime Munarriz

    Seems promising, but…
    wouldn't it be possible to have it integrated INSIDE PureData, a kind of Undo or History…
    just a Menu click away
    Pd can benefit of the collaborative spirit, and tajka advantage on Max
    just before Max for Live arrrives, then what?

  • Thanks Peter. There are a couple of related threads on the monome forum:

    SVN or Git:

  • Jaime – actually, yes, it could be possible to integrate version control inside Pd. That'd be a big task, but it's not impossible.

    Of course, using coding languages, it's much, much easier, and it's likely that your IDE already supports it.

    Which brings me back to my earlier question: Subversion has TortoiseSVN on Windows, Versions on Mac, support in NetBeans and Eclipse (among others). Is there any of this kind of support for Git? (I'm actually really surprised on the IDE front given how many people are using it!)

    Google Code, by the way, gives you easy SVN access, though that role is filled by GitHub.

    This is just a question, not an SVN vs. Git war. 😉 My guess is, given the projects out there, I'm likely to encounter both. And that's fine. I'm mostly happy everyone is discovering Version Control for Better Living!

  • Okie… yeah, Google is my friend.

    Now, that said, it doesn't look like these are anywhere near as mature as some of the svn offerings. But the NetBeans plugin looks usable.

    I'm still puzzled by some of the things I'm hearing, though, like someone on the monome forum saying they don't like svn because it "requires" an Internet connection, which just isn't true. (And anyway, any version control system "requires" a connection to host offsite … I mean, that's the definition of a server. Servers are good. So, um… what's the problem again?)

    The separate issue is how patch systems interact with version control. I've got a Pd project coming up, so I'll be interested to experiment.

  • Myles de Bastion

    I like SVN, I don't like the .svn garbage it litters all over your folder hierarchy.

    Waiting for my host (dreamhost) to support git and then I'll switch.

  • Pingback: R.Seiji » links for 2009-02-23()

  • RE: the diff'ing issue I was talking about above. Timothy Place (one of the Max developers) shared this helpful tidbit:

    "Since the change log is a mile long, I'll point out an obscure new power-user feature in Max 5.0.6.

    You can send a new message to Max like this (or put it in an init file):
    ;max sortpatcherdictonsave 1

    This makes it so that the JSON files that are use by Max for saving patches will keep the dictionary in the same order (alphabetized) every time you save. If you are keeping your patches in version control (e.g. SVN, GIT, CVS, etc.) then this should make your diffs a lot more usable."

    Haven't tried it yet but sounds very promising!

  • Pingback: Create Digital Music » Max 5 Bug Squash, Expo74 Max/MSP/Jitter Event in April()

  • @Peter: "saying they don’t like svn because it “requires” an Internet connection, which just isn’t true."

    That was me saying "It's like coming up for air not to having to rely on there being an internet connection every time you want to commit." on the monome forum.

    You're right that this doesn't necessarily have to be the case, but it has been the case with all svn projects that i've worked on that the repository i need to commit to is not a local one, of course ymmv. A typical git arrangement seems to have a different workflow in this regard; there's still a remote repository, but you have a local mirror of it too. You commit frequently to your local repos, and periodically push to the remote repos.

  • Right, but that's a chosen workflow, eh? There's no reason you couldn't do exactly what you're describing with subversion.

    I'd actually like to see some svn/git comparisons, but so far they've been from people on one side who seem not to understand the other. Oh, well — I'll be playing with both because now I'm running across more people using Git, so maybe eventually I can compare. 😉

  • "Right, but that’s a chosen workflow, eh? There’s no reason you couldn’t do exactly what you’re describing with subversion."

    Given that you know you want a particular workflow, the important question is how far does one tool facilitate it compared to the other.

    I don't know how tricky is it to commit to multiple repositories from the same working directory using svn (which i think would be necessary to approximate the effect of being able to commit locally and then push to a remote server at a later date). Or to take another example, how straightforward is it to update the same working directory from multiple different repositories.

    These aren't rhetorical questions; they're things I'd never done with svn and don't know if they're possible–while i know they're simple to do with git (great for working on the train!).

    "I’d actually like to see some svn/git comparisons, but so far they’ve been from people on one side who seem not to understand the other."

    I'm certainly not the best person to try to provide a proper comparison between the two, but for what it's worth, it does seem that a good proportion of git users used to be subversion users (myself included), while the opposite is not the case. Though i have seen a few posts from svn users switching to git and being confused (and angry), which i can relate to.

  • i said "(which i think would be necessary to approximate the effect of being able to commit locally and then push to a remote server at a later date)."

    But on second thought, this still wouldn't be equivalent to the git workflow described. I don't know how you'd go about emulating it using svn (can anyone explain?).

  • voxish

    Hi guys,
    I'm looking at getting into this stuff, and I'm investigating the svn vs git debate to decide which one to use. I came across Mercurial (hg), another solution that follows a distributed paradigm like git, but claims to have a much gentler learning curve. Does anyone have any experience with Mercurial and can advise?

  • These seems like a good place to mention my little trick on getting Quartz patches (which can be represented as binary or xml) to always serialize to XML inside git —

  • Pingback: Create Digital Music » Twitter Everywhere: More Tweet a Sound, SuperCollider Code, Richie Hawtin + Traktor()

  • Rafael Vega

    Links are broken, anyone has an alternative?

  • Rafael Vega

    Links are broken, anyone has an alternative?