I save project versions in Reaper also, which Reaper makes very easy to do. And I also use the Project Notes to document the changes I make along the way. I put in the time and date, and list the changes and additions I have made in that particular version. You can even set it so the notes pop up every time you open the project, and open the notes at any time with a key-combo. In that one note you have every version, date & time, and changes made (until you branch it). You can also set it up so that you can add notes directly in the individual tracks. Here's a video with examples.

 

Apple Logic :



Studio One 5:

 

my projects always end up like this
12 projectname 045-B-02 fixed hats after crash sdfalg4-newversion56

 

It's not hard to name new saves with something more descriptive than a number. Using numbers you would have to open them all to have any idea what's in them. I do this but I use something descriptive in the names. That's what is seen in the video above.

 

I actually do both sometimes. Always have the unique number, and then after it i might say what the difference is.. kinda like what waverider said, but my file looks something like:

Proj123.0045-fixed hats.rpp

All the project files are in a folder named like so:

Proj123 - (some quick description of what the song sounds like, to remember it easy)

Once I've completed a project, I rename the project folder with the name of my track, and drop it in a completed projects folder.

There's probably better ways to do it, but it is quick and easy for me. I can see why people would like a version control tool to use (my actual job is as a "computer programmer", so I use them all the time), but I also don't see why anyone can't just use Git or other versioning tools out there for this, if that's your fancy. They usually will allow just about any old file. There will be some size limits if you store on cloud. It might be nice to have a bit more features for comparing two projects together, but I think for most people you can manage that with comments.

I will say looks like Logic does it fairly well though, if I'm understanding @Moonlight 's screenshot right. Looks like you can pick a description of the version right from the menu and load an older version that way. Nice.

That all said, a version control software with music production is not for me. My workflow is probably different than those that want to use it though. I tend to progress pretty linearly with the versions.. rarely ever going back to an old one. So it works for me to just have automated backups, and the whole # + comment system I use. But what works for me doesn't work for everyone.

 

the advantage will really shine in collaborative projects , its a pain to work with other people on the same project workflow wise , especially for bigger projects with no clear roles , in addition I use my projects in a modular way , I take drums from one and add melody from another so using something like git would make my life easier

 

That actually makes a lot of sense (especially with my programmer background, where you almost always 'collaborate'.. I get it now). I almost never collaborate on music, so I never really thought of it from that angle. Maybe running your own Git server would work though?

 

I did think about doing something like this with FLPs for a long time. Basically, binary or text doesn't matter, the structure of the file should be understood to create what is called a "diff" i.e. a meaningful list of changes. In case of project files, they can be "added a pattern 'Hi Hats'", or "Removed track: Bassline".

For implementing this, we need 2 things - a simple no-BS version control system (VCS) and a parser. The VCS doesn't know the structure but it keeps a track of changes. The parser analyzes the project file and creates an accessible structure. Both working in tandem, can achieve versioning. In case of code, it is simple text, so no parser is required as such to convert the text into a more human readable form. One big problem, particularly is the every evolving and changing nature of the project file formats. For e.g. a project re-saved in a newer version of the DAW might have a lot of new information which isn't necessarily a change for the user. A parser must be sufficiently tested and stable to analyze such cases.

I remember older versions of LMMS were able to open a FL project. It was a converter in itself. However, Image Line keeps adding stuff to the FLP format so often, in ways that make the logic used for parsing older projects unusable for projects saved in newer versions. Unfortunately, on top of the already kind of broken support LMMS had, this caused it to permanently remove FL project support. Obviously, no DAW dev will want to completely document their format, as then any of their competitors can use that information to their advantage, and even steal ideas, maybe.

If anyone is interested in the internals of FLP format, you can check out PyFLP, a parser I created. It can read and save any changes you do, just like FL. I posted about it here some time ago. With some Python knowledge, you will be able to compare and find out differences between two files

 

Git will happily store and version binary files but it can only show differences for text-based formats. So you can use it but you would have to add extensive text notes about the changes when you commit a version. It would be fantastic if a DAW could list your versions and describe the differences but the only way that can happen atm is if a DAW manufacturer implements the functionality themselves or if, as above, someone reverse engineers the file formats and makes a specific tool, which is never going to be as convenient to use.

 

I think the idea is to show a history of the development, which to me as a producer is done through mixes. When comparing and deciding which you like better that is done by listening. You listen to the different mixes, not open the different version of the saved project to decide. Once you have decided THEN you go seek out that saved version. Comparing is NOT done by opening the saved project files. It's done by comapring mixes, so to ask for the history of the saved project files on a site misses the whole comparison idea. You compare mixes, make a decision, then go find the saved project file. Lots of wasted work and energy to show a history of saved project files. The mixes are easily compared and opening that saved project file comes after. The video shows comapring mixes on one page and a history of the mixes. THAT is what gets compared, and they represent the saved project versions. It is misguided to ask for a history of the saved project files on a page.

 

If that works for you, cool. I would skip the numbering. The descriptive names are what you are looking at. The number doesn't seem to be used for any real purpose, but if that's your method, fine. You could do away with the numbering and just use descriptive names and be fine. If it's just numbers, you have to try to remember what each number conatins. If you are trying to get an idea of what is in the saved version, I would think descriptive names do that much better than a number. THAT is why I stopped naming files by date early in my development. I found myself trying to remember what was done on that date. Same with the numbering. I'd be trying to remember what I did for that number. It's easy to do descriptive names.

 

@kooper The number is mainly there for ordering, for me, but also because I don't always want to have to come up some description of what's different. Number is always part of the name for me, a description is not. Like I said, I tend to work pretty linearly anyways, not needing to go backwards, so I usually only throw a description in there if there's some major change I might have to undo.

As a note, stuff can always be ordered by date, but sometimes stuff when shuffled around can lose that date too, that's why I personally like to number stuff. Unique, sortable, quick and easy, gets the job done for me... and then when needed (not too often), I tag on a little description.

Quick and easy, for me, but what works for you, works for you. We all have our ways that make sense

 

For Reaper users, this might be a thread/plugin to follow:
https://forum.cockos.com/showthread.php?t=262912

Heda mentions he's going to implement a bit of a version control. Obviously it isn't going to a full on version control, but more of a way of seeing/accessing different versions. For Reaper users, saving a project in a folder, and saving off versions in a somewhat manual way (easily done), this might come in handy, depending on how he goes about implementing things.

 

I thing Gobbler does versioning.

It's like a cloud service for audio collaborations.

 

Just found out Blend