How nice would it be if, how Git and the like do this for code on a per line basis, DAWs could do the same thing but with tracks instead of lines. And, like with Git or similar, you could easily switch and merge between branches of a song etc. - how is this not a thing already in DAWs in general? Why not?
What’s to stop you making a Git repository and checking an Ardour project into it?
I’m not sure whether merging would produce meaningful results, though.
There would need to be some sort of repository involved, yes. And for the merging to make sense in this context, you should be given an option to compare two versions of a song on a track by track basis and decide which to keep etc., similar to a diff of code.
So who is going to code that?
Not that it is a bad idea persay, but it involves a LOT of coding (As in an entire new piece of software in terms of UI). Many DAW manufacturers and Ardour’s team would probably rather focus on making tools that more directly help make music is my guess.
I don’t know, man, just kinda throwing it out there.
Just strikes me as something I personally would find extremely helpful when collaborating on things and stuff with one or more other people.
I do suspect the UI would be the least of the unlucky coder’s worries, probably just a few menu entries and one or two new views. Switching tracks between various states according to commits might, I’m guessing, be more involved.
Am I wrong though? Would that not be, like, super convenient? As opposed to just throwing song files and wavs and stuff onto Google Drive or DropBox or whatever, and then faffing about with copying stuff between sessions and -_- ugh …
The idea is nice, but have you ever resolved merge conflicts in code? It can be quite a nightmare if things aren’t managed well by developers. Trying to do so in a complex DAW session where people are getting creative sounds like a headache ten-fold.
Ardour’s snapshot feature offers some potential for “branch” like workflows. Or git can work quite well if you are the only contributor. I’ve actually used git to manage an ardour collaboration, but since we were many timezones apart we were never working on it at the same time and were able to completely avoid merges. See https://github.com/ssj71/OSC90 if you’d like.
That said it would certainly be an interesting project to try to come up with an open DAW session format that is condusive to merges like that. I think you’d more or less have to track the entire action history with timestamps, like “record region,” “remove region,” “add plugin,” “change plugin param,” etc. Then merging branches would be attempt to apply the history of actions. Plugins though, add a whole new level of pain, what if the system is missing the plugin or the plugin is a different version? Especially if you are working cross platform this will be difficult to understate it.
Interesting idea for sure, fun to think about, but I’m definitely not going to take it on.
The idea is nice, but have you ever resolved merge conflicts in code?Not only that, I've tried to resolve conflicts in XML from a documentation package. I shudder to think what doing that in Ardour's XML files would be like. The only benefit I can see in using Git with Ardour is being able to go back to an earlier version after messing up an editing session big time, i.e. using Git as a multi-generation backup tool.
I appreciate that it might remain an entirely hypothetical discussion forever. Still, what if such an open session format wouldn’t even aim to track anything other than audio? I.e. just dealing with audio representations of the, err, tracked tracks. Meaning MIDI notes/control, plugin settings etc., all that remains local, and your process of “pushing” to the “repository” is sort of just rendering a track into its equivalent in version control. Might remove the bulk of the headache and be as open / agnostic as possible, yet at the same time it would do most of what we usually would want it to when collaborating on a song - to hear what the others are tinkering with and integrate it into our own tinkering process.
I guess what I’m after isn’t so much something that does necessarily all the same things that version control does for code as something that mimics the ease of use version control offers for collaborating on code.
well IMHO the branching/merging of git is what makes it easy to collaborate on code.
After some discussion about this in #opensourcemusicians I was pointed to https://splice.com/ and https://blend.io/ both of which I know little about and they seem closed source, but you might find them to be what you wish for.
Cheers. I’ve had a look at these earlier, and splice.com does seem to come fairly close, at least if you have a supported DAW.
I’ve had this idea before, although more at a global level for collaboration purposes, similar to splice and blend.io, but specifically for Open Source DAWs. The concept was to use some sort of uniform messaging capabilities (e.g. OSC or some other format). My initial stab at it got to the point of being able to send messages back and forth between a server and a command line client (basic telnet stuff to start with) and starting the task of fleshing out the message format (using OSC, though someone recently recommended the XMP format, which I haven’t looked at yet). The goal is to make clients that are actually patches to the Open Source DAWs (starting with Ardour and QTractor) and a server to store/send the messages and an attached website (something like github). Unfortunately, I don’t have time to code everything myself. If there are two or three other people who want to help me with it, I’m willing to resurrect the project and try working it as a team. If anyone is interested to see what I started with, they can check out https://notabug.org/jazzyeagle/OSM-Server and https://notabug.org/jazzyeagle/osm-client. Again, I didn’t get very far, but the concept is there.
One additional note: The concept was to store the messages (which would include the audio/midi data), NOT the individual files that the DAW would create. By storing the messages and creating patches that converted the messages into actions the individual DAWs could understand, we get away from the issues that QTractor may not be able to read Ardour files and vice versa (multiplied by how many other audio/midi programs ultimately want to get in on the idea). Unlike github, each message would be stored once per repo, and then each commit would basically be a list pointing to the various stored messages (similar concept to an array of pointers in C/C++) to build the song up to a certain point. A Merge Request would be the collection of additional messages to be added in, and the client would have to have some way of applying the updates on a temporary basis for the owner to listen to and either accept or reject the various changes.
the messages would include 8GB of audio data? (that’s possibly on the small side).
Any archive that is going to store the song would need the audio data (assuming, of course, that the song is not exclusively midi based), so if it’s 8GB in messages or 8GB in uncompressed audio files, it’s going to be 8GB regardless.
sure, no doubt. but a message protocol intended to handle multi-GB messages has to be very carefully designed; a message protocol that merely refers to multi-GB filesystem paths is much less complex to get right.