There’s a difference between a bug and a flaw. A flaw is intentionally wrong. Recently I used Backup to transfer my “song” to another computer. To my horror, “Backup” does not do this. I had many files “missing”, These files turned out to be in my User section and not with my song files. Apparently if I forget to bounce samples which I had edited, the samples are not contained in my backup. Why? Also, when I duplicate a sample, it’s does not really duplicate and I have to bounce which I am constantly doing. If you forget to bounce, there could be trouble. The reason why duplicating does not bounce leads back to the old days when hard drive space was very expensive. Not now. Even if I bounce, it means an extra keystroke constantly which adds up to thousands of keystrokes I don’t want to do. It complicates my my life a lot. Let’s rethink this. I need to make a macro which includes Duplicate and Bounce with a single keystroke. I can do this but I’m just fixing a flaw which should not be there!
Steingberg needs to have a team spend a couple of weeks and painstakingly go over everything that could possible go into a project and make the backup do the right thing.
They also need to revisit the library manager and make sure that Cubase really gets all of it’s location data from the LM and doesn’t save any library file locations of it’s own.
What would be even better is if the LM could manage where files get stored as well, so you can see it all in one place. Anyway, sorry you are dealing with this.
I know the pain.
I’m not sure about how Cubase works, but in Nuendo at least it’s pretty clear that a simple “backup” will back up some of what’s in the project folder. If something isn’t in there it won’t get backed up. In order to make sure what’s needed is in that folder there’s “Prepare Archive”. So prepare archive first, then backup.
That should probably be optional. I wouldn’t want duplicate events to lead to duplicate files.
On the one hand, I feel users ideally shouldn’t have to think about such stuff, but on the other hand, I’ve always created a folder for each new project, then immediately saved the project file (.cpr) into the same folder, and never had such problems. If audio files or samples get added to a project (as opposed to being recorded in the project), I do that using the Pool and always choose the option to copy the file to the project folder.
I don’t entirely disagree. I think it’s likely that the way it functions is a bit of an inherited view on things where this sort of stuff fall under the headline of “engineering” which implies users ‘should’ be aware of it, because, well, they’re effectively “engineers” at that point. It’s all logical, just not intuitive.
I agree with the engineering mindset in that users shouldn’t expect everything to be done for them so they never have to think about things like this.
I agree with the user mindset that ‘why should I have to worry about this if there’s an easier solution?’…
Absolutely agree … I wouldn’t have developed my workflow unless I’d been there from the start and aware I needed to watch out for such things.
In that respect …
… I’d have to agree, but this does appear to be happening over recent versions, though perhaps not with high priority.
Agree 100%, but that sort of thing doesn’t go down well anymore 
– it’s somewhere in the corner with having the audacity to suggest someone should read the instructions for that incredibly complex piece of equipment they’ve just purchased.
… and there lies the solution, if Steinberg can figure out how.