[torben-friis]

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).

[thw_9a83c]

At least the Reaper has a quite readable "rpp" XML project file. So this probably works nicely. Other that that, versioning DAW projects is a pure hell. It would require to version control all samples, plugins, configurations, etc. I don't really see an easy way to do it.

[torben-friis]

That’s why I said it should fall on the daw. They can serialise their own settings, including the plugins used and its versions, and have a common interface for plugins to expose and restore a serialisation of its internal setup.

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.

[PaulDavisThe1st]

> They can serialise their own settings, including the plugins used and its versions, and have a common interface for plugins to expose and restore a serialisation of its internal setup.

I'd be incredibly surprised if there is any DAW in existence that doesn't do this already.

But it has very little do with version control per se.

Ardour already has "snapshots" which work pretty much as you describe.

[torben-friis]

>But it has very little do with version control per se

How so?

For clarity, my train of thought was that if you have that, you have easy differentiation.

Someone edited the transpose knob of a sampler plugin, someone else edited the cropping marks, you can take a shot at merging those differences.

Sometimes it might not make much sense - if you edit a synths preset, other people’s changes aren’t going to fit in the new one. But it’s a starting point at least.

[lodovic]

An Ableton live set file is just a gzipped xml, so I can imagine some git hook that would unzip it before committing it to git. That way you can merge different branches, but it will surely come with its own limitations.

[sorrythanks]

It'd be cool to see something like the recent Automerge/Godot thing built into a music making application.

https://www.inkandswitch.com/project/beckett/

[nativeit]

This is really neat. Beckett being one part of a broader effort to develop "universal version control".

https://www.inkandswitch.com/universal-version-control/

[PaulDavisThe1st]

Ardour projects are self-contained by default, and can be moved between different systems and different operating systems.

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.