Whenever I encounter CPU spikes/usage/dropouts I always look to my ASIO buffer settings. I am also a frequent user of two different DAW's, and a single universal buffer setting does not always work between them. If DAW 1 wants the buffers set to "yyy", DAW 2 might be happier at "zzz". There are no rules, just take the time to optimize them for each DAW.
 
I also only run lower buffers during tracking - and only if I need to use input monitoring. When I go into mix mode - I raise the buffers to allow more CPU for plugins.
 
Just my 2 cents...

This is true. Plug-ins like Nebula are not designed for use during tracking. Increasing buffers during mixing is a common practice to reduce CPU load.

lawp
nebula is a cpu-hungry plug fo' sho'... how are you using the instances? if they're all on the same channel, that channel is all going to a single core i believe

 
Does anyone know for sure if Sonar works like this?
 

Pict
All of this on one track of audio.

 
If "LAWP" is correct and you are testing with a single track, maybe this is the source of the difference.
 
Can you duplicate the track and apply Nebula on several different tracks/channels to see if performance is improved? I'm not saying that is a solution - I'm just saying it might go a long way in explaining why there is such a discrepancy.
 

I'm not using Nebula for tracking I've tried it in both Reaper and Sonar with multiple channels with one instance each and a single channel with 6 instances on it(as suggested by stevec) with nothing on the busses and every time Reaper performs flawlessly and Sonar chokes.I've duplicated the same track over 24 channels and gradually added single instances of Nebula to see when it chokes each DAW.
             Reaper manages 16 instances Sonar 6 instances every time with the same configuration of audio tracks this is using console input,buss or preamp emulations add an emt plate reverb longer than 1.5 secs(very processor greedy) and Sonar won't even begin playback.It's night and day there must be a reason.As I said before Henry Olonga had the same experience which is why I tried Reaper in the 1st place and I know for sure his system isn't anything like mine.
 
     I know conclusions are as easy to draw as curtains but my conclusion is Reaper simply handles Nebula libraries far better than Sonar.In fact my head is beginning to swim from the different permutations I've tried on both DAWs every time Reaper performs better with Nebula on my computer.

similar thread http://forum.cakewalk.com/FindPost/2943488

I disagree that you can't (or shouldn't) compare DAWs this way. These are important real world facts that we have to deal with. The same way you can say "crap, Ableton doesn't support VST3 but my other DAW does!", this is a valid observation. Sonar is not very efficient at working with Nebula, or Nebula isn't with Sonar, whatever, the point is the results speak for themselves and directly affect the way we can work effectively (or not) with the DAW. Reaper is often hailed as being particularly efficient. 6 vs 16 is a very big difference though. No matter how many differences there are, this is a strong point in favor of Reaper and a strong call to the bakers to look into this specific plugin's performance, or just performance in general.
 
Some people seem to really dislike any form of critique on Sonar. I'm hoping critique makes things better in the long run.
 
EDIT: I'm editing my posts a lot today, but I just wanted to say that I believe Reaper specifically has a useful kind of "look ahead" feature that calculates plugin performance ahead of the regular sample buffer when it has "extra processing power" during a lull. This may be at play here or not, but it's a useful feature none the less.

Yikes... that thread again...
 
I remember someone posting they used Ozone 5 on every track a couple months ago, and someone responded that they were impressed. I assume this is one of the more "CPU hungry" plugs and I just got it a few weeks ago. I just started piling them on an audio track and assigning them each a different preset master setting (i.e. processing audio actively). They started to gain stage each other, so I had to keep lowering inputs/monitor settings. I got bored with this at 10 instances, play it, and CPU is running 6%. This is definitely not a "real-world" application of plug-in use, and if I owned a plug that consumed my machine, I would kick it to the curb quicker than last week's news.
 
Edit: I just closed the project (left X3 open) and CPU dropped to 2% and freed 1GB of RAM.

Were you testing Reaper in one of the sample accurate modes?

mettelus
Yikes... that thread again...
 
I remember someone posting they used Ozone 5 on every track a couple months ago, and someone responded that they were impressed. I assume this is one of the more "CPU hungry" plugs and I just got it a few weeks ago. I just started piling them on an audio track and assigning them each a different preset master setting (i.e. processing audio actively). They started to gain stage each other, so I had to keep lowering inputs/monitor settings. I got bored with this at 10 instances, play it, and CPU is running 6%. This is definitely not a "real-world" application of plug-in use, and if I owned a plug that consumed my machine, I would kick it to the curb quicker than last week's news.
 
Edit: I just closed the project (left X3 open) and CPU dropped to 2% and freed 1GB of RAM.

It's gonna sound sarcastic, and it's NOT meant to, but I don't understand your point in relation to the OP?

Sanderxpander
It's gonna sound sarcastic, and it's NOT meant to, but I don't understand your point in relation to the OP?

SONAR is a sample accurate application. Reaper is not sample accurate in it's default configuration. Sample accuracy adds higher demands on system resources.

Testing Reaper in one of the sample accurate modes may show similar results to SONAR's baseline.