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).
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.
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 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...
> 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.[1]
If there are, it's not beyond reason to add something to git to make it work better.
If changing a single bit at the start of file changes the whole thing then it's really a failing of the file format. By which I probably mean the container format.
A version control system that would/is using patches internally would be more space efficient, but probably slower as it would have e.g. to apply all patches from version 0 to reconstruct the current version. Git made its choice with regard to this frequent dilemma and its original purpose, which was to version control the Linux kernel source code.
> If changing a single bit at the start of file changes the whole thing then it's really a failing of the file format. By which I probably mean the container format.
Audio formats are typically compressed, so this is hardly avoidable. Compression is a bit like encryption in that regard, except that (good) encryption deliberately introduces random data [2].
[1] https://jvns.ca/blog/2024/01/05/do-we-think-of-git-commits-a... (or long story short:) https://news.ycombinator.com/item?id=13644631
[2] https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
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:
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.
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.
Shameless plug: https://www.makidapp.com/
Linear version control makes total sense to me: "Can we go back to the version from 2 weeks ago" "which one was that? "Before we removed the hi hat!"
But I struggle to think of a realistic case for branching.
Edit: I suppose those are not generally collaborative, so from the context of merging branches from other contributors, I would probably agree that it becomes a little messy when most of the contributors are not also fluent (or even passingly familiar with) git.
But branches are only really useful if you can merge. If the more-cowbell branch tests well, and the faster-tempo branch also tests well, you'd like to merge them. But the file formats in music production don't generally allow such things.
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?
For the second question ablbundle, the Ableton Note project filetype, might fit your criteria.
and it's more "nagware" than "crippleware"
If you can’t get the source code out of it (or, in this case, DAW project), it isn’t version control, it is more of a binary release history.
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
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 dont think it’s trivial at all, but exposed with a basic ui it could be a killer feature.
Hell, as a POC even simply saving everything internally on each “commit” could be a UX improvement, so you can move easily between “save points” of the project without going the “V2_final_forreal folder” route.
The problem comes mostly from two angles:
1) DAWs which allow you to use external audio/MIDI files and do not place referenceable copies of them inside the session/project folder itself.
2) Plugins that are available on the original system but are not available for whatever reason on the new system.
In my experience, #2 is a vastly bigger issue than #1.