Hi all,  up until recently, Sonar X3d has been pretty much problem-free. I was very happy, after the many issues I had with X2.... In X3 I've been doing huge mixes with big track & buss counts, and lots of plugins.  
 
In my latest mix however, I have run into problems.   I had never had problems with running out of computer horsepower,  but it seems my CPU hit about 40% & I was getting dropouts and stuttering - I increased my interface latency settings from my standard mix setting of 1280 up to 1792 samples, but I was still having problems, so I decided to start freezing tracks to ease the load...
 
Here's where the problems started - I can only  freeze one track at a time, because every time I try to freeze another track in the same session, Sonar crashes.  It's got me a bit mystified.  
 
I've managed to freeze a few tracks in between crashes, & the session is now running pretty much without dropouts, but it seems to be operating right at maximum capacity.  Unfortunately, when I un-freeze tracks to alter them, it crashes also.  The CPU & RAM are both running at about 35-40% during the session. 
 
Here are my details:
OS: Win 7 Professional 64 bit (Service Pack 1)
Processor: Intel Core i7 2600CPU @ 3.40GHz 3.4GHz
RAM: 16GB
Interface: M-Audio ProjectMix I/O
Also running a UAD2 Solo PCI Card for some plugins.
 
Any suggestions?

Do you happen to have one or more 32-bit plugins loaded into your X3 project?
 
There are some 32-bit plugs that do not play well with 64-bit Sonar, and it gets a bit tricky, since they likely worked in some prior Sonar version, and each plugin has its own interpretation of the VST 2 or VST 3 specifications.  So, sometimes errors are only exposed because of code changes within Sonar - not to say that the Sonar code is bad, it's just that it may slightly be different in how it does things, or passes things to and from the plugin.
 
I went through a process of first of all deliberately choosing to move to a completely 64-bit environment, then I made sure each 32-bit plugin I wanted to use in 64-bit Sonar worked, and I moved those to a sub-folder in the 32-bit plugins folder.
 
I now have all 64-bit plugin 3rd-party plugins, and only whatever 32-bit ones came with Sonar.
 
SO, these 32-bit plugins MAY be experiencing a slightly different set of code in its interactions with Sonar and/or Windows (new maintenance), and this HAS caused weird processing and crashes - per other posted threads.
 
What happens if you open it in Safe Mode with no effects, to see what happens?  This would be a super easy quick test to see if something with the plugins is causing your problems.
 
Please review and hopefully perform, and post back so I can try to help you through whatever is happening.  :)
 
Bob Bone
 

I had a similar problem with freezing and bouncing tracks and mixes.
My problem turned out to be my cpu temp was running too high.
Try running Real Temp to see if you have a cpu overheating problem.

I would agree with Bob's tack but I would also verify if the performance issue is occurring in other projects as well. If it isn't then that would reinforce the idea of a plug being the problem. If the issue is occurring in all projects I don't have any good ideas other than to ask the question: What Changed?
 
Best of luck.
 
Regards,

Dropouts at 40% suggest another process outside of SONAR is interfering, such as an interrupt handler. Try disabling your network and see if that stops the dropouts.

ALSO:
Based on your system specs, I would suggest you have a buffer size setting issue...
pops, clicks, stuck notes all have a sort of balancing act they do between how FAST you are sending your buffers and
how LARGE they are, in both audio and midi.
I assert that your rig should be able to handle (to a point) a large session w/plugins without  such a large buffer.
too small; pop pop  too large; cripple your cpu, pop pop stutter; too slow, pops and maybe crash as well.
Assertion 2; a 40% cpu hit is not uncommon on large projects w/ lots of (esp. realtime ) plugins, on an
I7 2600, and that shouldn't give you the issue you described in your OP.
 
I always use the old backwards walk when I get issues on a system
that was running well before I  ever even CONTEMPLATE a re-install/wipe/whatever:
1.user error(connections, etc.)
2.hardware (random, non repeatable)
3.software (always repeatable with same steps)
4.(sonar specific): burn the aud.ini file and sonar will make you a nice clean one. you will have redo any configuration tweaks you had but usually works.
 
hope some of this helps, I'm a 2 finger typist (lol).
 
 
Mel

Thanks for all the replies - I suspect something has changed in my system to cause this.  The only thing I can think that I am doing different from my last mix is that I have installed and used Izotope's Nectar Elements... any reports of issues with it?

According to some threads on the web, this plugin's pitch correction functionality uses 'look-ahead' processing, which will drive your latency through the roof.  I am wondering if there is some other functional use of look-ahead processing within that plugin.
 
That plugin sounds like those parts of it are meant to be done POST tracking, for mixing.mastering.
 
Bob Bone
 

Let me clarify my above post.
 
Here is the text I snipped from a support page on the Izotope site:
 
"Nectar has two modes of operation: Mixing and Tracking. In Mixing mode, some modules introduce latency so that the algorithms can look ahead to incoming samples in order to raise their processing quality. In Tracking mode, Nectar keeps latency to a minimum by eliminating these look-ahead functions. Tracking mode also lowers overall CPU usage. Use Mixing mode while mixing when latency can be compensated for, and tracking mode while recording or other times when you need lower latency and CPU usage. Check your host's documentation for more information about latency compensation.
 
So, perhaps you are in Mixing Mode, and this looks like it lets loose the hounds, so to speak, on the look-ahead processing, causing latency issues during tracking/editing sessions.
 
I hope that is the fix, as it seems pretty simple to do - just make sure you are in Tracking Mode.  :)
 
This same web page details the number of samples added to the processing, based on the functions, so you can know exactly how much latency is added by each function of Nectar.  Here is the link for that page:
 
http://www.izotope.com/support/portal/index.php/kb/article/564-Nectar_Latency
 
Bob Bone

Thanks for going to the trouble of looking that up Bob! I actually did manage to freeze the track I was using Nectar on.  It did improve things slightly, but it didn't change much overall.