REAPER Tutorial: How To Save A Project From A Bad Plug In

One of the risks of using virtual instruments and effects is that not all are created equal. You will run into compatibility problems with certain plug ins in certain hosts. I'm pretty much a VST/VSTi user, so I'll focus on those plug-in types, but the tricks I will suggest should work for any plug-in type.

I write this from experience. Recently, I've been working on a new version of an old song of mine, so I've spent a lot of time fiddling with VSTs trying to recapture the original sound and feel of the old song. And I will freely admit I have a lot more plug-ins than I have had time to fully test. This is the perfect scenario where BAD THINGS CAN, WILL, AND DID HAPPEN.

So What Happened?
Everything was fine when the last few times I worked on the song. Everything was running smoothly and I was making a lot of progress. Tonight, I loaded REAPER (and it auto-loaded the project), and instead of gracefully fading out from the splash window, REAPER crashed. I tried it again, it crashed again, but at a different part of the loading process. Third time's a charm, right? Wrong. Third time it loaded most of the way, the splash window got to the "Fading out" status message, and the entire computer froze. I had to resort to a hard reset (hold down the power button until it forces a shutdown). For the sake of full disclosure, I went through this same process (including the forced reboot!) TWICE before I decided I was being stupid.

Option 1: Go To A Backup
REAPER keeps backup copies of the last time you saved the project, so all is not lost. Find the file in the same directory as your project that has the same file name with a .RPP-bak extension. This is the backup made of the next-to-last saved version of your project. Rename it to something with an .RPP extension, and try loading it. If you're lucky, the bad plug in was not included in this version. More likely, it is still in there, and you crash again. If it doesn't crash, you are left with the problem of losing any changes you made since that save. Not ideal, but if the changes are minimal, this might be a viable option.

Option 2: Disable Suspect VSTs
If you have a pretty good idea of what new VST you added before the project went south, you can disable the suspect VST in one of two ways. One: Find the .dll file for that VST and rename it with a different file extension, like .dll_disabled. Two: Move the entire VST out of the path that REAPER looks at. This can be a good idea if you know exactly what you've been playing with, and can isolate the one "problem child".

Option 3: Kill Em All
In my situation, I had been working with so many VSTs, I had no clue what was in and was not in my project. So I instead renamed my root VST folder to another name, so REAPER wouldn't find any of my VSTs. When REAPER loads, it will not find any VSTs under the path it is looking at, so it will present you with a clear list of all plug ins it couldn't find. Copy down this list. Rename your VST folder back to its original name. Now you can try the same steps I outlined in "Option 2: Disable Suspect VSTs", since you now know every VST in your project. I can almost guarantee one of them doesn't play nicely. Move one out (or rename the .dll), try it. If the project works fine, then keep that VST separate/out of your toolkit. Newer versions of REAPER might work with it, so I'd recommend having a "doesn't work with REAPER yet" folder to drop all of these into.

Safe At Last
In an ideal world all VSTs would work with all hosts. I've never been "under the hood" on a VST host before, so I'm really not sure why some plug-ins are stable in one program and totally corrupt in others. But the fact remains that this is a reality. Since there are so many free/cheap VSTs out there, I know I don't really have too much to complain about if one doesn't work correctly in my DAW. For just about any type of plug in you want, you can probably find dozens of others out there that might work better.

If You Like Testing...
If you're the type of person that likes to have all the bugs worked out before you start, then you should test each and every plug in before you put it in your "real" toolkit. I have seen plug ins that crash on saving the project, crash on loading the project, crash on loading the plug in itself, as well as aberrant behavior when twiddling knobs in their UI, and even the occasional situation where using the same plug in multiple times in the same project will cause a meltdown. Frankly, there are so many parameters, I can't even imagine how rigorous the testing should be to declare a plug in "stable".

If You'd Rather Live on the Edge...
I'd rather spend my time playing than testing, so most of my "uh-oh" crashes come during real projects. So if you're like me, you'll need to get used to recovering quickly from a total project collapse. Once you step back, take a deep breath, and look for the unruly plug in, things will sort themselves out pretty quickly. I have also seen quite a few references in the forums to "pro grade" (i.e. expensive) plug ins that are also temperamental and will crash out your DAW, so the problem is definitely not just because you're using "the cheap stuff" like I am. These problems come with the territory, so get used to it.

Good Luck and Happy Bug Hunting!