Nobody wants to see this error message from their DAW, but with Reaper, at least you can attempt a graceful recovery.
Cockos Reaper has some interesting tricks up its sleeve to help you resuscitate seemingly corrupt projects.
For me, Reaper has always been extremely reliable — more so, in fact, than various other sequencers I’ve used over the last 20 years. Yes, I’ve experienced the odd few crashes in my time but, invariably, reloading the same Reaper project got me up and running again in a matter of seconds, leading me to believe that the problem was more likely to be a third-party plug-in than Reaper itself. However, I recently completed and saved the final revision of a song only to find the next morning that this project crashed Reaper every time I attempted to reload it. Yes, I had recent automatic backups of the song but, weirdly, they crashed Reaper too. The most recent version I could successfully load into Reaper was some two days old, and I was loath to abandon two days’ worth of mix tweaks.
However, with a little background research, a few hunches and a couple of new techniques I was able to get my most recent version of a Reaper project — in other words, one of the ‘broken’ ones — up and running again with no loss of data, as well as modify my future projects so that such crashes would hopefully never happen again. Here’s how I did it.
The Recovery Position
This tick box is the secret to being able to open Reaper projects that otherwise crash.The big secret to encouraging Reaper to load apparently broken project files is to use its built-in recovery mode. Few users seem to know of the existence of this feature, yet it can be an absolute lifesaver. To recover a project in this way, launch Reaper, either using the ‘Reaper (create new project)’ option that many users should find as a launch option, or simply hold down your Shift key before clicking on the Reaper icon, to start with a blank canvas. Once Reaper is up on screen, you can use its normal ‘Open project’ option, but when the file-select dialogue opens, tick the box labelled ‘Open with FX offline (recovery mode)’, or if you prefer to choose from your Recent projects list, do so with the Shift+Ctrl keys held down (Shift+Command on Mac). Simple as that!
The chances are that your defunct project will now load perfectly, but with all its plug-ins and instruments offline and therefore inactive. You can now re-save your project with an updated name, safe in the knowledge that every track containing audio and MIDI recordings, along with all your carefully entered automation passes, are safe. Phew!
Interrogating The Suspects
When you have reloaded your faulty project using recovery mode, its plug-ins will all be offline, but you can re-enable them one by one to track down the culprit.Now’s the time to do some detective work, by selectively re-enabling those plug-ins you consider totally reliable. Just right-click on each of your plug-ins in turn and you’ll see that ‘Offline FX’ is currently ticked. You can just click this option to re-enable it, although a much faster way to re-enable plug-ins is using the Ctrl+Shift-click shortcut (Command+Shift-click for Mac).
If you suspect a particular plug-in of being dodgy, leave it offline, and when you’ve re-enabled all the ones you consider ‘safe’, re-save your project with another updated name. Then exit Reaper, relaunch it and check that this modified project loads correctly. Once you’ve ruled out the commonly used ones, the culprit is most likely to be one of the few that are left.
Guilty Parties
So, which are the most likely suspects? A good rule of thumb is to be suspicious of any plug-in used only in this project, and not in any of your others. You may also have suspicions about some well-loved yet positively ancient plug-in that hasn’t been updated for years, and if this proves to be the guilty party, the quickest solution is to track down a substitute.
However, the most likely crash candidates tend to be more complex plug-ins, such as open-ended environments that let you build your own synths or effects from basic building blocks (for example, items built with SynthEdit, Reaktor, or Max/DSP), or those that load in large amounts of sample data, such as soft samplers or convolution-based plug-ins that load in large impulse response files. Sometimes it may be a particularly large sample library that tips the balance, or a missing impulse file that causes a particular convolution reverb plug-in to fall over.
Due Process
Selecting one of these options for a particular plug-in can prevent it ever crashing Reaper again when you use it for future projects.Well, so far we’ve managed to restore our previously crashing project, and hopefully identified a single guilty plug-in that caused that crash. Thankfully, as with most things in Reaper, there are further options available that may let us carry on running any dodgy plug-ins without running the risk of any future crashes. You can view these by launching the Add FX dialogue and then right-clicking (Ctrl-click on the Mac) on any plug-in in your list.
In the drop-down window that appears, you’ll see an entry labelled ‘Run as’, with four main sub-entries: ‘Default (set in Prefs/VST)’, ‘Separate process’, ‘Dedicated process’ and ‘Native only’. The simplest approach is ‘Native only’ mode, which opens plug-ins and lets them all share RAM with Reaper itself. Things get slightly more complex if you have both 32- and 64- bit plug-ins, and this is where the ‘Default (set in Prefs/VST)’ option comes in useful. For example, on my 64-bit PC running 64-bit Reaper this default was already automatically set in my Preferences/Plug-in compatibility page to ‘Automatic bridging (when required)’, so that 64-bit plug-ins run in their Native mode, and my few old faithful 32-bit plug-ins get bridged so they can also run inside 64-bit Reaper.
However, it’s the two other options that particularly interest us here. If you choose ‘Separate process’ for specified plug-ins, they will all run in one other process distinct from Reaper, all sharing the same but separate pool of RAM. If, on the other hand, you choose the ‘Dedicated process’ option for a particular plug-in, it will run in an entirely separate process from Reaper and all the other plug-ins, using its own personal RAM allowance.
Thankfully, we don’t need to get too bogged down in terminology here. The bottom line is that, in Native mode, if a plug-in crashes Reaper will crash as well. However, if you shift some plug-ins to run as a ‘Separate process’, then any time one of them fails Reaper will carry on regardless; you can still save and reload your project, but all the separate plug-ins will fail. Finally, if any plug-in crashes when running as a ‘Dedicated process’, only that plug-in will fail, while any other plug-in that’s using its own dedicated process, as well as any running on the ‘Separate process’ and Reaper itself, will remain intact.
Dedicated To You
Even better, you can choose the most appropriate process option for a particular plug-in and have that as the default for all future usage, to minimise the risk of any future crashes. You can do this from inside any Reaper project, as follows. First, Insert a new track, click on its FX button to launch the Add FX dialogue window, then right-click on the name of the plug-in that’s previously caused a problem. Then, in the list of Run As options, select ‘Separate process’ or ‘Dedicated process’ as required. Finally, you can click on Cancel and exit Reaper without saving anything. The next time you launch it, your process selection for that plug-in will be remembered and used as a global setting.
The easiest approach, a once-only exercise that took me a few minutes, is to set complex sample-based plug-ins to ‘Dedicated process’. I ended up doing this for Audio Ease Altiverb, the Best Service Engine, Camel Audio Alchemy, NI Kontakt, and Spectrasonics Omnisphere, among others. These plug-ins aren’t particularly prone to crashing but can sometimes require huge amounts of RAM, so it makes sense to give them special treatment. Any ancient plug-ins that you nevertheless still love are also best set to ‘Separate process’.
The only slight annoyance of switching to Separate or Dedicated processes is that, as with any bridged plug-ins you have in your list (either 64-bit ones running under 32-bit Reaper, or more likely older 32-bit ones running inside 64-bit Reaper), your plug-in GUI will appear in a separate window from the main effects window. Thankfully, there’s even an option to combat this: beneath the various ‘Run as’ options mentioned earlier is one labelled ‘Embed bridged UI (may not work with all plug-ins, less crash-resilient)’. Clicking that for a particular plug-in and exiting Reaper as before will remember this setting.
This final option isn’t perfect. With the huge third-party Reaktor ensemble that had initially caused my problem, for instance, I experienced no further crashes, but if I switched to a different application, my Reaktor GUI was visually corrupted when I switched back to Reaper. It’s nevertheless useful, if only to get the standard drop-down preset list into the same GUI as the plug-in itself. So if, like me, you want to force all your old 32-bit plug-ins to appear in the Add FX window just like the 64-bit ones, click on ‘All Plug-ins’ in Reaper’s Add FX window and enter ‘x86’ into the filter list to display the complete list of 32-bit bridged items installed on your system, so you can individually set them to the ‘Embed...’ mode. Clever, huh?
