alt Hacker NewsGit for Music – Using Version Control for Music Production (2023)
Comments
Splice[1] Studio[2] used to be version control for music software (from about 2013-2021). You could browse Ableton Live (and a few other DAWs) projects and see the tracks and rendered versions each time you saved, add metadata etc. They pivoted into the more profitable sample discovery and sales business later and dropped the less profitable studio product.
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...
It's interesting seeing parts of life overlap.
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!
Not pretending to be an expert in either system's internals, but I feel like svn would be a much better fit than git for this.
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.
This prompted me to learn about the following git features/extensions, namely `git-annex` and its list of adjacent items ("what git-annex is not"[1]) that might be useful (or suggestive of an alternative) in the context of music production:
> 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).
The binary file problem is real - audio files balloon Git repos fast. Git LFS helps but adds complexity. I've had better luck with a hybrid approach: Git for project files/metadata/stems, cloud storage with versioned folders for final mixes. Keeps the repo lean while maintaining the branching workflow benefits.
I use Git with Lilypond[1], text-based music notation software: https://lilypond.org/
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?
I’ve been using git for remote collaboration music production for 5 years. We sometimes use branches as well when we are working in let’s two ideas for a bass line. We’ve not really had any issues other than that we need git lfs.
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.
Here's a video of a talk at the 2022 Ubuntu Summit on using version control with Ardour for the same purpose as TFA, but also for collaboration (particularly during COVID):
One of the maintainers of the Open Source project "Oxen" here. Our VCS scales for binary data better than git does, and was built to solve some of the problems with git-lfs and git-annex.
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:
I maintain MAKID, which is a desktop app built to integrate with Ableton live files in order to help manage versioning/organization. I’ve been wondering if a git workflow is the right one for producers. I feel like it sounds nice but in the end ppl are probably just gonna copy and paste their files because it’s intuitive and easy. Plus I imagine users getting confused by branching causing them to think they’ve lost their progress.
Shameless plug: https://www.makidapp.com/
I'm one of the founders of https://diversion.dev. It's a version control used mainly by game developers, but also by some audio and video artists. Its advantages over git for music production - 1) it works with large binary files out of the box, and 2) it's easy to use for non-technical people. This also solves the issue of backing up and sharing the project complete with large media files that the author mentions.
I've been doing this for years, I also use git for graphic design projects. I know it was invented for software development, but I have found it to be quite capable for document management, just generally. Using branches for remixes or derivative works feels very natural.
The difficulty with sharing projects is why we built Sesh (https://sesh.fm), like Figma for music. We auto-resolve edits live in the same session, no Git-style branching/merging to think about. Just share a link, see collaborators' cursors, record and edit together in real-time. It’s early days, but we’ve had some fun seshes so far. Happy to answer questions.
Most producers just use SoundCloud for version control. You can export tracks directly from the DAW. Since it's cloud-hosted, it's easy to share with others and enable them to listen and drop feedback as comments within the track waveform.
It may never happen but I sure wish there was an open protocol for DAW files. Sounds like Reaper XML is a good start
This is really a problem that should be solved by the daw itself.
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).
There should be a seperate VC for this, because using git for stuff like that is a bit wrong.
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
this will work if and only if the DAW has good format (lexical, not compressed etc.)
I built this: https://github.com/profullstack/music for OSSM
You need git annex to make it work well assuming everyone on the project can be taught to use git.
Are there any examples of music software that can be used professionally and isn't crippleware?
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?
I'm not a programmer and I don't use Git, but I am a record producer and it's not clear to me what advantage this provides.
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.