Give users ability to define auto-save location

Nuendo
1

I find myself regularly loading the most recent version of projects, whether that be from the .npr or the .bak file, thus I have all saves and auto-saves in the main folder where I sort them by creation date or modification date and can quickly see & load the most recently saved file.

With the forced implementation of the Auto-Save folder doing that became both awkward and slow because I now have to go between two folders checking the save times of .npr or .bak’s. For me it has introduced an awkwardness, extra work, and a degree of frustration.

In the Nuendo (and Cubase) Preferences panel, under General, please add the option to set the auto-save folder location manually, or in your default Auto-Save folder.

2

Hi,
nothing wrong with your FR, just one question:
What about saving your cpr/npr in your Auto Save folder? “Save As” asks you for a dedicated location so why not the other way round?

1 Like
3

It’s not what I want to be doing with > 20 years of projects that I still use, just to get around the issue Steinberg has introduced as that would cause more issues with the folders of older projects.

I sincerely would rather the ability to set the auto-save folder myself rather than stop using both Nuendo & Cubase 14 being forced back to earlier versions just to keep my hundreds of projects folders as I already arrange them.

I certainly don’t expect it will happen, and I already move auto-saves to the main folder where I want them in projects created in N14 & C14, but I just wanted to ask :slightly_smiling_face:

1 Like
4

This wasn’t imposed by Steinberg – countless users were annoyed that the automatic saves were going into the same folder as the project. They didn’t want to see these files. Steinberg has simply finally responded to all users.

4 Likes
5

Why keep each and every .bak file?

Once I close a project for the day or session, I back it up to the cloud and locally and then delete the folder.

6

Your irrelevant comment is actually also wrong. This change WAS imposed by Steinberg. They implemented this change without giving users the option NOT To do it that way - which is what it means to impose something. The fact the change was imposed on all users based on user feedback or request shows Steinberg will consider changes based on requests :person_shrugging:

7

Why keep each and every .bak file: Yes, there are reasons for doing this.
It’s great you established a system you are happy with, that’s excellent :slight_smile:

8

I too certainly doubt Steinberg would implement a feature where the immediate consequence would be the deletion and overwriting of other project backup files (e.g. “Untitled1-XX”) , as well as inconsistent and arbitrary versioning of bak files where a user decided to pool all backup files from all projects into a single folder. If you had Untitled1-01 through Untitled1-20 from Project A in this “pooled” folder and created a single backup from a new Untitled1 Project B, its bak would be Untitled1-21, and depending on backup file retention settings, it could delete a entire swath of Project A’s backups. Just one change in that parameter could obliterate untold numbers of backups.

Your existing process of organizing your baks sounds like a far better solution to me.

9

Many professionals save their projects as versions.
Example for customer C22418:
C22418_2025-12-25.npr
C22418_2025-12-26.npr
or
C22418-a.npr
C22418-b.npr

This makes the *.bak files completely unnecessary. You only really need the *.bak files if Nuendo crashes unexpectedly. You’re using the wrong approach entirely. Don’t make your incorrect way of working the norm.
(We perform daily versioned backups.)

*.bak files are only “rescue files” after a crash.
The *.bak files date back to the early days of UNIX. They were rescue files for emergencies and were never intended for versioning.

How you use these files is not in accordance with the inventor’s intention.

2 Likes
10

Irrespective of when a feature was introduced, the current iteration is designed to create versioned bak files. They are not just “intended” for that purpose, but explicitly coded to provide versions through time.

He’s using a “different” approach. On macOS, bak files are not deleted upon “save” or “save as,” and they only clean-up based on timing/versioning parameters set by the user. They persist through time as automatic, versioned backups. There is absolutely nothing wrong with choosing to take a production dependancy on a programatic process.

Just because another person’s method is “different” doesn’t make it “wrong.” Between my 2 studio rigs, Nuendo has crashed one time in two years. 1 time between 2 systems. I keep my versioned bak files through time as a normal part of project and file maintenance, and for me, it’s a part of my workflow.

I see you keep coming back and editing your responses without any attribution to what you’ve actually changed, so I’ll just leave it at saying that if “the inventor” didn’t want them used as versioned automatically saved files, they wouldn’t provide the user with versioned backups, and they wouldn’t have provided explicit configuration parameters to keep X versions, and they wouldn’t have named them “Auto Save.” If you are suggesting that “the inventors” expect Nuendo to crash every 4 minutes thus necessitating requirements for multiple iterations of “emergency backups” through these persistent crashes, then I respectfully submit that you are mistaken.

11

This is a historically based protection against file corruption. In early Cubase/Nuendo versions (SX era, early Nuendo generations):
Project files were monolithic XML-like structures.
A crash during saving could:

  • render the current project file unusable without any possibility of recovery.
    The *.bak file was then often the only way to recover the data.

The *.bak file is not a version control system, but a last resort.

Anyone using it for version control misunderstands its purpose both technically and conceptually.

The *.bak file dates back to a time:

  • before auto-save
  • before backup folders
  • before stable file systems

The *.bak file is useful as a last resort, but should not be confused with or used for a versioning strategy.

(I often correct it because I sometimes translated it poorly from German.)

12

For me, it’s an integral part of my otherwise effective file maintenance. What it started off as 30 years ago really has nothing to do with what it’s used for today. I can confidently say that I’m well aware of the full scope of operations within my studio, and that I’m not “confusing” anything, nor am I “misunderstanding” any use-case.

Incorrect. Anyone using for it version control has chosen to use auto-save files as just one method by which to approach an overall strategy of production file maintenance and project management. It’s not mutually exclusive at all.

Using it as the ONLY method of versioning wouldn’t be optimal of course, but you seem to be the only person imposing that logical restriction here. And you’re not arguing with users here, you’re arguing against “the inventor.” Nuendo creates versioned autosave files, which you are choosing to ignore the significance of. That’s really all one needs to look at to prove the use case extends beyond “last resort.”

Of course, you are free to do whatever it is you choose to do, just like other people are free to make their own choices. But in my opinion, you condemning any other possible use case as “wrong” while also impugning others’ capacity for understanding while casting them in a rather insulting light seems inappropriate. But you do you.

1 Like
13

Mixing engineers and musicians shaped the sound of music time and time again by NOT stricking to manuals. Instead, they did whatever it took to get to the sound they wanted. By accident or on purpose.

If we were all stickler to the rules we wouldn’t have tape delay, all sorts of saturation, fat drum sounds by placing mics the wrong way - you name it… Following that line of argument, the usage of bak files as an additional means of backup or documentation shouldn’t pose an existential thread to anyone.

Just a thought :blush:

1 Like
14

This is was Google says:
Nuendo’s .bak files are automatic project backups, crucial for disaster recovery after crashes, created in your project folder with a Name.bak format, and can be opened like regular projects (often offering to open the most recent one after a crash) by selecting them in the File > Open dialog, allowing you to recover recent unsaved work, with settings for frequency and quantity adjustable in Preferences

It bothers me that someone insists on having these *.bak files in the project path – even though many have insisted on saving them in a subfolder.
*.bak files are not intended for frequent opening and use. They are files for a usually rare emergency.
For example, if something was accidentally deleted and it can’t be undone.

But someone here is apparently opening *.bak files around the clock. So often, in fact, that it’s impossible for them to access the “Auto Saves” subfolder. And that’s not usual.

Therefore, it is only logical that these files are now in a subfolder. What also bothers me here is the claim that Steinberg “forced” the subfolder. It was logical and consistent.

15

I agree with this, and said as much. I personaly don’t see any reality where NOT having the project-based auto-saves in a project-specific folder makes any sense. Particularly since this is a global, structural design choice that impacts file-naming and could potentially destroy other project data.

Agreed again.

And yet again. My pushback was that the “only correct way” to use auto-saves was in response to some catastrophic event, crash, or failure - and that any other use was “wrong.” I don’t try and tell people what to do, but rather, give examples of why I choose to include certain processes into my workflows.

Part of the auto-save functionality is to also include the “last event that triggered a project change” in the filename itself. By way of example:

PianoSequence-122325-02-(Set Tempo Tempo).bak
PianoSequence-122325-03-(Add Track Track MIDI 01).bak
PianoSequence-122325-04-(Record Track Omnisphere 01 - O).bak

Depending on what I’m doing, Nuendo’s “undo” is limited for me. If you are in HALion and have captured just the right modulation for a patch, and mistakenly change something, you can’t always “undo” that. Limitations in undo history in general have bitten me multiple times. But that’s just an example - “insert your issue here.”

I have taken a real-world dependency on the availability of multiple, versioned auto-saves through time, including “event that triggered auto-save change” notations as part of my workflow. It absolutely works for me, and I use it time and time again as just one part of a greater strategy to save time and recover from when I do something silly or just make a mistake. I can just open these files and (hopefully) recover from #StudioLife issues.

The only reason I replied was to simply state that “just because people use a feature differently doesn’t mean it’s wrong.” Yes, in the case of the OP/Contributors, I don’t agree on the basic premise for the FR. But I also don’t think it’s right to just discount a process out-of-hand because of how something may have been originally designed decades ago, or because other people may use it differently. For me, it’s not “last resort,” it’s not “for emergencies only,” and it’s not “wrong.” And my choice in using them in a way that has proven absolutely valid time and time again doesn’t mean that I’m challenged in my ability to understand or conceptualize. That’s all I was on about. :slight_smile:

1 Like
16

Thank you. I agree with you completely.

We are working on large archiving projects (State / municipal / private archives ) of analog audio recordings that we are digitizing.
We have many projects with 500 GB (and more) of audio data and a timeline spanning many days. For example, when 100 tapes were recorded consecutively. Nuendo can do all of that absolutely perfectly.
We are consistently documenting and versioning the process so that we can easily revert to intermediate stages.
And daily double backups to NAS.
But we also do our own private music projects.

In fact, we need *.bak files once a month because Nuendo suddenly crashes and creates empty 0-bit files.
But what you’re saying makes perfect sense, because undo doesn’t always undo everything. It is designed for these cases.

2 Likes
17

With V14, .bak files are now named in such a way as to encourage versioning.

If I were to use those files, in this way, I would use network caching, in order to back them up and having a designated folder only supports this approach.

18

Not to be rude to any contributors here, but I have not and will not read any comments since my last one so please do feel free to say whatever you wish knowing I haven’t and won’t be reading it :slight_smile:
My little feature request stands - I would like the ability to have my auto-saves placed into the main project folder as they used to be. Thank you to Steinberg for whatever consideration you might give to my request :folded_hands:
To all the people that have added comments (which I have not read), wishing you a Happy New Years for 2026 and much fulfilment and happiness :partying_face:

19

Then it’s too bad you won’t see this reply where I was going to show you how to create a scripted service to automatically do this for you in the background upon creation of the .bak file (depending on your OS).

I suppose that’s the consequence of immature approaches to communication, though. You literally could have had this working today. Oh well. I’d say “good luck” but you’re not reading this.

2 Likes