Is it time for me to get a new computer?

[Robert_G]

I remember spec'ing out a pc rig that matched a loaded macbook pro and it came out pretty close.
Sure, you can get a tower cheaper but try it a laptop form.

If you were doing a fair comparison, do a comparison to a mac mini or mac studio.

Then post the specs for a fair comparison.

Why? The OP has made it clear that he isn't mobile. He doesn't need a laptop.

 

[musicalweather]

@aldous Thank you so much for this explanation. Very helpful! Just curious, would the "pre-load" setting be configured right within the VI's (like Kontakt), or is this something that is a computer setting?

Now on to the issue of slowdowns on my MBP. I did some experimenting last night. Unplugged my largest monitor and the kernel_task went way down. I’ll spare you all the details, but I then tried out a number of different monitor configurations. The winner seems to be closing the lid of my MBP and using three external displays. Yes, three! Kernel_task stays super low and the overall CPU load (at the bottom of the Activity Monitor) is rock bottom, even with a bunch of apps open. Booyah!

I think I still need to put this setup through its paces - have a big DP project open, with lots of plugins + VE Pro + other stuff like Safari, mail, and even Dorico. But I’m very encouraged so far. I’m still going to come up against the limits of my anemic RAM - just 16 gb! Ugh. But this discovery and resulting setup is breathing some new life into my machine. I may just be able to hold on to it for a while longer. Can’t thank you enough for your help!

Re: PCs vs. Mac. @Robert_G and others who have pointed out the price discrepancies: your argument is certainly compelling, and I’m giving it some thought.

If I wanted an all-in-one setup, it would be hard to continue considering Macs. But I’m actually content to keep what I have (VE Pro + 2 slaves), until those machines aren’t viable any more. At least that’s what I’m thinking right now.

I may try a demo of DP on one of my PC’s just to see how it feels and works. The consensus regarding DP on Windows seems to be mixed - some users find it miserable, and some are content.

The thought of becoming truly proficient in Cubase - ugh. (Although, Guy Michelmore did exactly that - went from DP to Cubase on Windows, because the cost of a Mac is so high). I would sorely miss DP’s Chunks feature, and the ability to audition highlighted midi and audio (seems like a simple thing, but I’m so dependent on it!). I’m not so much dreading the learning curve as dreading how slow my workflow will be while I learn, and the thought of tight deadlines makes me anxious.

This thread has been very helpful and enlightening. Thank you all so much for weighing in.

Also, to all, just FYI: it’s she.

 

[aldous]

@aldous Thank you so much for this explanation. Very helpful! Just curious, would the "pre-load" setting be configured right within the VI's (like Kontakt), or is this something that is a computer setting?

That's a per-VI (or per-player) setting. I don't use Kontakt that much, but as I recall instruments usually have their own setting - called "DFD Buffer" - but you can also set a Kontakt-wide override value that takes precedence. In Spitfire's player, you can set it per-product, but there's a button that propagates those settings across other Spitfire products.

Now on to the issue of slowdowns on my MBP. I did some experimenting last night. Unplugged my largest monitor and the kernel_task went way down. I’ll spare you all the details, but I then tried out a number of different monitor configurations. The winner seems to be closing the lid of my MBP and using three external displays. Yes, three! Kernel_task stays super low and the overall CPU load (at the bottom of the Activity Monitor) is rock bottom, even with a bunch of apps open. Booyah!

Excellent! Really pleased that worked, thanks for reporting back. Sounds like it was indeed spilling graphics from the GPU, then... if closing the lid fixes it, then I imagine it was having to choose a crazy scaling factor to unify the laptop screen with the externals. If closing the lid bothers you, then there's maybe something we can do about that; but better to leave things as they are otherwise, if it works for you?

 

[Guy Rowland]

That's a per-VI (or per-player) setting. I don't use Kontakt that much, but as I recall instruments usually have their own setting - called "DFD Buffer" - but you can also set a Kontakt-wide override value that takes precedence. In Spitfire's player, you can set it per-product, but there's a button that propagates those settings across other Spitfire products.

A bit off-topic, but it's a real shame Kontakt doesn't have the same flexibility as East West's Play and Opus players - you can set those preload buffers for each drive invidually there. I can't think of any case where this wouldn't be what you'd always want to do.

 

[musicalweather]

If closing the lid bothers you, then there's maybe something we can do about that; but better to leave things as they are otherwise, if it works for you?

The picture isn't quite as rosy as it seemed initially. I did have some spikes in the kernel_task yesterday with this new setup, though as I spent the evening working in DP, everything ran quite smoothly. After I finished with DP, I opened up Pigments in standalone mode and the kernel_task shot up and stayed there. I disconnected one of the smaller monitors - no effect. Then disconnected a second large monitor, the kernel task came down. I also noticed that quitting out of Pigments brought it down. When I opened Pigments back up, the kernel task went high again.

Based on my very layman's expertise, it seems that both software and hardware can cause the kernel task to shoot up. If I use heavy apps like DP + VE Pro, quit out of them, then open up another heavy app, something can go awry with the CPU. Maybe this has to do with memory leak?

I'm a bit surprised at how rapidly the kernel task can rise and fall. But at least I know how to address the problem of spikes. Sometimes it means just disconnecting a monitor. Thanks for your help.

 

[aldous]

The picture isn't quite as rosy as it seemed initially. I did have some spikes in the kernel_task yesterday with this new setup, though as I spent the evening working in DP, everything ran quite smoothly. After I finished with DP, I opened up Pigments in standalone mode and the kernel_task shot up and stayed there. I disconnected one of the smaller monitors - no effect. Then disconnected a second large monitor, the kernel task came down. I also noticed that quitting out of Pigments brought it down. When I opened Pigments back up, the kernel task went high again.

Based on my very layman's expertise, it seems that both software and hardware can cause the kernel task to shoot up. If I use heavy apps like DP + VE Pro, quit out of them, then open up another heavy app, something can go awry with the CPU. Maybe this has to do with memory leak?

I'm a bit surprised at how rapidly the kernel task can rise and fall. But at least I know how to address the problem of spikes. Sometimes it means just disconnecting a monitor. Thanks for your help.

In System Settings for Mission Control under Desktop & Dock, is "Displays have separate spaces" enabled or disabled? Also, in Battery settings, is "Automatic graphics switching" enabled or disabled?

Might be worth getting a bit of information about what the GPU is doing. See this link. Also, with Activity Monitor open, press Command+3 and Command+4, and that'll put CPU and GPU history charts on-screen. You can then repeat your experiments and take screenshots of the charts (remember to mark what changed when )

 

[musicalweather]

In System Settings for Mission Control under Desktop & Dock, is "Displays have separate spaces" enabled or disabled? Also, in Battery settings, is "Automatic graphics switching" enabled or disabled?

Might be worth getting a bit of information about what the GPU is doing. See this link. Also, with Activity Monitor open, press Command+3 and Command+4, and that'll put CPU and GPU history charts on-screen. You can then repeat your experiments and take screenshots of the charts (remember to mark what changed when )

"Displays have separate spaces" is disabled. "Automatic graphics switching" is also disabled.

Was doing just normal stuff on my computer this afternoon. I had two external monitors running with the MBP lid closed and had Safari, Mail, Calendar, Pages, and Syntorial open. Then opened Pigments and the kernel_task shot up to 550%, and Pigments was almost unusable. Took a screen shot of the CPU and GPU history at that point (see first screen shot). Then, disconnected my largest monitor, and the kernel_task dropped to about 11%. See second screen shot of the CPU and GPU stats. Just as an experiment, reconnected the large monitor again and the kernel task stayed low.

Of course, this is not an ideal way to work, although it certainly gives me a quick fix if the kernel_task is high.

I'll just add that I was being a bit sloppy by leaving some apps open. If I'm under a deadline and really working on a project, I'll close all unneeded apps to make things run optimally. But sometimes I forget to do that.

 

[aldous]

"Displays have separate spaces" is disabled. "Automatic graphics switching" is also disabled.

Those charts were helpful, thanks. I suspect having "displays have separate spaces" disabled is the underlying "cause", since it forces MacOS to render a single, huge desktop across all your screens; that's exponentially more work than rendering a desktop for each screen individually. It could be that it can just about manage to run the desktop on the GPU, but that Pigments has an interface that pushes it over the edge. That last bit is just a theory though.

I guess you previously disabled it for a reason, so it may be a matter of trading that off against the number of screens / hassle of this kernel_task issue. Only if it works, though, so maybe give it a try if it's not too inconvenient? (Just bear in mind that this may rearrange windows of applications spread across screens.)