# Help! Reaper Freezes when Saving Project (Slow Saves)



## Pav_G

In Reaper 6.15 & 6.16 When saving the project (or autosaving) the project freezes for 10 seconds of seconds and becomes unresponsive If I am running 5+ instances of any virtual instrument (Play, Kontakt etc.). This prevents me to have an autosave on. Could you please help me figure out what is happening?

You can see the problem here:


In my projects I tend to have from 10 to 60 instances of Virtual Instruments and when I worked in Logic and 2012 macbook, I never had issues.
I have NVMe SSD for Libraries + SATA SSD for the System & Plugins, 64 Gigs of Ram, AMD Ryzen 3950x 3.5 GHz (16 Core, 3.5 GHz base clock, 72 MB total cache).
I am running 64x versions of Kontakt.

Things that I tried/ruled out:
- The issue happens both on a project that is 70MB and 2MB so the size seems to not matter.
- It's not a case of corrupted project or an unreasonable high number of virtual instruments, because I performed tests on a fresh project with only 5+ Virtual Instruments Instances and I encountered the same problem.
- The problem goes away if I tick 'disable saving full plugin state' in preferences in plugin compatibility section, but is not really a solution as none of my libraries load if I re open the project. Saving minimal 'undo states' per plugin does not solve the problem.
- I switched of saving undo states in preferences - no difference.
- I do not save undo states within Kontakt aap.
- I switched off saving undo history - no difference.
- I performed RAM Diagnostics - everything fine.
- Performed SSD speed tests - I didn't get any abnormal results.
- Disabled Auto Protect, Disabled Firewall on Norton Antivirus (This is essentially switching it off, right?)

UPDATE:
- Changing Multicore settings in Kontakt did not make a difference. 


Have you encountered a problem like this? Have you got any suggestions what might be causing the problem and what tests I can perform to figure it out?

I would really appreciate some suggestions.

Thanks,

Pav


----------



## Dex

You're sure this only started with reaper 6.15?

Maybe try excluding your project directory from Windows defender scan locations.

Anyway, this happens to me too but only for larger projects (in terms of MB) and I just live with it.


----------



## Pav_G

Dex said:


> You're sure this only started with reaper 6.15?
> 
> Maybe try excluding your project directory from Windows defender scan locations.
> 
> Anyway, this happens to me too but only for larger projects (in terms of MB) and I just live with it.


Thanks for the reply. 

I am not sure if it happens only in 6.15 & 6.16. I recently switched from mac an Logic to PC and Reaper and these are the first versions that I started working with.

I will try to look into windows defender. So far I only switched of Norton under assumption that Norton would be handling the job of windows defender. But maybe I am wrong. 

What do you mean by larger projects? In terms of file size or track count? Mine is 40Mb and it seems to be too much. Also on the track count front, I had a chance to speak to somebody who runs hundreds of instances of Kontakt in Reaper and he never had this problem. However, In my case is maximum 50 instances and also according to my test, it takes only 5 instances of contact to get Reaper to freeze for a couple of seconds during saving.


----------



## pmcrockett

I get load freezes at 30 MB and under on project size in Reaper. I assumed it was normal.

Project size has less to do with how many Kontakt instances there are and more to do with how complicated those instances are, because the entire plugin state has to be saved. If you, for example, save a project with bunch of instances of OT's Capsule engine instruments, the project size can end up being pretty large. (EDIT: e.g. my track template for fully loading just the Violins in OT Symphonic Sphere is ~19 MB on its own.) The save file footprint of the tracks themselves -- not counting the plugins -- is minuscule.

I have a massive Hollywood Strings template whose file is ~70 MB for an empty project with just the configured Play instances.


----------



## tack

Just to help baseline (with an AMD 2950X targeting a SATA SSD as a project drive):

My full template (100+ tracks) is about 230MB on disk, and with all instruments disabled, takes about 1.3 seconds to save out. This includes last known plugin state. Now, as I start enabling instruments, save times increase, presumably because Reaper must query each plugin's current state, and then serialize it within the project.

A fresh project with 10 empty Kontakt 6 instances saves imperceptibly quick, and takes up 54KB on disk. Unsurprisingly.

If I add a different multi-articulation patch to each of those Kontakt instances from Spitfire Chamber Strings, save times grow to about 500ms, and the file size is 8.5MB. Duplicating all the tracks increases save times to a bit over 1 second, with a 17MB file size. With 30 tracks, it's around 2 seconds. So we can reasonably infer this is roughly linear, and that with 60 tracks, with _those _patches anyway, 5-6 seconds is in the ballpark.

It'd be interesting to know if that process is much faster in other DAWs -- if so it suggests this is parallelizable and there could be an optimization opportunity there for Reaper.

I'd disable McAfee _entirely_ and go hunting for Windows Defender and ensure the same. Firewall is irrelevant here, if either (or both) are the culprit at all, it's going to be the antivirus hooks. (Personally I recommending avoiding third party anti-malware tools. Windows Defender is perfectly competent, and some of these third party solutions have a history of doing bananas things that actually make you less secure.)

Another thing you can try doing, just to rule out (or in) personal settings, is a fresh portable install of Reaper and see if the same behavior is reproducible.


----------



## Pav_G

tack said:


> Just to help baseline (with an AMD 2950X targeting a SATA SSD as a project drive):
> 
> My full template (100+ tracks) is about 230MB on disk, and with all instruments disabled, takes about 1.3 seconds to save out. This includes last known plugin state. Now, as I start enabling instruments, save times increase, presumably because Reaper must query each plugin's current state, and then serialize it within the project.
> 
> A fresh project with 10 empty Kontakt 6 instances saves imperceptibly quick, and takes up 54KB on disk. Unsurprisingly.
> 
> If I add a different multi-articulation patch to each of those Kontakt instances from Spitfire Chamber Strings, save times grow to about 500ms, and the file size is 8.5MB. Duplicating all the tracks increases save times to a bit over 1 second, with a 17MB file size. With 30 tracks, it's around 2 seconds. So we can reasonably infer this is roughly linear, and that with 60 tracks, with _those _patches anyway, 5-6 seconds is in the ballpark.
> 
> It'd be interesting to know if that process is much faster in other DAWs -- if so it suggests this is parallelizable and there could be an optimization opportunity there for Reaper.
> 
> I'd disable McAfee _entirely_ and go hunting for Windows Defender and ensure the same. Firewall is irrelevant here, if either (or both) are the culprit at all, it's going to be the antivirus hooks. (Personally I recommending avoiding third party anti-malware tools. Windows Defender is perfectly competent, and some of these third party solutions have a history of doing bananas things that actually make you less secure.)
> 
> Another thing you can try doing, just to rule out (or in) personal settings, is a fresh portable install of Reaper and see if the same behavior is reproducible.



Thank you for the suggestions. I tried the portable isntall solution already and It dind't help. But it sounds like you are experiencing slow saves as well. I can confirm that On my 2012 MacBook with 16 Gigs of Ram I did not encountered this sort of issue. But it would be interesting to hear if this happens in other DAWs on PC.

However, I discussed my issue with Johnathan (Storryteller, OTR) who is super kind by the way and tried to be helpful as much as he could. Anyway, he found my issue quite bizzare. He doesn't experience the save delay himself and he runs hundreds of instances of Kontakt in Reaper, which makes me believe that reaper choking on Saves is not 'normal'. Something is going wrong there. But it would be interesting to find what causes it - whether it's hardware or software.


I also contacted Cocos Team and this is what they said:

'That could have a whole number of reasons
based on configuration alone, requiring a lot of troubleshooting. Alas
your video has no sound so we don't know if audio output is affected or
not. However, one idea coming into my mind is that NVMe SSDs can cause
quite some CPU load during data transfer, so if your task scheduler
spreads threads over cores in an unlucky way this may bring other things
to a halt.'

I asked them to give me ideas on how I can test their theory. We will see what they suggest.


Also for anybody interested, I have just found a similar thread on Reaper forum. https://forum.cockos.com/showthread.php?p=2347304


----------



## tack

I was never that bothered a 3-5 seconds of save times, but if it got much higher than that I'd probably complain. And I do admit that this wouldn't be fast enough for autosave. When I first started using Reaper I was saving to a network drive over CIFS and that was just simply brutal. 30-40 seconds for that 200MB template. Completely unusable. But that blame lies with Windows, not Reaper.

I'm surprised to hear that coming back from Cockos. It sounds specious to me, it has to be said. The reason NVMEs cause CPU load is that they're fast as balls and invariably move the bottleneck to the CPU.

I'm more interested that @storyteller doesn't experience this same behavior. On Windows as well? I wonder if he tried a portable install if he'd observe a difference.

Do you see this if you avoid Kontakt altogether? Maybe just use PLAY instruments? Edit: nevermind, I see your post on the Reaper forum now where you mentioned trying exclusively PLAY.


----------



## tack

Another idea, try having Reaper load Kontakt as a dedicated process and see if that changes anything. (It didn't for me, but since we're experimenting here.)

Right click on Kontakt in the FX browser and click Run As | Dedicated Process. You may also wish the enable Embed Bridged UI in that same menu.


----------



## pmcrockett

I just clocked it, and it takes me 25 seconds to save a 35 MB project. SSD vs. HDD and with or without Defender enabled for the folder don't make any difference.


----------



## tack

I thought I might try the trial version of Studio One. With the 30 track Kontakt test I did above, save times are about 5x slower than Reaper (~12.6 seconds vs ~2.3 seconds with Reaper)


----------



## Joakim

It takes me less than 3 seconds to save a 18.6 MB large project with 16 instances of Kontakt 6 in Reaper version 6.14 to an SSD.

3950x
64GB 3600 CL16 RAM


----------



## Stevie

The only thing I can think of that causes this is a huge track chunk. VSTis tend to save their whole instrument data there, like the whole mapping of all samples in the case of Kontakt. Maybe Poay is worse here. One huge downside with the track chunk is: REAPER saves it regardless if changes had been made to the VST instrument at all. I’m sure saving times could be hugely improved if REAPER set a flag for the VSTi. That way only relevant data would be saved, as the VSTi remained untouched.


----------



## tack

I don't think the slowness is saving it to disk as such (if that's what you meant). After all, even when FX are disabled it still writes out the (last known) track state chunk. But when the FX is enabled, it must:

Interrogate the FX to fetch current state
Serialize that current state
Serialization ends with base64, that much is obvious looking at the RPP file. But base64 is pretty fast (2-3 GB/s on one relatively modern core). So that either means there's a lot more to serialization than just base64 (feasible) or (I suspect more likely) querying and fetching state data from the FX is inefficient.

And I imagine the only way for it to know that it's changed (whether it should bother to serialize) is to actually fetch it and compare. And if that's the slow part, it won't help much. OTOH, if the slow part is actually storing that in Reaper's internal track state chunk, yeah, maybe room for improvement there.

Question is why doesn't storyteller see this. I'd love to see more measurements. If we can find something tangible, maybe we can fire a flare gun on the Reaper forum. 1 out of every 250 times Justin notices.


----------



## pmcrockett

It definitely doesn't seem to be a disk write speed issue. If I open the Windows disk activity viewer, there's barely any disk activity while saving, and the CPU only jumps by like 8%.


----------



## pondinthestream

I gave up on Reaper after many years in part because it never handled Kontakt very well - for me. Nothing ever really fixed that and I certainly tried. Some interaction between my system, Kontakt and Reaper. I now use Studio One and Bitwig for composing - they have their own issues too but I find them much better for composing - still use Reaper as an audio utility but not for composing in.


----------



## pmcrockett

I'm still sorting through this, but I've made progress. Here's what I did, most of which is probably irrelevant:




I booted into Windows safe mode to see if Reaper would behave on a stripped down system. Had to plug my keyboard into a different USB port to make safe mode work (EDIT: also unplugged my Steam controller to free up that port). Couldn't load plugins in Reaper in safe mode, but if I loaded with FX offline, the project saved almost instantly.

Went back to normal Windows and loaded the project with FX offline. The project saved almost instantly.

Brought the FX back online via the _Track: Set all FX online for selected tracks_ action. Project saved in under 5 seconds.

Closed Reaper, reopened, and loaded the project as normal with FX online. The project loaded faster than I remember, and it still saved in under 5 seconds.




All I can think is that maybe Reaper doesn't play well with a Windows session that's been running a long time and needs occasional system reboots to maintain peak performance. Maybe I haven't noticed it because I tend not to reboot or power off unless I have a specific reason to.


----------



## pondinthestream

pmcrockett said:


> All I can think is that maybe Reaper doesn't play well with a Windows session that's been running a long time and needs occasional system reboots to maintain peak performance.


that's interesting - perhaps all my problems related to that - my machine runs for days at a time


----------



## storyteller

@tack - Thanks for tagging me in the thread. I've spent a lot of time helping Pav try to trouble shoot this as well. I loaded his template (with the plugins I have the same as his). I've tried my templates on OS X Catalina as well as Windows 10 virtualization. I do not experience the delay like his video is demonstrating. This is the first I've seen a video of it though.... which is good since that means we are moving in the right direction to solve the problem.

The one thing I really hope Pav tries is turning Defender off completely. I've suggested it numerous times, but that doesn't seem to be something he has wanted to test in full. I have a suspicion that this is probably having to do with anti-virus/anti-malware. If not Defender, then it could potentially be the NVME hardware, or potentially a failing piece of hardware (though he has run a mem test on his ram). 

Hopefully his testing above involved disabling anti-virus completely so that will rule that portion out now. In our emails, he had only attempted excluding kontakt files. Of course it is important to exclude reaper files and any other file types that are used in a DAW.

Other points that I could not troubleshoot for PAV... His template is running Spitfire BBCSO as well as Play and Kontakt. I thought that possibly BBCSO might be an issue (since I don't have it to test and could not find any other potential problems). But, from his tests, he found that disablng BBCSO didn't seem to affect the save times. Rather, Kontakt and Play both exhibited the same behavior causing the slowdown.

@Pav_G - Please feel free to jump back in with any further details from our tests and suggestions as well.



pmcrockett said:


> All I can think is that maybe Reaper doesn't play well with a Windows session that's been running a long time and needs occasional system reboots to maintain peak performance.


I also had him copy/paste his tracks into a completely new/blank project and that seemed to produce the same issue he is currently experiencing.

EDIT: I also had him play with the CPU cores and buffers in Kontakt to see if either of those settings were creating issues. I wouldn't think they would be a culprit, but that was another path he said he tested.


----------



## Pav_G

storyteller said:


> @tack - Thanks for tagging me in the thread. I've spent a lot of time helping Pav try to trouble shoot this as well. I loaded his template (with the plugins I have the same as his). I've tried my templates on OS X Catalina as well as Windows 10 virtualization. I do not experience the delay like his video is demonstrating. This is the first I've seen a video of it though.... which is good since that means we are moving in the right direction to solve the problem.
> 
> The one thing I really hope Pav tries is turning Defender off completely. I've suggested it numerous times, but that doesn't seem to be something he has wanted to test in full. I have a suspicion that this is probably having to do with anti-virus/anti-malware. If not Defender, then it could potentially be the NVME hardware, or potentially a failing piece of hardware (though he has run a mem test on his ram).
> 
> Hopefully his testing above involved disabling anti-virus completely so that will rule that portion out now. In our emails, he had only attempted excluding kontakt files. Of course it is important to exclude reaper files and any other file types that are used in a DAW.
> 
> Other points that I could not troubleshoot for PAV... His template is running Spitfire BBCSO as well as Play and Kontakt. I thought that possibly BBCSO might be an issue (since I don't have it to test and could not find any other potential problems). But, from his tests, he found that disablng BBCSO didn't seem to affect the save times. Rather, Kontakt and Play both exhibited the same behavior causing the slowdown.
> 
> @Pav_G - Please feel free to jump back in with any further details from our tests and suggestions as well.
> 
> 
> I also had him copy/paste his tracks into a completely new/blank project and that seemed to produce the same issue he is currently experiencing.
> 
> EDIT: I also had him play with the CPU cores and buffers in Kontakt to see if either of those settings were creating issues. I wouldn't think they would be a culprit, but that was another path he said he tested.


@storyteller Thank you so much again for helping out and devoting a lot of time for me. I really appreciate it and I am super grateful.

Sincere apologies for not updating you on the antivirus test and on the videos, I jump straight into forum as I didn't want to waste even more of your time, considered how much you tried to help me already. I did switch off Norton completely and switched off everything within 'Windows Defender with Advanced' window. It didn't make a difference.





What test would you use for testing if the SSD is failing? I only did speed tests and performed RAM tests with 'Widows Memory Diagnostic'. I doubt this is the case, because it sounds like other people experience something similar, but it's worth a shot.

It's correct. I tried different settings with the core configurations and it would not make a difference.

@pmcrockett You have an interesting theory about Windows running for a long time causing it. However, I did test it on a fresh boot and I didn't get any better results.


----------



## pmcrockett

After waking the computer up from sleep mode this morning, the save time was back up to about 19 seconds. Not as long as before (25 seconds) but still clearly a problem. Rebooting brought the time back down to just under 5 seconds.

I screencapped what programs and services are running in the Windows task manager and I'll look again and compare to that list once Reaper starts saving slowly again. It may be that there's something running in the background that's messing things up and isn't there immediately after reboot on my system.

Also, saving was still nearly instant with all FX offline even when the online FX save time was 19 seconds. I don't understand why having the FX running slows the save down. Maybe when saving an offline FX it just reuses whatever state data it already had for the FX in the save file instead of actively querying the FX.


----------



## Dex

This online vs offline save time is interesting. Are the file sizes the same? (I'd test it myself but I'm not at my computer right now.)

One thing I know from tests I did a while ago is that it takes my other DAW (Renoise) even longer to save a project than reaper does. The only difference in their save file structure is that Renoise save files are compressed human-readable files while reaper save files are uncompressed human-readable files.


----------



## tack

@pmcrockett's experience sounds like it could be a separate issue because the symptoms are a bit different: much longer save times than the rest of us are experiencing, and an observation that rebooting temporarily improves things, which the rest of us don't seem to experience. I myself have Windows up for weeks at a time without rebooting and don't notice any degradation over time in this regard.

We aren't being very methodical in testing either. It's hard to be, admittedly, because we may not all own the same libraries.

To try to help be a bit more data driven, I've created 4 different types of projects, compared save times in both Reaper and Studio One, and assembled everything into this spreadsheet:

*Link to spreadsheet*.

Please try out the projects (hopefully there's at least one in there for a library you own) and add your data. See the Methodology tab in there for instructions.

I have to retract my earlier comment about Studio One being several times slower than Reaper. They're quite comparable -- probably within the margin of error considering with S1 I need to use a stopwatch (unlike with Reaper where I can get precise timing via a script).


----------



## Pav_G

tack said:


> @pmcrockett's experience sounds like it could be a separate issue because the symptoms are a bit different: much longer save times than the rest of us are experiencing, and an observation that rebooting temporarily improves things, which the rest of us don't seem to experience. I myself have Windows up for weeks at a time without rebooting and don't notice any degradation over time in this regard.
> 
> We aren't being very methodical in testing either. It's hard to be, admittedly, because we may not all own the same libraries.
> 
> To try to help be a bit more data driven, I've created 4 different types of projects, compared save times in both Reaper and Studio One, and assembled everything into this spreadsheet:
> 
> *Link to spreadsheet*.
> 
> Please try out the projects (hopefully there's at least one in there for a library you own) and add your data. See the Methodology tab in there for instructions.
> 
> I have to retract my earlier comment about Studio One being several times slower than Reaper. They're quite comparable -- probably within the margin of error considering with S1 I need to use a stopwatch (unlike with Reaper where I can get precise timing via a script).


Shouldn't we pick something that everyone has in their arsenal, like Konakt factory library or something?

Just to understand what we are after, once we have different entries what will this data tell us?


----------



## tack

Pav_G said:


> Shouldn't we pick something that everyone has in their arsenal, like Konakt factory library or something?


I don't even know that everyone has that. Previous posts mentioned OT. I thought I would pick heavy weight patches like those multis from OT and Spitfire. Konfact factory library patches are pretty small, state-wise. But if you want to put together a test project with the factory library I can host it, and update the spreadsheet with my own results.



Pav_G said:


> Just to understand what we are after, once we have different entries what will this data tell us?


It will tell us if there are outliers, and if those outliers could be related to system specs, and (where applicable) if there is an actual issue with Reaper relative to other DAWs. So far, Reaper and S1 are behaving very comparably on my system. If they had been substantially different, I'd have collected more data (system metrics, thread analysis) and taken it to the Reaper forum. But as it is, I have nothing anomalous to report (relative to S1).

And it will help us hone in on where to look next, because to be honest we have a collection of disorganized anecdotes with no methodology, and it's hard to make sense of anything. Everyone has different projects and that's a significant factor. We need to start eliminating or at least controlling variables.


----------



## brek

tack said:


> It'd be interesting to know if that process is much faster in other DAWs -- if so it suggests this is parallelizable and there could be an optimization opportunity there for Reaper.



To add another disorganized anecdote...

Save times were in the same ballpark (iirc around 30 seconds for a 100mb project) for me with Reaper and Cubase (tested on Windows PC).

When I did some tests on a Macbook running Logic with the same patches loaded, the save times were a second or two. So, it's possible, but don't know if the magic sauce is in Logic or the Mac.


----------



## Levitanus

I'll upwote @brek here. The same theme recently was on the Russian forum, so I've remembered another masterpiece of software called Blender3D, that autosaves project up to 16GB every 2 minutes without breakouts and other things.
I feel the reason is — that it makes some sort of background dump. Maybe logic does the same. But, occasionally I can't imagine, how this could be done without stopping user activity. Or without doubling RAM usage...


----------



## storyteller

pmcrockett said:


> After waking the computer up from sleep mode this morning, the save time was back up to about 19 seconds. Not as long as before (25 seconds) but still clearly a problem. Rebooting brought the time back down to just under 5 seconds.
> 
> I screencapped what programs and services are running in the Windows task manager and I'll look again and compare to that list once Reaper starts saving slowly again. It may be that there's something running in the background that's messing things up and isn't there immediately after reboot on my system.
> 
> Also, saving was still nearly instant with all FX offline even when the online FX save time was 19 seconds. I don't understand why having the FX running slows the save down. Maybe when saving an offline FX it just reuses whatever state data it already had for the FX in the save file instead of actively querying the FX.


Just curious if you experience the same issue while leaving Reaper running the whole time or if you experience the same delays if you restart Reaper with a long-running Windows session? I have noticed that past versions of Reaper do exhibit small memory leaks that build up over time - especially if you never shut it down. At least that is my experience on OSX. However, almost ALL applications exhibit similar leaks - so it isn't something that I'd consider a defect... rather just a by-product of millions of lines of code. Reaper's leaks just become more apparent with constant freezing/disabling/activating tracks. Again, it's small... but it can build up over time. It may actually be a Kontakt bug or something not Reaper related since it deals with the instruments being loaded/unloaded from ram. Anyway - just thought I'd ask...


----------



## tack

One way to determine if the leak is caused by an FX or Reaper itself is to have the FX load as a dedicated process. This way, when the FX is offlined (or deleted), the reaper_host64 process exits entirely.


----------



## tack

Pav_G said:


> Shouldn't we pick something that everyone has in their arsenal, like Konakt factory library or something?


Ok, I added a project using the factory library. Really needed to amp up the track and patch count and even then it was harder to measure with S1 as human lag time with the stop watch represents a greater portion of the overall time. In any case, for me, save times with 250 patches from the factory library are sub-second.


----------



## hsindermann

I always had a similar problem - my old template with about 100 tracks took at least half a minute to save. Drove me nuts. What increased the save time tremendously was when I incorporated Berlin Woodwinds - it seems this library takes up the majority of the time. The only solution for me was to move away from having all my libraries loaded in Reaper itself - instead I moved everything into a locally running instance of VEP7. Save times are back to a split-second now, and I could happily activate auto-save again.


----------



## tack

Yeah, with VEP, the patch state doesn't get stored in the Reaper project anymore, which has its pros and cons. Certainly significantly faster load and save times and smaller project files is the main benefit.

Would be really nice to have data points from other DAWs like Cubase (in the non-VEP case).


----------



## pmcrockett

storyteller said:


> Just curious if you experience the same issue while leaving Reaper running the whole time or if you experience the same delays if you restart Reaper with a long-running Windows session? I have noticed that past versions of Reaper do exhibit small memory leaks that build up over time - especially if you never shut it down. At least that is my experience on OSX. However, almost ALL applications exhibit similar leaks - so it isn't something that I'd consider a defect... rather just a by-product of millions of lines of code. Reaper's leaks just become more apparent with constant freezing/disabling/activating tracks. Again, it's small... but it can build up over time. It may actually be a Kontakt bug or something not Reaper related since it deals with the instruments being loaded/unloaded from ram. Anyway - just thought I'd ask...


I'm restarting Reaper within the Windows session. Typically, I don't leave Reaper open for more than maybe 5 hours at a time and I never put the computer to sleep while Reaper is running. The 19 second saves this morning were coming from a fresh load of Reaper on a Windows session that had slept overnight. So I suspect in my case it's something outside of Reaper that's at the root of the problem.


----------



## fakemaxwell

pmcrockett said:


> I'm restarting Reaper within the Windows session. Typically, I don't leave Reaper open for more than maybe 5 hours at a time and I never put the computer to sleep while Reaper is running. The 19 second saves this morning were coming from a fresh load of Reaper on a Windows session that had slept overnight. So I suspect in my case it's something outside of Reaper that's at the root of the problem.



Wait, are you sleeping the computer vs shutting down entirely? Sleep/hibernate generally do not play well with real time audio. Booting back from safe mode requires a shutdown, and it seems to work better when you do it that way. Can you check and see what happens when you shutdown overnight?


----------



## Quanah

Would any of those plugins be UVI Workstation with a full Virhamonic Bohemian instrument loaded, by chance?

Attach files


----------



## pmcrockett

fakemaxwell said:


> Wait, are you sleeping the computer vs shutting down entirely? Sleep/hibernate generally do not play well with real time audio. Booting back from safe mode requires a shutdown, and it seems to work better when you do it that way. Can you check and see what happens when you shutdown overnight?


I'll try an overnight shutdown instead of sleeping tonight. Just sleeping and immediately waking the computer off of a fresh reboot, which I tried today, doesn't cause problems.

@tack I've added my results to the spreadsheet for projects 3 and 5 in Reaper (tested right now, while Reaper seems to be working properly for me). The results are similar to yours -- marginally slower, but I'm saving to HDD and not SSD.

EDIT: Ran the test again, saving to two SSDs (the Windows system drive, and a non-system drive), and the results were both slightly slower than the HDD. Ran one of the HDD tests again and it was still faster than the SSDs. Odd.


----------



## Pav_G

brek said:


> To add another disorganized anecdote...
> 
> Save times were in the same ballpark (iirc around 30 seconds for a 100mb project) for me with Reaper and Cubase (tested on Windows PC).
> 
> When I did some tests on a Macbook running Logic with the same patches loaded, the save times were a second or two. So, it's possible, but don't know if the magic sauce is in Logic or the Mac.


 Damn. I start to regret switching to windows. I never had problems like this on a macbook and logic. Does everyone on Windows experience this? This is the main question.


----------



## Levitanus

@Pav_G, I feel the keyword here is not MacOS but logic.
I'm now on Ubuntu + Reaper. And, I'm sure heavy projects takes still time to be saved. But... because I cannot use VEPro (which is the most time killer and project size inflator) and I'm using subproject in orchestral arrangements (which may be not common to many of people) — I don't feel any freezes on save and can, finally live with backup once per 2 minutes.


----------



## pondinthestream

Pav_G said:


> Damn. I start to regret switching to windows. I never had problems like this on a macbook and logic. Does everyone on Windows experience this? This is the main question.


Not really but this sounds typical of my experience with Reaper. Every so often some incredibly annoying behaviour would appear and waste my time. Eventually I used portable installs and just deleted the old one and started a new one. In the end I switched to studio one, which has not been so unstable


----------

