Well, there actually is a convention when it comes to Cubase’s built-in version naming. With the exception of the first time you “save a new version”, it simply adds 1 to a two digit counter, of the form “ProjectName-NN.cpr”, so that “-NN” part makes it easy to see which version is newer. And, of course, the exception for the first time is that it adds “-01” in the “-NN” portion, so, for example the filename of the first new version of a project named “MyProject.cpr” would be “MyProject-01.cpr”. Thus, simplifying the idea to only handling Cubase’s new project version saves, and not intentional “Save As” saves, which could either imply a new version or just backing up to another name (or maybe something else I’m not thinking of), would simplify interpretation greatly. My reason for mentioning it was really meant just to see if some people use “Save As” in ways that might want to have this same feature suggestion be applied.
I don’t think that would be applicable in the case of just dealing with Cubase’s “Save a New Version” facility. At least since I’ve been using Cubase (only since 9.5 at all, and mostly since 10.5), the nomenclature has been consistent.
Even in the case of cleaning up an existing list, I think that, if the project is in the same folder and follows this convention on naming, enabling the option should be able to handle the Hub’s view of recent projects. There might, however, be the question of what happens if you now disable the preference. That is, should Cubase have saved the full list of recent projects but only displayed the newest version so that it could conceivably display the full list if the user changes their mind on preference? In that case, it might affect internal Cubase settings (probably in an XML file?). This consideration also might make it more challenging to clean up the list if, for example, deleting the newest file from the list did not clean up the older instances of that same project from the list. Personally, I’d be happy to have it keep the underlying list clean according to a user’s preferences – if the user actually wants to read older versions of a project, they can always use File/Open or File Manager (or Finder) to do so explicitly.
And, if the list is kept clean, and if an older version of Cubase is expected to be able to read versions of that list created in newer versions of Cubase (I have no idea on that front since I never tend to go backward once updating to a newer version), as long as the format is kept the same, the only thing that would change is the user gets a shorter file list after the file is opened in the newer version by a user who has the new preference set.
I’m not particularly fond of this option. I do sometimes have multiple projects with different names in the same project folder. The most typical example would be different milestones of the same project, where I copy, then rename, CPR folders from File Manager after milestones. (While I do use the “save as new version” command, too, I mostly use that for non-specific cases, where maybe I’m about to do something major that isn’t a milestone, so want to start fresh. And, of course, this also happens automatically when Cubase thinks it has some corruption.) For example, after tracking lead vocals, I’d do a copy of “project.cpr” (or “project-02.cpr”) as “project, track LdVocs.cpr” (or “project-02, track LdVocs.cpr”). I generally wouldn’t care about those being in the Hub’s list, of course, but there may be some cases, for example if I open that project specifically for some reason (e.g. to review settings, check on if some “user error” I made subsequently might be able to be rescued by grabbing something from that older instance, etc.) where there might be some value in its being in the Hub after I’ve accessed it for the first time via File Manager.
I think the feature request is the same functionally, but your suggestion could conceivably be an implementation alternative. Though both alternatives could have separate “side effect” considerations.
Hello everyone,
Bonjour tout le monde,
