Save a a new version vs Save as a new file

Hi all,

I’m wondeting if there is a massive difference between saving “as a new version” and saving by renaming the file (for example, saving a new file each day with that day’s date, containing the latest edits)?mI’ve always used the second method, and I’m wondering if I’m the only one who does it this way.

Do you also rename the .csh file too? Renaming by hand was never a problem in my ewperience, but you need to keep .cpr/.npr and .csh names consistent. If you don’t use DOP, i think you don’t even have to worry.

I’ve used to do that, too, but stopped at some point. Using “save new version” is just quicker, and that is what it is, a shortcut for us lazy people :smile:

My take on the original question: While I use save as a new version a few times in the course of most of my projects, I copy the CPR file after saving multiple times a day.

Why?

The save as a new version increments a version number, but is pretty (totally?) meaningless for describing what was changed at that version.

On the other hand, if I copy and rename the CPR file, I can name each copy meaningfully. For example, one might be “-, track BGVs, Ch1.CPR” and another might be “-, comp BGVs, Ch1.CPR”.

Now, using the specific example I included in the renaming case, somewhere down the line – maybe I’m at the point of working on a rough mix – I find that there are some strange artifacts in the first chorus’ background vocals that something I’m doing at the current stage of the project has made more prominent. If it’s not the sort of thing that I could address with RX, I may want to figure where along the line the problem was introduced, and the meaningful CPR file names can fairly quickly lead me to options. For example, if I find it was there since the comping of the background vocals, I may want to go look at the raw takes from tracking to see if I can fix it by comping differently, and I can possibly do this by importing the relevant track(s) from that version of the project, make the relevant changes and move the results from the imported track(s) to the current track(s) in the right location. If, on the other hand, I’d just been using automatically generated version numbers, how do I know which numerical version was were I tracked the BGVs and which was where I comped them?

This sort of thing has saved me a number of times in cases like this example, as well as editing mistakes I don’t notice early enough, and various other real-life scenarios.

As for the save as a new version, I tend to use that at some major milestones, where I’m planning to do some significant changes afterward, especially if I’m getting experimental, where it may be that I want to entirely ditch where I’ve gone from the point of having created that new version. I’m not sure that I ever have actually used that in a practical sense, though.

1 Like

Is that the only difference? No other benefits apart from time saving?

Hi,

Nope, the new .csh files are created when renaming and saving the .cpr file. I find “saving as a new file” a better workflow since it allows me to include dates, making it easier to locate specific sessions when needed.

Apart from “Save as a new file” I use a similar workflow, but I keep track of my daily edits in a separate Word document. It would be great to use the Notepad for that, but apparently, allowing users to adjust the character size is too much of a challenge for Steinberg to implement :wink:

I don’t actually use the “save as a new file” command. I just do the renaming in Windows’ File Manager.

I don’t want to have to look inside the file to see the version-type “comments”, which is why I like to do this at the file name level. That can be quickly seen without needing to open the Cubase project.

Well, in my book, time saving is a pretty good argument :wink: I can’t be bothered to have to type in a different file name each time I want to save a new version.
But yeah, that is the only difference.