This should be easy. I'm curious, due to continual 'audio engine' (whatever that is) dropouts, which is more taxing on the engine. Many audio tracks with 'analog' recording, or the same amount of MIDI tracks coupled with audio tracks using soft synths? Or is a combination of both easier or harder?
I have seen constant crashes and frequent audio drops with the use of multiple effects/processors so I leave these alone and do everything dry, but I wonder if it's the number or types of tracks holding the recordings that make the difference?

Looking at your specs I would think your system will not be the issue. A computer with that much memory can take anything you could toss at it.
The short answer is, audio tracks or midi tracks use very little CPU on there own. 
But as you add effects and soft synth those are totally dependent on memory and the CPU.  
 
But have you checked your DPC Latency? Dropouts are most often caused by your background processes interrupting Sonar. 
 
Your on Windows 7 so DPCLAT monitor will still work 
http://www.thesycon.de/deu/latency_check.shtml
 
 
Or for more in depth reporting use this
http://www.resplendence.com/latencymon
 
 

Soft synths and FX plugins load your CPU (and RAM) while audio tracks (without FX) load your hard disk. Overloading either can cause a dropout, but disk dropouts are generally less of a problem. Both can generally be prevented by setting appropriate buffers, and, as Johnny pointed out, making sure your DPC latency is low and, most importantly, stable with no spikes.
 
Crashes are another issue altogether, and generally don't happen due to high CPU/disk loading alone (although high loads can voltage sags that lead to instability). If you have any defective RAM, a big project plugin-heavy project is more likely to expose it, so running MemTest or similar to check you RAM is a good idea when you're seeing a lot of instability. In general, though, crashes are due to software/firmware code errors or interoperability issues among plugins, SONAR, the O/S and hardware interfaces.
 
Having a high-performance machine like yours should help prevent dropouts, but doesn't guarantee stability. My DAW is old and underpowered, but very stable. The few times I've encountered consistent issues were due to bad audio interface firmware, bad RAM, plugins with known issues, or very specific, repeatable SONAR bugs that were generally fixed in the next release (like the recent one with drum maps in project templates).

Thanks a bunch, I'll run the latency reports and memtest and see what shows. But I think the answer I needed was tendered as with a host of midi tracks although I have tried to sidestep the effects/processor plugins, I do tend to be a bit laden with soft synths. Repeats of some of my favorites (addictive keys, raptor) as well as single instances of many others to fill the parts. I may indeed be better, if I understand correctly, and my reports are non conclusive, to record using more hardware samples and patches and minimizing soft synth usage..
Thanks so much for the direction guys!!

joyof60
 I may indeed be better, if I understand correctly, and my reports are non conclusive, to record using more hardware samples and patches and minimizing soft synth usage..
Thanks so much for the direction guys!!

Freezing the synths is a fluent way of keeping things running with "too many" soft synths.

TRhanks Kalle, What does that do exactly? I've always been a bit timid of that function.

joyof60
I may indeed be better, if I understand correctly, and my reports are non conclusive, to record using more hardware samples and patches and minimizing soft synth usage..

That seems to be such a backward step, in my opinion. My hardware synths have been gathering dust since I went down the VSTi route... So much easier, and much, much cheaper than the real thing.
 
How many VSTi instances do you have in one of your typical projects?
 
My laptop DAW is not as highly spec'd as your PC and I'm running up to twenty VSTi, and another twenty or more VST effects and managing fine... Anything over that and everything starts to get a bit too busy anyway.
 
cheers
 
andy

Freezing a soft synth turns the track into pure audio so the synth no longer needs to use CPU and disk access to generate audio on the fly. If you want to unload the synth, you can bounce to track(s) instead of freezing. This permanently renders the audio to a new track and you can then archive the midi and remove the soft synth.
 
There are lots of ways to reduce CPU usage while tracking, but it is important that there are no latency spikes that are affecting you.
 
Regards,
Dan
 
 
 

joyof60
...which is more taxing on the engine. Many audio tracks with 'analog' recording, or the same amount of MIDI tracks coupled with audio tracks using soft synths?

Going back to the original question, straight audio is far less taxing than soft synths and sample players. Even a modest machine can handle hundreds of audio tracks without dropouts. If you use your computer as just a substitute for a tape machine, you'll likely never have issues unless there's a hardware problem (network card that's a DPC hog, for example).
 
But even if you're recording strictly analog sources, at some point you'll want to add effects. Some of those can be extremely taxing on the CPU. Common practice is therefore to defer inserting effects until after tracking is complete, at which time you can simply increase your buffers for the mixing phase.
 
Or, if you have hardware synths another option is to use large buffers all the time. That's what I do, even though the final product will be heavy on samples. I can get away with that by tracking with a hardware synth, recording only MIDI data, and then substituting a soft synth later. Because I never play soft synths in real time, latency is never an issue.

Yea, freezing tracks is the way to go to ease the burden on the CPU.  I used to run plenty of audio tracks on a 486 and newer - as long as there is a 2nd hard drive.  Now, running more than one softsynth or good reverb would overload the old systems.
 
I still habitually freeze synths.