Recovering from RPP-BAK terrible Save As behaviour

[ferropop]

After a crash, here's what happens when recovering from a RPP-BAK file.

1. Open the rpp-bak file Song.rpp-bak

2. Great, now we want this to replace Song.rpp as this is the whole point

3. These are the default options when saving :



Now I ask -- in what situation would you possibly want to Create Subdirectory For Project? Maybe in some corner case, but in 99.999% of situations you're just trying to replace the main project with its most recent pre-crash version as it will have a more recent timestamp.

This so commonly leads to a complete duplication of the original project, INSIDE the project folder, creating a complete mess of nested stuff.

It's a terrible default that should be disabled automatically by Reaper if it detects you are working on a RPP-BAK file.

...to make matters worse, let me uncheck Create Subdirectory and proceed with overwriting the original (as 99% of the time will be the case)...

Now, when opening/creating a new project Create Subdirectory is UNCHECKED!!! So now you're accidentally NOT creating a subdirectory for a new project, accidentally saving everything as a mess to the root of your projects folder.

It's unintelligently just remembering whatever the last used setting was.



I would propose the Default to ALWAYS CHECKED "Create Subdirectory" with new projects, and default ALWAYS UNCHECKED "Create Subdirectory" when in a RPP-BAK file.

This happens accidentally too often to count, and it's just finnicky and unclean and potentially disastrous default behaviour currently.

[ferropop]

Maybe the way to address this is making that setting Project-specific, and having the default flag set by certain conditions.

1. New project, "Create subdirectory" is checked.
2. Already saved project, "Create subdirectory" is UNchecked as you want to keep everything inside the already-created structure and are usually just saving an Alternate Version of the project to the same folder
3. RPP-bak file, "Create subdirectory" is UNchecked as you're usually just replacing the RPP to the same folder, not trying to uselessly/disastrously create a nested duplicate inside the project folder.

[Fergler]

I'm the guy that's the complete opposite that that default is made for, I guess. I rarely turn it off and I get tripped up when I forget to.

[ferropop]

Originally Posted by Fergler

I'm the guy that's the complete opposite that that default is made for, I guess. I rarely turn it off and I get tripped up when I forget to.

Fergler so you agree with the defaults, or with what I'm proposing?

I find it hard to imagine a scenario where you're opening a RPP-BAK (either because of a crash or reverting to an older version) and wanting to then create a nested folder inside the original project folder, and duplicate all the media to this nested folder.

And in a strange situation where this is what you want, as a one-off, check the box.

But by default this is so so so odd.

[vitalker]

Originally Posted by Fergler

I'm the guy that's the complete opposite that that default is made for, I guess. I rarely turn it off and I get tripped up when I forget to.

ferropop is writing about defaults for BAK projects, not normal ones.

[ferropop]

I know like this feels like such a minor thing, but it's legitimately disruptive.

Reaper is my main daw since 2009 and I still stumble with this regularly, it's just in one of those pesky spots where it's so incredibly easy to just hit Save without carefully checking those boxes.

The boxes create some pretty undesirable behaviour if set incorrectly. Just making a case for setting people on a safe path to their intentions, and minimize doing things that are relatively disruptive like creating folders, duplicating media (which media folder do i delete, which do I keep? etc)...

[Justin]

The default settings for the save-as window are chosen based on whether the current project is set.. it only defaults to those settings because you had it set that way the last time you saved a new project from scratch. So yeah I suppose we could keep track of whether a rpp-bak file was loaded and use a different setting based on that, but meh.

[ferropop]

Originally Posted by Justin

The default settings for the save-as window are chosen based on whether the current project is set.. it only defaults to those settings because you had it set that way the last time you saved a new project from scratch. So yeah I suppose we could keep track of whether a rpp-bak file was loaded and use a different setting based on that, but meh.

IMO any ironing out of quirks (especially ones that still regularly hang up a user of 12+ years) can't be a bad thing. This might just be a me problem, but I suspect it's in the pile of "got burnt but learned to live with it" for many other users also.

With every piece of software, users have to keep an internal list of "oh don't do that; don't forget that little weird behaviour; under no circumstances ever do THAT cause it'll crash", and it's a background process running in our minds at all times that become part of normal use. Any reduction in this list is worthwhile I'd argue, but yeah just thought I'd bring it up and lay it out like this if there's any interest in refining it.

[foxAsteria]

Originally Posted by Justin

but meh.

I also think it's a legitimate issue. I've developed habits to get around it, but opening a backup should never default to creating a subfolder. It's an option I use exactly once per project, when titling it for the first time and thus giving it its own project folder.

Why it's an issue: While I'm working I use file iterations (using the built in auto-increment action) so I have a clear version history in the project folder just by opening it, and sorted by date, the latest version is at the top...

...BUT(!) if the project ever crashed and I didn't remember to uncheck the box, now all future iterations ended up in a subfolder, which is yet another thing I must remember to look for when opening the project or I risk accidentally working from an old version. Not to mention all the redundant data.

I agree with OP, it's a default that is far more likely to cause problems than anything else.

[Fergler]

Ok I missed that this was about -baks only. So for me, I didn't even realise til now you can open a .rpp-bak. Guess it has never been set to open in Reaper. I've just been renaming them to .rpp and removing the crashed version, all outside of Reaper.

[ferropop]

I'll throw this out there - it just happened to me again.

When a project crashes we're generally in a panicked state because a trillion data loss scenarios run through our heads, and maybe there are deadlines or people's projects riding on your work. It's sort of a frantic moment where these little details really do matter.

This just leaves open the scenario of creating a worse mess at a terrible time. Hope you consider it, thank you.

[thommazk]

+1 As I feel the same.

It's a small thing in the end but it makes more sense in terms of coherence of what to expect from a backup file.

[ferropop]

Happened again

[norbury brook]

Originally Posted by Fergler

Ok I missed that this was about -baks only. So for me, I didn't even realise til now you can open a .rpp-bak. Guess it has never been set to open in Reaper. I've just been renaming them to .rpp and removing the crashed version, all outside of Reaper.

and that highlights another issue for people. You have to either show 'All file types or *.baks in the explorer otherwise by default it won't 'see' them to even open after a crash



M

[ferropop]

I'll be the bad guy and say it - the "meh" from Justin is just disappointing and kinda surprising on such an otherwise tightly-kept ship.

Fair enough, we're in the nitpick forum. It's the scenario where this nitpick occurs that (to anyone who has encountered it) escalates it to a real issue. When you're panicked (your project just crashed!), you are not behaving carefully or logically, and this can cause an incredible mess without the guard-rail guiding you towards recovery.

It's a simple set of situations to check for honestly, I hope it gets a second look.

1. If you started a fresh project, have the "Create Folder and Copy Media" checkboxes on first save.
2. If you opened an existing project and Save As, have Create Folder unchecked and Copy Media checked
3. If you opened an rppbak, have Create Folder unchecked and Copy Media checked (just in case)

[foxAsteria]

Hmm I'm not sure "copy" should ever be automatically checked.

On a fresh project I always use 'move,' and I only use 'copy' when I actually want a copy of the project for sharing or whatnot.

Not that we're getting any traction on this but I think the only default changes should be concerning subfolders.

In my experience, noobs rarely look at those options and e.g. in a lot of my sister's projects, each new version is inside a folder inside a the old version's folder. So a with a long-standing project, the newest version is nested dozens of folders deep for no reason other than Reaper ill-advisedly suggested it.

[ferropop]

Originally Posted by foxAsteria

Hmm I'm not sure "copy" should ever be automatically checked.

On a fresh project I always use 'move,' and I only use 'copy' when I actually want a copy of the project for sharing or whatnot.

Not that we're getting any traction on this but I think the only default changes should be concerning subfolders.

In my experience, noobs rarely look at those options and e.g. in a lot of my sister's projects, each new version is inside a folder inside a the old version's folder. So a with a long-standing project, the newest version is nested dozens of folders deep for no reason other than Reaper ill-advisedly suggested it.

Totally fair, I chose Copy as the default always because it minimizes risk of things not "coming along for the ride".

For example, what happens if you open a Rppbak not for crash reasons, but because you want to revert to yesterday's version. Should you choose Move and create a new folder options on save, do those files that belong to today's project get ripped out of the original folder and put into the new one - breaking the old project?

...just another example of how fragile all of this is.

[ferropop]

The temp media folder in Reaper suffers from similar potential for data loss.

ie, start a new project start doing stuff, pulling in samples, rendering things...

If before doing the first save you pull something from the project into a sampler, you're actually pulling it in from the temp folder because it hasn't yet been copied to your project folder! So even after you save, the sampler is referencing something in the temp folder, forever, without any indication!

It's why I've let the temp folder grow to a massive heap of 99.999% useless stuff, with the off chance that a sampler is referencing something that didn't get copied to the project folder.

And yes, this happens all the time. Best practice of course is to immediately save your project when you start, but of course at the start of a session you don't even know what you're about to make, let alone knowing what to call it.

[ferropop]

Found this in the wild. It's what happens when this behaviour is left unchecked :



4 levels of nested folders, and this dude most likely has no idea. If you wanted to fix this structure now, which is the correct folder?. Do you need to amalgamate all the nested folders? Are there necessary media items in some folders and not others? Running a Consolidate could create an even bigger mess if VST samplers are randomly referencing media scattered across the nested folders, as you think everything is centralized and then delete stuff etc etc etc.

My point is, it should be hard for the above to happen - let alone too easy.

Thanks!

[norbury brook]

I had a rare reaper crash yesterday and was confronted with this again.

I agree, it seems strange that opening a back up of your project behaves like you were starting a whole new project.



when you've opened a backup you should just be able to hit save and it saves as the last version you were working on when it crashed. I save incremental versions of projects when working and opening the latest backup does NOT remember that when saving.I have to manually name and number it and remember to uncheck all the media boxes so i don't get another nested folder.


M