Nice, thanks @npudar!
I just read the article and thought of an extra tip: For disabling sleep, screensaver and standby automatically, you can use Amphetamine.app which triggers automatically when GP is open. This has the advantage that in day-to-day use, your normal sleep, screen lock and screen saver settings will still apply
Yes, I did see this, it’s a great guide for users of the newest MacOS, with lots of useful tips. My MacBook is still on High Sierra because the drums were suffering from distortion, missed hits and pile-ups under Mojave, driving our drummer crazy. After that, MacOS became 64-bit only and I have a critical app (Nord Modular G2 Editor) that won’t run in that environment.
My solution is mostly script-based and relies on disabling SIP in Recovery Mode, so that you’re not prevented from disabling system processes. I’ve modified the code quite a bit since I posted it on github a couple years ago, with more things disabled and also now I run it entirely in recovery mode’s Terminal, instead of having to disable SIP (note that I’m still using High Sierra, so I don’t know if that still works on newer OSes).
I’ve saved the disable.sh and enable.sh scripts in my user bin directory, and I run them like this:
cd /Volumes/Macintosh \HD/Users/<username>/bin
Aside from running the script, I also do a few manual steps that coincide with the article you mentioned: 1) disable BlueTooth, WiFi, and Notifications; 2) tell Spotlight not to index /Volumes/Macintosh HD; 3) disable App Store’s automatic check for updates; 4) remove some login items; 5) quit some other apps that still run automatically, like SnagIt, OneDrive, Karabiner.
I haven’t done any real benchmarking. My measure of good performance is whether or not GigPerformer can successfully handle the drums and synths without dropouts and pile-ups, and this script has been a big part of that success. Aside from disabling iCloud, HD indexing and other CPU hogs (CleanMyMac X had to go!), other things that have contributed to our trouble-free G.P. performance are a better MIDI interface (MOTU micro lite), no USB hubs, and a better WiFi router. We run QLab on the same MacBook, for our video backdrop/lightshow, it connects via WiFi to an Airport Express to an Apple TV to an Optoma projector on the other side of the room. QLab’s techs told me I should never even think of running video over WiFi, and yet here we are, all this stuff now runs flawlessly on my little MacBook Pro. After several years of troubleshooting on-and-off drum kit nightmares, it’s all good now and I don’t want to mess with it!
Anyway, I’ll update the github gist with the recovery-mode scripts I’m using now.
Re benchmarking, I should add that I did a lot of system load testing to try to find the sources of system slowdown/contention, and I even had Activity Monitor’s CPU History and Memory Pressure meters running at gigs. Unfortunately I never saw anything that could explain the drum kit distortion, dropouts and pile-ups, which were too short to register (but no less aggravating in a live show).
For people that are on more recent versions of macOS (and have System Integrity Protection enabled), here is a “lite” alternative to @therealgps’s script: Two shortcuts for Shortcuts.app. They do most of what the blog article recommends:
I was finally able to upgrade my MacBook Pro to Big Sur, and now I have a script that runs on the latest macOS versions, successfully disabling all the processes that tend to interfere with our stage setup (GigPerformer 4 and QLab). Because I have a non-Apple system drive (an OWC SSD), the Monterey installer refuses to run, so I am stuck with Big Sur. But I’ve tested the script on Monterey in a Parallels 17 virtual machine, and it works just fine. You can find it here: Disable Big Sur and Monterey services · GitHub
I also disable spotlight indexing and automatic software updates, and kill some still-running processes - see the Comments section.