196,675 users have contributed to 43,023 threads and 258,419 posts.
In the past 24 hours, we have 2 new thread(s), 3 new post(s) and 99 new user(s).
That seems a lot for a quad core. How much memory is DP showing it is using and how many threads? My experience is that if DP shows anything over 50% CPU you'll hear it in pops and crackles. What disk are you running the samples off? They should be on a dedicated 7200 drive.
Spaces can take quite a lot of CPU but you may may need to look at a PC slave to get over the problem.
Hey, thanks for the reply. I agree, on paper it seems like a lot, however it's a lot of articulations for each instrument, so for example one Kontakt instance will be LASS 1st & 2nd Violins, with only a few things playing on each instance, not all 16 channels blazing at a time. I also have the samples split pretty evenly over three 7200 rpm drives as well. I'm not using Play at all in this template, in attempting to make it all stable I thought I'd try just keeping it all in Kontakt.
I've disabled the instance of Spaces, which doesn't seem to make a huge difference. I've also tried reloading one instance of Kontakt at a time, and with one K5 loaded with LASS 2 (no Stage & Color loaded), no other plugins or anything, the buffer at 1024, and the CPU is already at 15-20% without even hitting play.
In the Activity Monitor, DP is using around 40 threads, and with the one instance loaded DP has 1.62 Gigs of real memory.
LASS is a hog on K4...relative to VSL or QLSO/PLAy3...BUT, what strikes me as odd is that you see CPU use go up in a sampler without anything playing? It should not touch the CPU until its playing back samples and running its auto arranger scripts and calculating glissando time stretches in RAM, etc. I find it suspect that you open an instance and it eats 20% of your (albeit older) Xeon. Are you sure you've let it fully load before reading CPU usage? Kontakt and vsl both do that thing that everyone but me likes--loading in the background. Kontakt will call itself loaded at like 10sec...and then proceed to continue loading for another 45sec in the background--if a machine is actively loading huge samples to ram, it will register elevated CPU time during the load unless you have some really pricey SCSI drives/controllers.
And 1024? Yikes...I didn't use over 256 on occasion with a 10 year old single core P4. Let alone on the c2duo iMac, that never went above 128...I think you have something wrong.
In terms of increased CPU at idle it does do that. I tried an experiment recently measuring CPU usage and turning things on and off and you load something like Kontakt and CPU does goes up - then play or record and it goes up more. It doesn't seem a big load though compared to what I see colleagues running Logic on a laptop can run which makes me wonder whether DP's MAS is not the most efficient way of using limited resources. Interesting to try the same template with Cubase or Logic.
Well we did a not very scientific test this morning using DP7, Cubase 6 and Logic 9 running on a Quad Core Mac 2.66 10.6.6, 9Gbs RAM
In essence when running with 5 identical instances of Kontakt 5 in server mode and playing the same sequence:
Logic (64 bit) used 90%
Cubase (64 bit) 160%
DP (32 bit) 190%
DP also seemed the most erratic and spiked quite often which is where clicks and pops come from. As a life long DP user this is a little bit depressing!
So after MUCH trial and error, I think I may have tracked down where part of the problem is, although I haven't figured out the best way to fix it. I've moved all the Kontakt instances into VE Pro, leaving DP empty except for one instance of Omnisphere (which I've left disabled for the time being). The CPU meter in DP was still around 40% at idle, so that wasn't it. And everything's running in real time, no pre-gen enabling.
For the last while I've tried to do lots of routing within DP to make it easy to quickly print stems. To do this, I've run things through a couple of layers of Aux channels. For example, my LASS strings in one group, EW in another, Symphobia in a third, so as to be able to reverb/EQ them individually before sending them into through another Aux into a Strings Bus audio track (which is Input Monitored while working, then record enabled to print stems). The stems are then sent out a Master bus into one more audio track for printing the mix, for a total right around 25 busses.
I decided to try deleting some of the busses to see if that helped. I deleted about half of the busses, with a negligible difference in the CPU meter, then kept deleting one by one. With one bussed track still enabled, no real change, but when I deleted that one, the CPU meter dropped down to next to nothing. After rejoicing mightily (and prematurely), I reassigned everything out my main output, and sadly watched it spike back up to around 35% at idle. This is a little better though, so it's starting to border on usable.
Now the odd part is that with nothing loaded into DP itself except the MIDI tracks, a few busses without any processing, and everything sitting at idle, no MIDI recorded into the tracks, no audio files, DP's still hogging 53% of my computer's CPU, according to the monitor in MiniUsage. When I disable the VE tracks, theoretically freeing up the resources, DP is still using 28%. Quitting VE altogether and leaving DP open the meter is around the same.
The only other application open is Safari (so I can type this), and that's it. With the DP session project closed and nothing loaded in VE, DP uses 2.2%, and in an empty session it's around 4%. It seems strange that a bunch of empty MIDI tracks and a couple of Aux busses take that much computing power, so I'm not really sure what to make of it.
And that's where it's at. I'm at a bit of a loss of what to try next, I've got an old slave PC that I can try to bring into service, but it's probably only good to offload a small amount of the load to it.
Thanks again folks, I appreciate the ideas.
Jeff
Martin,
Will the save channel preset (corrupted file issue) on the Mac be fixed on the next release? This has been an issue for me since the first release of VE-PRO. It is a great feature, if only it worked all the time. There's no way to know when a channel preset is saved, if it will be corrupted when it's needed again.