though as I said its not unlikely I will have 20 in some projects. Its just that I use GR often and its a good VST to test performance with.

30 instances of GR5 might be the equivalent of 150 randomly used/needed plugins. It's fine to find a processing ceiling with but I don't see it's instance count as a real-world indication of how many VSTs in general you can use. I think I would just do your normal project work and see how that goes unless that has already given you a problem.

Since Snooks and I have already tested with record arm on, we could probably see how many we can get running as playback only and report back just so you can compare. I still have my test project I think.

Also, and most importantly. Unless you have some super-tight, time-sensitive (to the ms) automation going on... when *not* record armed, you don't need 30ms buffer, it serves no purpose but to produce pops and clicks. Crank that buffer to it's higher/highest setting when not tracking.

__________________Your whole life people will tell you what you can't do. Getting past them is the first step to actually getting things done.

I think I would just do your normal project work and see how that goes unless that has already given you a problem.

Thats why Im here. Im simply using GR as a benchmarking tool since its used heavily in many projects, but the issue is that I often am getting crackles/pops when my realtime CPU is at around 50% or less sometimes, and my total CPU is only 25% or so

My decently powerful/expensive rack PC with a good quality PCIe sound card is not performing anywhere near what it should be.

Thats why Im here. Im simply using GR as a benchmarking tool since its used heavily in many projects, but the issue is that I often am getting crackles/pops when my realtime CPU is at around 50% or less sometimes, and my total CPU is only 25% or so

My decently powerful/expensive rack PC with a good quality PCIe sound card is not performing anywhere near what it should be.

Hmm... benchamarking isn't normal work. What happens if you just open a project of yours and start working? As I said way up ^there, expecting CPU to get to near 100% before you hear pops and clicks is a thing of the past, you can't use that as an indicator these days - it will drive you crazy.

There is some wiggle room for RTCPU not being 100% but that takes us back to both my and drumphil's question about how much of your CPU for reaper.exe is kernel vs user mode. I do think there may be some room for improvement in your system but it needs to be looked at more from a real project, real world perspective instead of trying to benchmark at 30 sample buffer.

__________________Your whole life people will tell you what you can't do. Getting past them is the first step to actually getting things done.

As I said the reason I am here is because I am often working on projects and my CPU is getting nowhere near taxed and yet Im getting crackles and pops.

"how much of your CPU for reaper.exe is kernel vs user mode." What is the difference? Im only aware of Real Time and Total CPU. Total CPU matches what I see in windows task manager, and real time is what Reaper performance monitor shows me.

As I said the reason I am here is because I am often working on projects and my CPU is getting nowhere near taxed and yet Im getting crackles and pops.

"how much of your CPU for reaper.exe is kernel vs user mode." What is the difference? Im only aware of Real Time and Total CPU. Total CPU matches what I see in windows task manager, and real time is what Reaper performance monitor shows me.

You have to use a tool called Process Explorer to see it. When any application runs it has code that runs up in 'user mode' and when it makes calls that need to go down to hardware it gets passed down low-level to the OS and those CPU cycles are used in 'kernel mode'. Where the majority of CPU cycles are being burned (user or kernel) is helpful because it tell us more about just where the CPU is being eaten - like servicing the soundcard or a wiggy video driver would show up in kernel - conversely some inefficient code in Reaper processing it's own data would show up in user CPU.

For process explorer, just double click reaper.exe in the list and look at cpu on the performance tab and send us a screenshot - green = user mode and red = kernel mode. Like the screenshots I posted above last week.

__________________Your whole life people will tell you what you can't do. Getting past them is the first step to actually getting things done.

Heres a screenshot. With the project I was running, I had some reverb on the master, and 29 instances of Guitar Rig playing the same prerecorded guitar track. The RT longest block size was consistently slightly over the maximum allowed time, and especially on seek/stop, there would be lots of crackling/popping

Can I suggest running the DAW Bench test for reaper. It would be useful to know if the problems are specific to guitar rig, rather than the overall system load.

See how much load you can put on the system before you get crackles. If you can put much higher load on the system before you get problems than with guitar rig, then the basic working of your system is unlikely to be the problem.

At the moment we are assuming that guitar rig isn't the cause of the issues.

Regarding anticipative fx, part of the reason it is helpful is that it allows a buffer to smooth out the cpu load. What if a plugin only uses 30% cpu on average, but has cpu usage spikes that could interrupt the overall system?

Could it be that this is an issue with guitar rig?

How do things work with anticipative fx turned on, and the buffer size set to 64?

Also, are you using the 32bit version of guitar rig in reaper 32 bit, or the 64 bit plugin in 64 bit reaper? Using the 32 bit plugin in reaper 64 may not perform as expected.

It would also be worthwhile testing with the built in intel HD graphics rather than the 710.