Git for Music – Using Version Control for Music Production (2023)

Specific to this "problem" with git, are there music project formats that aren't binary, or at least trivially and unambiguously machine translatable to/from plain text?

If the binary format is just TLVs why can't there be a plain text representation?

AFAIK they all dump file management into the user, both for the “source” (projects) and the “binaries” (exported songs).

Ableton includes a feature for exporting self-contained projects so they don’t break if you load them in a different pc, which is the bare minimum, but other than that good luck.

Most of the problems engineers face are present in music production - collaboration, parallel work that may need to be merged, etc.

The subjective nature of music also makes it so that you’ll frequently want to try to develop the project some way and drop all changes if it doesn’t work, or that you’ll realise a change is problematic later (for example, something might sound well in headphones but horribly later in the car).

I find svn to be wonderful. There seems to be a real phobia against it which I've never understood and it's such a shame.

Especially when one of the biggest arguments "against" it is that "it's centralised" (when in fact using it in a decentralised manner is trivial), and ironically most people these days just use git as an interface to github (rather than the other way round), effectively using it in centralised manner.

The workflow is based on having the same software, ableton and plugins are largely mirrored.

We communicate over FaceTime which is good enough to assess ideas. When then record track for track and build the songs that way.

Shameless plug: https://www.makidapp.com/

When I start a DAW session I simply prepend the session file name with the date (YYMMDD). If I make a significant change to the session and might want to recall the older version I 'Save as' my session and update the date - or I add a version number if I make more than one new version in the same day.

For example:

250820 Song Title

250821 Song Title

250821 Song Title 1.1

250822 Song Title

At the end of each day I render the current project as a stereo audio file using the same naming conventions:

250820 Song Title

250821 Song Title

250822 Song Title

If I need to "merge" an older version of a session with a newer session my DAW (Ableton Live) allows me to drag tracks from the previous session. A few edits later and I've successfully imported the older asset that I wanted.

That's it. That's all of the version control that I need. All of my assets are saved in the project folder, I have an easy to parse chronological record of my project's development, and I always know the most recent version.

It's akin to working in LaTeX with Git, in that there's a source file that gets tracked, while the PDF output is untracked. And it's great because this is real source code and the Git diffs and commits are meaningful, unlike working in binary formats.

I feel fairly confident that decades from now my work will be recoverable, a confidence that I don't have when working with proprietary binary formats.

What options do I have for text-based DAW? I accept that this is a niche preference for solo work; I have difficulty imagining that such a platform would be suitable for traditional studio collaboration. I've dreamt about building something myself using AES31 if I only had another lifetime — but maybe someone has beaten me to it?

https://www.youtube.com/watch?v=gB7AsFbtJic

I did music production at the same time as heavily using SVN and starting to use Git - I didn't cross this over at the time. All (in my case) Cubebase files were just -1, -2 suffixes and it worked. I had continuous backups, sure and it just kinda worked at the time.

Given I now use Git heavily in my work/hobby life, when doing other projects (3D models for printing (questionable at best) and artwork (very very very questionable at best)) I definitely wanted to use some sort of SCM. I opted for these for Perforce - mostly to experiment, but also the idea of having binaries in a distributed SCM. Yes, I know Git-LFS _exists_, but also, to me it breaks the idea of what Git is.. relying on a server for binaries in a situations where everything should be distributed.

If I now went back to audio-production, I would probably consider either Perforce or SVN. Perforce only if it were for a single user (because of licensing). The ability to clone/checkout a single directory of a repo at a given point in time natively and make modifications and push them back is almost quite necessary when dealing with very large files.

And I still use SVN for _some_ situations - particularly those where Perforce is overkill and all I want to _always_ HEAD and the rest is history (for manual preservation history) and no such need for merging and branching (thinking Wiki and other plain-text tooling).

In the case of any sort of any binary-merging - I _heavily_ assume this isn't expected in the poster's situation!

  > git-annex is not git-media, although they both approach the same problem from a similar direction. I only learned of git-media after writing git-annex, but I probably would have still written git-annex instead of using it. git-media uses git smudge filters (recently supported in git-annex as well; see unlocked files) and may be a tighter fit for certain situations. It lacks git-annex's support for widely distributed storage, using only a single backend data store. It also does not support partial checkouts of file contents, like git-annex does.

  > git-annex is similarly not git-fat, which also uses git smudge filters, and also lacks git-annex's widely distributed storage and partial checkouts.

  > Similarly, git-annex is not git-lfs, which also uses git smudge filters, and appears to lack git-annex's widely distributed storage and partial checkouts.

  > git-annex is also not boar, although it shares many of its goals and characteristics. Boar implements its own version control system, rather than simply embracing and extending git. And while boar supports distributed clones of a repository, it does not support keeping different files in different clones of the same repository, which git-annex does, and is an important feature for large-scale archiving.

  > git-annex is not the Mercurial largefiles extension. Although mercurial and git have some of the same problems around large files, and both try to solve them in similar ways (standin files using mostly hashes of the real content).

We've had a few requests to integrate with music production workflows, but haven't taken it on yet. If anyone wants to collaborate to integrate Oxen with their DAW or workflow let us know! Here's the project:

https://github.com/Oxen-AI/Oxen

I expect over the next few years that the DAWProject[3] open source protocol for exchanging between DAWs could make it possible for some of the ideas of splice come back without having to rely heavily on undocumented binary formats.

[1]: https://splice.com/

[2]: https://cdm.link/splice-studio-is-free-backup-version-contro...

[3]: https://github.com/bitwig/dawproject

Also many DAWs export their project files as binaries (like Logic) so Git wouldn't like that much in terms of Diff and Compression

The main issue is also maintaining multiple folders. Git can do submodules, but that means creating new gits, publishing, making new submodules etc which is a waste of time that a normal person would rather spend making _v2s, even though they're cloggy and messy