# What is causing single core CPU spikes in Logic?



## mybadmemory (Aug 27, 2018)

Hi all!

I'm on a 2017 iMac, 3,6ghz i7, 32gb ram, SSD with the latest Mac OS and the latest Logic Pro.

I'm having issues with sudden single core CPU spikes, mostly during live playing of VI's, but occasionally also on playback. The first 7 cores are low but the last one (to the right) suddenly pops to 100% for a second or so causing clicks and pops. 

I've tried two different interfaces as well as no interface at all so it does not seem interface-related, but rather something to do with the Mac, Logic, or some plugin I'm using.

I've also tried all variations of the settings for processing threads, process buffer range, and multithreading without result.

I was not expecting performance issues with just a few (5-15) VI tracks on a machine like this. Is this common, and what might be causing it?

Cheers!


----------



## mybadmemory (Aug 27, 2018)

Oh and the problem occurs even if the song is not playing, if I live play on a VI track, so I guess it has more to do with live playing than playback.


----------



## Loïc D (Aug 27, 2018)

Hi, hard to tell without further details...

Are you using multitimbral Kontakt instances by chance ? This CPU behaviour is quite typical.

I'd recommend to freeze tracks and see how your CPU is calming down, or toggle plugins on/off.
Maybe you'd be able to spot a specific plugin or instance.

And I second your analysis : it's very unlikely an interface issue. Buffer size might tame the overhead a little bit, but it's not your main source of trouble.


----------



## gsilbers (Aug 27, 2018)

try changing the setting in prefs where it says playback all tracks & live tracks. maybe that helps?


----------



## Saxer (Aug 27, 2018)

Look at charlieclousers clarification:
https://vi-control.net/community/threads/gothic-instruments-dronar-questions.73958/page-3


----------



## sluggo (Aug 27, 2018)

There have been issues with graphics and the dreaded single spike. Change your monitor resolution to a lower resolution and then see if there is better performance. This was a known bigger problem a while ago and it seems like newer updates have addressed the issue, but everyone's system is different.


----------



## mybadmemory (Aug 27, 2018)

I think I've found Kontakt to be the bad guy here. For projects that only use exs24 I don't seem to get the spikes (and the overall CPU hit is also substantially lower).

As soon as I have an instance of Kontakt in a project, I get the occasional spikes while playing any track live. And overall Kontakt seem to be consuming an AWFUL lot of CPU power.

With 11 instances of Kontakt Player (using CineSymphony Lite), my CPU usage is at over 80% both in logic and in the Activity Monitor at simple playback. If I try to live play any track by midi I get immediate spikes causing clicks and pops. This should not be the case with a maxed out 2017 iMac, right?

How many instances of Kontakt should I be able to run on such a machine (3,6ghz i7, 32gb ram, SSD)?


----------



## JamieLang (Aug 27, 2018)

When you record enable a track, everything in that channel, and every aux its sent to is put onto a single thread in the low latency secondary buffer.

So, say youre playing a Keyscape C7 to some Abbey Road reverb(on an aux like god intended)....the C7 and the reverb aux have to be done on one thread, even if you have 12 or 24.

Its important to KNoW this so you can A)set up a dummy track with no inut or sends to “rest” the cursor on... and B) in the above instance, you would simply disable the send to Abbey Road while you play the part....and AR will go back to whatever thread(s) it was being processed with, and only the Keyscape instance gets put on the one core.

And as with ALL VI “performance metering going over”....the core of the CPU might not BE the reason it cant make the buffer and “overs”....its every bit as likely, sticking with keyscape that its waiting on a drive to stream, not the CPU “core” itself.

I found in my time with logic that this behaviour makes it fucntionally more resource heavy to play a VI live than in say Cubase, which also double buffers.


----------



## EvilDragon (Aug 27, 2018)

mybadmemory said:


> And overall Kontakt seem to be consuming an AWFUL lot of CPU power.
> 
> With 11 instances of Kontakt Player (using CineSymphony Lite), my CPU usage is at over 80% both in logic and in the Activity Monitor at simple playback. If I try to live play any track by midi I get immediate spikes causing clicks and pops. This should not be the case with a maxed out 2017 iMac, right?



Kontakt by itself is a really efficient sampler, so I'd take a look at the library and what it's doing and if it can be improved/optimized (of course, that's up to the developer).



mybadmemory said:


> How many instances of Kontakt should I be able to run on such a machine (3,6ghz i7, 32gb ram, SSD)?



You cannot expect a firm number, due to above. It all depends on the library/libraries you're using and how intricate/taxing they are.


----------



## LamaRose (Aug 27, 2018)

This issue has been so well-beaten that the _horse_ carcass has long since disappeared. The problem is APPLE. No one can figure out what the deal is with fixing this annoyance.

Create an audio track and try playing with both the audio & midi tracks enabled. This MIGHT help during recording. Just clicking on the audio track usually helps during playback.

Definitely check your buffer size in preferences... 256 _works_ for me. Make sure "playback & live tracks" is ticked in the same preference window. I have my buffer range set to medium.

And of course, some libraries are flat out CPU-intensive... and when everything hits one core, something else hits the fan.


----------



## mybadmemory (Aug 27, 2018)

Thanks for the replies guys!

Yes resting on audio tracks does seem to help with the spikes as they occur during either live playing or toggling between different tracks. And also not using Kontakt helps a great deal. This is of course not optimal though. 

So should I just accept this behaviour as normal? You don't think my overall CPU hit seem high at above 80%, with ~10 instances of Kontakt running SineSymphony Lite (which is supposed to be a lite library for mobile use). I was certainly expecting to be able to run more than this on my machine! (In the defence of CineSymphony it does seem to happen with all my Kontakt instruments though, as well Logic's own new StudioStrings and StudioWinds).


----------



## EvilDragon (Aug 27, 2018)

Check your power profile, perhaps it's throttling your CPU speeds? DAWs really don't like that happening.


----------



## JamieLang (Aug 27, 2018)

LamaRose said:


> This issue has been so well-beaten that the _horse_ carcass has long since disappeared. The problem is APPLE. No one can figure out what the deal is with fixing this annoyance.


No one?


----------



## Loïc D (Aug 27, 2018)

If you’re really stuck in spite of all the good tips here, you might want to freeze tracks to free CPU load.
It’s efficient.
That said, your machine is recent and powerful and I’m surprised that you manage to reach the limit with so few instances...


----------



## LamaRose (Aug 27, 2018)

Noticed that you're using Kontakt Player vs full Kontakt... most of us here are using the full version, so maybe there's a particular issue with Player. To answer your general question: you should be able to run a lot of instances with your machine. 

Try using Activity Monitor to track background CPU usage. Also, how is your Kontakt performance in stand alone mode - outside of Logic?


----------



## MarcelM (Aug 27, 2018)

have you tried to turn the convolution reverb off in cinesymphony lite? i guess its enabled by default?


----------



## jcrosby (Aug 27, 2018)

mybadmemory said:


> Hi all!
> 
> I'm on a 2017 iMac, 3,6ghz i7, 32gb ram, SSD with the latest Mac OS and the latest Logic Pro.
> 
> ...



Found this video yesterday while trying to decide whether I pull the trigger on the new MBP... Anyway, sounds exactly like what you're describing. He shows it happening cyclically every 60 seconds, even when idle. He also has Console open and looks at all of the processes running...

Although he doesn't have a solution or a solid answer as to which process he's definitely on to something that Apple need to look into... Seems to be OS related, basically a garbage background process chewing up CPU cycles.


----------



## EvilDragon (Aug 28, 2018)

LamaRose said:


> Noticed that you're using Kontakt Player vs full Kontakt... most of us here are using the full version, so maybe there's a particular issue with Player.



Nope. They're exactly the same code, just different license.


----------



## LamaRose (Aug 28, 2018)

jcrosby said:


> ...cyclically every 60 seconds, even when idle...




This could be the OS performing auto backup(s). 

Another tip I forgot to mention is shutting down other programs, including browsers, whilst working in Logic... I forget to do this all the time, but it always helps to some degree.


----------



## Nick Batzdorf (Aug 28, 2018)

Are we back to the days when it was advisable to turn off the Mac clock to save CPU horsepower?

The Mac Extensions Dance, in which you keep removing half of them until you narrow down the culprit?


----------



## jcrosby (Aug 28, 2018)

mybadmemory said:


> Hi all!
> 
> I'm on a 2017 iMac, 3,6ghz i7, 32gb ram, SSD with the latest Mac OS and the latest Logic Pro.
> 
> ...


Just curioius, did this start after the last OS update? (Or anything else that may have changed in your setup?)


----------



## Soundhound (Aug 28, 2018)

I just had an acid flashback reading that line about Mac Extensions. Maybe life has gotten better after all. 



Nick Batzdorf said:


> Are we back to the days when it was advisable to turn off the Mac clock to save CPU horsepower?
> 
> The Mac Extensions Dance, in which you keep removing half of them until you narrow down the culprit?


----------



## sourcefor (Aug 28, 2018)

Yup I get this spike as well with my 2017 MacBook Pro on Sierra..I wish there was a fix other than adding a dummy audio track, which seems to help a bit! I wonder if it’s just Kontakt , etc. and not logic internal instruments? I also get sample rate not recognized errors as well , wtf is with these computers not workin the way they are supposed to.?! My system should be able to handle 20 sample tracks with no problems!


----------



## sourcefor (Aug 28, 2018)

Is it safe to go to High Sierra or better to stay on Sierra?


----------



## jcrosby (Aug 29, 2018)

sourcefor said:


> Is it safe to go to High Sierra or better to stay on Sierra?


Although I'm not on HS yet, everything I've researched suggests it's basically the same story on 10.12 and 10.13... (the video I linked to was a guy in 10.13... He was also experiencing issues with Keyscape so it's not isolated to Kontakt...)


----------



## ewtwolf (Sep 1, 2018)

jcrosby said:


> Found this video yesterday while trying to decide whether I pull the trigger on the new MBP... Anyway, sounds exactly like what you're describing. He shows it happening cyclically every 60 seconds, even when idle. He also has Console open and looks at all of the processes running...
> 
> Although he doesn't have a solution or a solid answer as to which process he's definitely on to something that Apple need to look into... Seems to be OS related, basically a garbage background process chewing up CPU cycles.




That is my video. I have since gotten to the exact issue of _why_ this happens and have a hack for MBP users. I've tested this on both High Sierra and the latest Mojave beta where the battery bug still exists.

So first off, it is important to understand how OSX handles system processes. When these are coded they can be setup as single threaded or multithreaded. The catch is, single threaded processes within the same framework all use the same core. On the development side, this is part of something called a WorkLoop. So for example, most kernel level tasks exist within the Apple IOKit framework as it has the system management bus under its umbrella. This is also where CoreAudio lives. That is key, because it means anything set in code for single thread processing, that is part of the IOKit, all goes on the same core together.

Most low level system processes are single threaded, like the AppleSmartBatteryManager.kext driver, and the BIG issue with Macs and ProAudio work, is active live tracks in your DAW, the one taking active input whether it's midi triggering a soft synth or live audio coming into a FX chain, those processes are single threaded. It's just how the OSX CoreAudio architecture works. By putting the process on a single core, it maintains integrity and things can get done at a lower latency. This is why you see in Logic Pro for example, the first core in its cpu meter running really high for your active track compared to the other core meters. Logic will multithread the other tracks not taking live input. Remember for Logic, the complete signal path of your active track gets put on the first core. So if you have fx on your master bus, those fx get put onto the single core, as do any other buses the track might be routed through.

So this setup typically works ok. The OS system has a scheduler that gets populated from the IOKit workloop, and it assigns the processes to the CPU. So if you look at your console and see all those processes running and notice the time stamp, you see we are dealing with things happening in very small fractions of a second. The scheduler commits processes to the CPU typically in an asynchronous manner, where one driver might have several processes associated with its active cycle, but each of those get layered against others:

Driver1 - Process 1
CoreAudio - Process 1
Driver2 - Process 1
CoreAudio - Process 2
Driver1 - Process 2
CoreAudio - Process 2
Driver2 - Process 2
CoreAudio - Process 3


So in this scenario the time difference from one event to the next is negligible in terms of audio processing. However, some system drivers can lock the core so only their commands get run for its cycle. This is what the battery manager is doing:

CoreAudio - Process 1
SmartBatteryManager - Command 1
SmartBatteryManager - Command 2
SmartBatteryManager - Command 3
SmartBatteryManager - Command 4
SmartBatteryManager - Command 5
SmartBatteryManager - Command 6
SmartBatteryManager - Command 7
SmartBatteryManager - Command 8
SmartBatteryManager - Command 9
SmartBatteryManager - Command 10
CoreAudio - Process 2 - IOWorkLoop - Skipping Cycle due to Overload <--- This would be the moment that the coreaudio exceeded its low latency buffer time and you get an audio dropout

The battery manager is using super old code, from 2005, before we had a lot of multicore laptops. And it uses a poll() coding method that isn't efficient for multicore systems, because it locks out the core, and typically runs a long command cycle. Basically nothing else gets through to the core until it finishes the commands. CoreAudio has a buffer setting, and if you run a low setting, you essentially limit the time it can wait. But since it can't get its process into the cpu core, you receive a Skipping Cycle due to Overload and get an audio dropout and glitch sound.

Other processes can activate that locking priority too, but most run shorter cycles, non poll() methods. But these are things to look into. I try and disable things like iCloud, BlueTooth, wifi, notifications, Siri, etc... Any third party apps like fan controllers, or battery apps, stuff that runs on the System Management Bus (SMBus) will cause issues sharing the core within IOKit workloop tasks.

TL;DR - Ok that out of the way this is the hack:

The MBP battery hack is pretty simple. You will basically trick OSX into thinking you are running a desktop Mac.

First make sure you are plugged into the AC Adapter. You also need to disable SIP (System Integrity Protection) to have access to change the system files. Restart the MBP and hold Command+R before the Apple Logo appears, and boot into Recovery Mode. At the menu bar, select Utilities>Terminal and type this command and hit Return:

_csrutil disable_

Restart your MBP and login

Open Finder and go to System/Library/Extensions/AppleSmartBatteryManager.kext

Right Click>Rename

Change .kext to .xkext and enter your password

Open Terminal and type this command and hit Return:

_sudo kextcache -system-caches_

Enter your password

This will flush the driver caches. It takes ~15-20 seconds. You will get a new Terminal prompt when it completes.

Once complete, Reboot your MBP

When you log back in you will no longer have a battery readout. You can verify the hack by opening Terminal and typing this command and hit Return:

_pmset -g batt_

This typically tells you the state of the battery charge. It should read "AC Power" if the hack worked.

To undo the hack, simply rename the .xkext extension back to .kext, run the _kextcache -system-caches_ terminal command again, and reboot.

***Don't forget to turn SIP back on once you verify the hack, through booting back into Recovery Mode Utilities> Terminal: _csrutil enable _and Reboot_***_

So the downsides of the hack is you get no battery status in OSX, so I don't recommend running it while you are on battery power only. You also lose your energy saving features.

The upside is the battery driver doesn't cause the coreaudio dropout in this mode. The battery power state is maintained by an embedded controller in its hardware, so OSX doesn't actually control the charging or power distribution. This is the reason you can charge your MBP with it powered off. Also the thermal management is not affected by this, and the battery temp sensors are still active. I bought a simple usb-c power meter that I connect to my MBP port and plug the power adapter cable into it, giving a readout of the voltage and current. Everything looked normal with ~ 2x more current when the hack was active vs without. Voltage remained constant between both setups.

This is obviously a hack messing around with system files, so do this at your own risk. There is potential here for corrupting the OS or instability. For my system, I've run this setup for several days with no issues. I'm on a 2018 MBP i9 32GB 1TB SSD with a RME BFP.

There are a few other services I've noticed that can cause some coreaudio related issues, and might help desktop users too. These are the watchdog events and apsd (Apple Push Service Daemon). I'm still experimenting with turning those off. I'll report back if I can remove them without any issues.


----------



## ewtwolf (Sep 1, 2018)

Just to clarify, Logic Pro is more likely to encounter the battery issue consistantly every time it runs, since Logic always places the active track onto the same processing core used by the system. Ableton, Cubase, Reaper tend to multithread things a little better, but they don't overlook the system core - all are fair game for getting processes assigned. So potentially the cpu event scheduler could put your Cubase/Ableton active track process onto the same core, and then it gets the overload event when the battery manager driver polling kicks in. So less frequency of the overload with the other DAWs, but still a problem.


----------



## Saxer (Sep 1, 2018)

ewtwolf said:


> ...since Logic always places the active track onto the same processing core used by the system.


I don't think that's the case. It's just the way Logic shows the active core. If you open the Activity Monitor you can see that Logics activity jumps from core to core.


----------



## ewtwolf (Sep 1, 2018)

The Active track that is taking input, is shared on the same core as any IOKit workloop processes. Any additional tracks that aren't actively selected get multithreaded.


----------



## ewtwolf (Sep 1, 2018)

Also, yes the core in use for single core processes can change, The Logic meter isn't a direct representation to the cores shown in the ActivityMonitor. However, once the event scheduler assigns the process to a core, the process stays there. So yes, you would see the cpu movement on different ActivityMonitor cpu meters, some of that is multithreaded background Logic Pro processes, and some is other system stuff. Active track processes will be confined to one core tho, whichever one the scheduler assigns it too, at the same time and core it assigns anything else in the IOKit workloop. Other system processes not in the IOKit framework might get scheduled onto different cores at the same time, depending on their scheduler:

Page 78 talked about WorkLoops within the IOKit framework:
WorkLoop Apple Dev Documentation

IOAudioEngine Documentation

One of several source code files for the battery manager showing poll() method and workloop.
AppleSmartBatteryManager.cpp 

https://pdfs.semanticscholar.org/presentation/cc6e/55a8e9dd9d084af1af0f9ae45c5a87cf0f40.pdf (Interesting read on CoreAudio and different buses p26)

AppleSmartBatteryManager uses this:
_command gate: A mechanism that controls access to the lock of a work loop, thereby serializing access to the data involved in I/O requests. A command gate does not require a thread context switch to ensure single-threaded access. IOCommandGate event-source objects represent command gates in the I/O Kit._

IOKit single-thread stuff all goes into the same workloop:
_workloop: A gating mechanism that ensures single-threaded access to the data structures and hardware registers used by a driver. Specifically, it is a mutex lock associated with a thread. A work loop typically has several event sources attached to it; they use the work loop to ensure a protected, gated context for processing events._


----------



## jcrosby (Sep 1, 2018)

ewtwolf said:


> That is my video. I have since gotten to the exact issue of _why_ this happens and have a hack for MBP users. I've tested this on both High Sierra and the latest Mojave beta where the battery bug still exists.
> 
> So first off, it is important to understand how OSX handles system processes. When these are coded they can be setup as single threaded or multithreaded. The catch is, single threaded processes within the same framework all use the same core. On the development side, this is part of something called a WorkLoop. So for example, most kernel level tasks exist within the Apple IOKit framework as it has the system management bus under its umbrella. This is also where CoreAudio lives. That is key, because it means anything set in code for single thread processing, that is part of the IOKit, all goes on the same core together.
> 
> ...



Small world  Thanks so much for posting this. I bought an i9 Friday, waiting for it to arrive... Definitely good advice, I'd clone or TM my system before monkeying with an system level kext files anyway... Also great pointers about other background processes. I disable just about everything you mentioned, however I typically run iStatMenus to monitor temperature. Looks like I'll skip installing it, at least for the time being... Much appreciated.

I also wonder if this is part of Logic's longstanding One Core Curse? I.e. if it uses the same core as background processes it seems like it should be related, and perhaps updating Logic's code so that it prevents it from using the core designated for background processes as a core available for active tracks...

Have you spoken to anyone at Apple about this? I'd imagine if you contacted their Pro Apps department they'd do the best they could to get some eyes on the issue.

Also curious... Assuming you've worked previously on MBP's, wondering if you find you get a higher overall instrument/plugin count, (in terms of CPU efficiency), on the i9 than previous MBP models. (Disregarding the dropout issue obvioulsy...) If so, curious if you think it's a subtle improvement, or fairly substantial?

Cheers, and thanks again for all the research...


----------



## ewtwolf (Sep 3, 2018)

Yeah, I submitted a bug report through their development side, #43737017, related to testing this on Mojave 10.14, but mentioned it also exists in High Sierra. They did respond asking for additional system logs. I also had a support request through Logic Pro and spoke several times with a senior specialist there named Chris. I sent him my video, and he took detailed notes, and passed it on to the development team. He's been great, even calling me when the latest MBP firmware came out to test if it fixed things -- unfortunately it did not.

So the issue is in part how Logic is coded, but more an OSX architecture issue. Logic Pro puts anything that the live active track's signal goes through on the same core. So any fx, even if they are on other buses, all get processed on the same core. This is really due to the OSX IOKit framework. Without seeing the actual source code for the various DAW's, it's hard to tell what they do different. I would guess maybe the buffering is better in other DAWs -- Cubase for example with its ASIO guard. Or maybe it is somehow they multithread the signal chain better. Or maybe set their thread priority differently. It looks like based on Apple dev docs that real-time audio will always be on a single core shared with the IOKit system bus processes, it is just a matter of if that single core is also running other higher priority system tasks that run longer than the audio buffer. If you are interested, this video is a presentation from one of two original architects of the IOKit framework. He explains how the priority bands and workloop function from a driver perspective 

This link has the slides he used: http://www.cse.unsw.edu.au/~cs9242/06/lectures/09-IOKit_Threading.pdf Interestingly at 29:35 he mentions that using the poll method is not recommended. Which is what the battery manager uses. I think whichever third party supplier designed the battery controller chip, also did the poor code.


----------



## sourcefor (Sep 3, 2018)

Thanks for all this info, I guess we just have wait for a recode of logic ?? Does anyone also get MIDI timeout issues and how do you correct this as well. Sorry to hijack but you guys seem to know whats going on.?!!


----------



## ewtwolf (Sep 3, 2018)

I have had midi timeout issues. Like a stuck note fairly random. It could be related. Haven’t tested for it.


----------



## mybadmemory (Sep 4, 2018)

I just noticed that my singe core SPU spikes are MUCH worse after waking the computer up from sleep than after a full reboot. It does however get substantially better if I just restart CoreAudio by changing the buffer size and hitting Apply.

Nice to have found a "fix", but still annoying to have to do this every time I wake the computer up (since I pretty much never turn it off but rather send it to sleep).

Have anyone else noticed this? Could any of the energy saving settings affect that some process need to restart after sleep?


----------



## ewtwolf (Sep 4, 2018)

I haven't noticed that, but I have noticed Safari is a turd with CoreAudio. I do not recommend having it open in the background, and definitely not browsing with it while streaming audio, like youtube or iTunes. I get a lot of dropouts even with my battery hack with Safari running. Seems like the webkit services Apple has for Safari can overload CoreAudio. I've been trying the Opera browser without any issues. Haven't tried the others like Chrome or Firefox yet.


----------



## ewtwolf (Sep 4, 2018)

Even with the battery hack, bigger sets in Ableton are still glitching out with CoreAudio overload events. I've tried turning off additional services through Terminal, but things just get too unstable. OSX just needs a major overhaul for CoreAudio. What a pain digging into all this. So the best fix I have found is installing Windows 10 Pro through Bootcamp. Rock solid. Seriously, no glitches, no hacks needed. 64 sample size buffer in Ableton runs perfect with my RME BFP. I guess I now own a very expensive Windows laptop. Hopefully Apple gives the bugs some serious work, otherwise I'm calling it, Pro Audio DAW work on a Mac just sucks. Bootcamp was a turd to install too. The software kept timing out on download through the Bootcamp assistant. Now that it is installed though Windows works awesome. Left a 200GB partition for OSX in case I need to install another firmware update.


----------



## Jeremy Spencer (Sep 4, 2018)

A great way to distribute core loads more efficiently in Logic is to use VEPro.


----------



## mc_deli (Sep 4, 2018)

Use fewer auxes, delete all bus plug ins... delete all auxes when you get desperate... don't use multi instruments... because they make auxes... and they pile it on core 1...

I'm surprised by the OP. This has been around for ages and I have read hundreds of posts on it. The hack is new, though that is too saucy for me!


----------



## ewtwolf (Sep 7, 2018)

I did a quick 1:30ish video covering my MBP and Mac general OS X hacks to minimize background processes causing CoreAudio issues. I'm able to run a decent sized Ableton session at 64 sample buffer, while QT screen capturing no less. Hope this helps out anyone with OS X woes.


----------



## sourcefor (Sep 10, 2018)

Is it safe to turn all the stuff off.? I may try it before I buy a new 2018 MacBook!


----------



## ewtwolf (Sep 10, 2018)

High Sierra’s APFS file system is actually helpful in this. You can easily create a new volume, without partitioning the drive, that dynamically shares the drive space. Then easily install a fresh version of OSX on the new volume using internet recovery mode. So I have one boot volume where I removed everything, and another that is clean. If I need to I can always delete the hacked OS X volume. My steps are reversable in the hack so shouldn’t cause any permanent issues if you don’t want to dual boot. I ended up removing more things so the dual boot is my safety in case I go too far.


----------



## willronnorth (Oct 22, 2019)

Hello you poor, suffering humans.

Let me know how you get along with this workaround (providing you how a powerful enough machine to apply this)

So I have the newest version of Logic Pro 10.4.7 running on Mojave on my iMac 2017, 21.5 4K, i7 3.6ghz quad-core, 16GB RAM. 

I found generally when facing this 'live-track thread-hog' issue that it seems to ONLY draw from the 2nd thread on the 4th core (8th meter in the performance meter - correct me if I'm wrong) HOWEVER - When going into my audio settings and clocking the processing threads down to *6* (3-cores) that the issue appears to go disappear and my thread usage seems to be evidently more balanced. The only thing to note is that this will push the active 6 threads harder as the load is no longer balanced over 8 threads. 

I have no idea whether it decides to balance everything on 6 threads and then use the remaining 2 (behind the metering) for the live-track or not, but it works perfect for me. 

Let me know how you guys get along with this workaround and I do hope it works for you all.


----------



## jcrosby (Oct 24, 2019)

willronnorth said:


> Hello you poor, suffering humans.
> 
> Let me know how you get along with this workaround (providing you how a powerful enough machine to apply this)
> 
> ...



Logic reserves that specific core for live mode, i.e. you'll continually see Logic reserving the same core for live input. Your two options are choosing either 'playback tracks' or playback and live tracks' in the multithreading option. It's just part of how logic works...


----------



## mybadmemory (Jan 3, 2020)

As of the latest updates (Logic 10.4.8 and MacOS Catalina 10.15.2) I'm no longer experiencing the dreaded single core spikes.

As a bonus the entire efficiency of the program seem to have been immensely improved! My CPU hit is substantially lower than it has ever been, and my reported latency is lower as well.

Fingers crossed the next update won't change this back. :D


----------



## Ashermusic (Jan 3, 2020)

mybadmemory said:


> As of the latest updates (Logic 10.4.8 and MacOS Catalina 10.15.2) I'm no longer experiencing the dreaded single core spikes.
> 
> As a bonus the entire efficiency of the program seem to have been immensely improved! My CPU hit is substantially lower than it has ever been, and my reported latency is lower as well.



I too thought I was seeing this, but I wasn't sure it wasn't just wishful thinking on my part.


----------



## Kent (Jan 3, 2020)

Ashermusic said:


> I too thought I was seeing this, but I wasn't sure it wasn't just wishful thinking on my part.


Are you on Catalina too, Jay?


----------



## Ashermusic (Jan 3, 2020)

kmaster said:


> Are you on Catalina too, Jay?



Yes.


----------



## double-m (Jun 12, 2020)

Hey guys,

very interesting topic and usefull related posts here..

Not that sure if Catalina and the Logic 10.5.0 has solved these single Core/Thread peaks in any way.

I just finished the installation and setups of my new Mac Pro (2019 /16 Core).
After using my last Mac Pro since 2008 it was time for a bigger upgrade and i expected a huge push of performance.
But i was simply SHOCKED when testing around with the new machine (see screenshot).

Next i have to test some different workflows and channel management on Logic as discussed in this frorum thread. For example the topic about the selected Live Channel. Which is also suggested by Apple.

i found an older Apple article about improving multi processor threads. Apple suggested to divide plugins from a chnannel into busses and aux channels. Since each channel can address one core only.
But i´m just not sure how about busses and aux channels related to each other.
I also saw on the Apple desription that the Stereo Out were left blank, without any plugins.
The plugins from the Stereo out were also placed on different busses.

But @mc_deli pointed in this thread better to delete all busses and aux channels, which seems to be opposite to the statement if have found from Apple.

I also will test differenet core settings in Logic.
Maybe i have to reduce all 16cores /32 Hyperthreads to whatever instead of using automatic mode.

As a mastering engineer i have to handle with a lot cpu heavy plugins.

Here is a link to the Apple article, but its german..





Logic Pro/Express: Tipps zum Ausgleichen der Multi-Core-Leistung


Logic Pro und Logic Express 8 oder neuer können auf Mac-Computern mit 2, 4 oder 8 Kernen alle Kerne verwenden. Beachten Sie die folgenden Tipps zum Ausgleichen der Leistung auf einem Multi-Core-System, wenn Sie mit Logic arbeiten.



support.apple.com





Screenshot workflow setup:
8 Audio tracks with light processing running into 4 busses with more heavy mastering plugins.
Plugins on stereo out as well.

increasing the buffer has not fixed this cpu peak !


If you got any ideas how to fix this, please let me know.
I will follow up with my testing results as well soon.

Thanks peepz and happy weekend


----------



## jcrosby (Jun 12, 2020)

double-m said:


> Hey guys,
> 
> very interesting topic and usefull related posts here..
> 
> ...



The spikes are partially due to live mode. (Logic drops the buffer on armed tracks). That said that is beyond extreme, especially being that those are audio tracks...

I'd get support on the phone ASAP, and specifically ask to speak to someone in _pro apps_. They should ask to document the issue, then forward the issue to software engineering. It may take a few calls to get some kind of answer, if they don't offer an explanation ask to file a complaint with _customer relations_ right then and there...


----------



## Dewdman42 (Jun 13, 2020)

create a "dummy" track in your project that doesn't have any plugins on it and make sure it is selected before you hit PLAY (unless you are recording, then of course you have to select the track you're recording to),


----------



## IFM (Jun 13, 2020)

What Dewdman42 said. From the look and sounds of it Logic is trying to live process all your aux tracks in live mode no matter what.


----------



## jcrosby (Jun 13, 2020)

That still seems extreme for 8 tracks and 4 auxes.

What exactly do you have on your stereo bus? And what's on each aux?
What sample rate and buffer is the project set to?
And are you running multiple Acustica plugins, or IK Tapes on the mixbus or auxes by any chance? (Loading up the stereo bus with a ton of heavy plugins can cause this kind of spike depending on what you have inserted... Hence me asking about Acustica and/or IK Tapes as these can choke out any CPU.)

Also try switching from _Playback and live tracks_ to only _playback tracks_ to see if the spike drops down at all. (In Logic's preferences.)


----------



## LamaRose (Jun 13, 2020)

I read somewhere that the CPU improvement - at least with Kontakt instruments - was due to K6? Anyone using K5 with Catalina? I'd rather upgrade to Cat than K6 to improve this very longstanding issue. But Caesar will ultimately have his tribute one way or another.


----------



## double-m (Jun 13, 2020)

jcrosby said:


> The spikes are partially due to live mode. (Logic drops the buffer on armed tracks). That said that is beyond extreme, especially being that those are audio tracks...
> 
> I'd get support on the phone ASAP, and specifically ask to speak to someone in _pro apps_. They should ask to document the issue, then forward the issue to software engineering. It may take a few calls to get some kind of answer, if they don't offer an explanation ask to file a complaint with _customer relations_ right then and there...



Thanks mate, pleas let us know when you got any useful feedback from customer relations. Maybe i will open a case as well.


----------



## double-m (Jun 13, 2020)

Dewdman42 said:


> create a "dummy" track in your project that doesn't have any plugins on it and make sure it is selected before you hit PLAY (unless you are recording, then of course you have to select the track you're recording to),


Thanks mate, will try this asap.


----------



## double-m (Jun 13, 2020)

jcrosby said:


> That still seems extreme for 8 tracks and 4 auxes.
> 
> What exactly do you have on your stereo bus? And what's on each aux?
> What sample rate and buffer is the project set to?
> ...



On the audio channels is not much happening. Just some low/medium cpu heavy plugins.
The auxes are fillded with dynamics, eq´s, saturation tools and Ozone 9, which is a big cpu bummer.
On stereo out are just some reference and measureing tools plus Sonarworks Studio.

The crazy thing is, this setup is very similiar i worked with on my old Mac Pro from 2008.
The old Mac Pro could handle this kind of projects, but on limit of course.
That made me shocked when i saw this huge peak on the new machine.
Like i said Ozone 9 takes at least about 30% of this peak.


----------



## jcrosby (Jun 13, 2020)

double-m said:


> Thanks mate, pleas let us know when you got any useful feedback from customer relations. Maybe i will open a case as well.


I've had different issues with Apple support, (MBP Glitching audio). I'm basically explaining the process you want to go through if you're experiencing abnormal behavior. If none of the above suggestions causes the spike to drop you should phone support and go through the same steps I had to go through before.

I had 3 separate incidents on my 2018 MBP, all of which were fruitless. At that point you need to be persistent and file complaints. When people fail to follow through and utilize customer relations to lodge a complaint Apple are more likely to just keep shoving sloppy software and/or poor hardware out the door... I don't want to derail the thread but I had a very long conversation with someone in Customer Relations who actually took the time to explain that this is one of the reasons why the butterfly keyboard issue resulted in a 'repair program'.... TLDR: If people don't complain through the proper channels Apple doesn't get put in check..




*THAT SAID*: This is a lot of CPU heavy processing. If you're not familiar with how Logic distributes real time processing across cores, (or what can cause the bulk of your processing to wind up on a single core) you can see behavior like this. Without knowing what you have inserted where it's hard to gauge if Logic is misbehaving or you 're simply asking Logic to do most of the work on one core.

IIRC the mixbus is tied to the same core as live mode. (frankly I've always found this a bit hard to fully wrap my head around, @Dewdman42 probably understands this better, and can explain it in more detail than I can..) Regardless, there are certain cores that you will frequently see spikes on depending on how your processing and routing are set up. (This isn't unique to Logic either. In the Live 10 beta Ableton confirmed Live behaves the same way...)

Anyway.. If I keep my mixbus processing to a realistic level and distribute more of my processing across tracks, CPU is much more evenly spread and core spikes aren't as severe. I'm also more likely to see smaller spikes on more than one core instead of one massive spike on a single core.

The one thing I know for sure is that if you load up the _stereo out_ track with a ton of CPU heavy plugins you're asking Logic to do most of its real time processing on a single core. This is where clock speed becomes an important factor... And, if you put a huge load on the mixbus there is a tipping point where using a dummy track won't really do a whole lot for you... I also believe auxes share this same thread but may be wrong about that...

The point is that you should divide processing across tracks as frequently as possible. you'll see a much better distribution across cores. And if you start loading up auxes and the mixbus with CPU hungry plugins you will hit a point where you have a spike like this and even the dummy track trick doesn't help..


----------



## Dewdman42 (Jun 13, 2020)

In general I will say, first of all, avoid using iZotope and other cpu heavy plugins while recording tracks. Not only will they hit the CPU hard, but they will also usually have latency, which sucks while recording. Just get used to using less FX or temporary fx while recording the tracks...FX that have low cpu and low latency.

Once your track is recorded, avoid having it selected while playing back, because whenever it goes into LIVE mode, difficult things happen with cpu thread allocation. LogicPro is attempting to minimize latency that way and its a good thing what LogicPro is doing, but if you mis-use it, then you might end up with a spiking cpu core.

There is a lot we don't know about LPX thread internals, we can only make some guesses. That article talks about spreading plugins across AUX channels in order to use more threads, but its not clear to me that will happen when a track is in LIVE mode and for various technical reasons I won't go into now, my thought is that no it probably won't. In LIVE mode, a track that is chained through a serious of AUX channels will probably have all of the signal chain isolated on a single thread.

If its not LIVE, then its possible LogicPro will use more multi-threading strategies as it sees fit to utilize cores as best it can. 

When no track is in LIVE mode, you can mix down a LOT of tracks with a lot of plugins, using a large buffer, and even my acient Cheesgrater can do it. The new MP should be having absolutely no problem with mixing down any combination of tracks and AUX channels with plugins galore. But not if its in LIVE mode..and what ever that article said about chaining up AUX channels, I'm skeptical about to be honest, especially with source track in LIVE mode.


----------



## Dewdman42 (Jun 13, 2020)

I just ran a quick test and have some conclusions about multi-threading, they line up with what I said above, but here are pretty pictures from the test.

First... I just used a simple example with Diva as an instrument on a track, with a couple of izotope plugins on the same track to add some CPU use... In my audio preferences I have the *multithreading* option set to* Playback and live Tracks*.

Here is what happens when that track is selected (in LIVE mode).







Alright so then if I create a dummy track and make sure that is selected before hitting play, this is what happens with threads:






So far we can see that in live mode, the single channel of plugins has to use a single thread, but in non-live mode...its able to split the work across two threads.

Next I attempted to chain up AUX channels as the Apple document recommended. While in Live mode..nothing changed at all. Only one thread used at the right end of the meter. I spread the plugins across 2 or 3 AUX channels in a chain...no difference. and non-live mode shows two threads, though with the AUX chain, its not evenly distributed:






Finally I changed the audio preferences *Multithreading* option to *Playback Tracks*. This give me 4 threads for one inst track feeding 3 aux channels in a chain.. (4 total channels being used), and just like Apple document said, we get 4 threads.






There are pros and cons to using the multithreaded playback setting. I prefer to use the *Playback and Live*, because in *Playback Tracks* mode, there is annoying thing when you change tracks where there is this long latency until you first play at least one note on the midi keyboard. Annoying. Maybe other pros and cons. But anyway, that is how you an spread the non-live load across more cores....as the apple document said.. But if the source track is in live mode...then no...it all goes to one thread, as I stated above.


----------



## double-m (Jun 14, 2020)

@Dewdman42 

Thanks a lot for testing these options.

I did the same, but forgot to drop some screen shots into my dropbox. Will follow up with some pics beginning of next week.

My results are a bit different.. sadly..

- I have tried the dummy track idea and selected this one before playback > No change
- I have changed the setting from Playback & Live to Playback only > No change
- I was increasing the buffer from 64 to the max 1024 > No change
- I have made a new routing to aux channels only. Before there were some bus channels aux channels mixed (for whatever reason). AND i left the stereo out with no plugins > No change
- i changed the core audio from my motu M4 to internal core audio and switched of the Sonarworks plugin > No change
- I have changed the core processing from automatic to 32, 16 and 8 > No change.

So every setting i have tried brought zero results. Its still the same peak with some overload stops.
At the end i had to switch off every oversampling on Fabfilter plugins to avoid processing overload stops.

Its kind of frustating to realize that there is almost no difference to my old Mac Pro (double quad) from 2008.
On my 2008 MP i was working with the same kind of projects. There were a bit more overload stops, but the performing difference looks very tiny.

It looks like i have bought a car with 16 cylinders and driving with just one.

If there would be no problem with updating OSX on my old machine, i could re-sell this new beast and go back working withe the old MP.

Btw. i was also expecting a much faster bounce /rendering process. But i dont see any difference in bounce time compared to the old one.

I think the new MP are great for video processing, but audio stuff seems to be quite disappointing.
I will try to get some support from Apple as well.

As i said, will upload some screenshots with my aux routings and stuff nexte week.

Thanks again and happy wknd !


----------



## Ashermusic (Jun 14, 2020)

Correct across the board Dewdman42.


----------



## Dewdman42 (Jun 14, 2020)

This sounds like a systemic problem of some kind. One difference is that you are presumably on catalina. I would call Apple support first and try to work through this. I’m out of ideas, but something is clearly forcing your machine to only use one thread no matter what you do.


----------



## double-m (Jun 14, 2020)

One thing to mention, the cpu peak staying the same even when i stop the playback.
But i remember the same bahavour from my old MP.

Its only going down when i changed some audio settings which are resetting the core audio.
I can also bring the peaks down by turning off some of the heavy cpu plugins like Ozone.
Ozone is about 30% of the single peak.

I´m using effect plugins only in this project, no instruments.

What happens on your system when you stop playback ?
Are the cpu levels going down ?
But i guess there might be a difference using instruments and fx plugs.

I have to call Apple fors sure. But the support is limited a.t.m. during the crisis.


----------



## double-m (Jun 14, 2020)

Forgot to say.. i´running logic in 44,1 khz resolution. No extreme sample rates.


----------



## double-m (Jun 14, 2020)

In this (german) articel Apple is speaking about the live channel (when selected).
Its the same way we were speaking about here.
They are also suggesting to split plug ins to different auxes and leaving the stereo out blank.
Its excatly what i did, haha.. But without results.






Logic Pro/Express: Tipps zum Ausgleichen der Multi-Core-Leistung


Logic Pro und Logic Express 8 oder neuer können auf Mac-Computern mit 2, 4 oder 8 Kernen alle Kerne verwenden. Beachten Sie die folgenden Tipps zum Ausgleichen der Leistung auf einem Multi-Core-System, wenn Sie mit Logic arbeiten.



support.apple.com





Updating to Logic 10.5.1 and Catalina to its newest version did not help.


----------



## SupremeFist (Jun 14, 2020)

double-m said:


> In this (german) articel Apple is speaking about the live channel (when selected).
> Its the same way we were speaking about here.
> They are also suggesting to split plug ins to different auxes and leaving the stereo out blank.
> Its excatly what i did, haha.. But without results.
> ...


Leaving the stereo out blank is a ridiculous piece of advice: there's a ton of producers who mix into compressors and other master-bus fx.


----------



## Bear Market (Jun 14, 2020)

SupremeFist said:


> Leaving the stereo out blank is a ridiculous piece of advice: there's a ton of producers who mix into compressors and other master-bus fx.



Yeah, but the effects don't necessarily have to be on the Stereo Out, do they? My mastering chain sits on an aux (or sometimes two serial auxes if I'm working a CPU-heavy chain) that feeds the Stereo Out. It definitely seems to help with multicore performance on my Logic rig.


----------



## Ashermusic (Jun 14, 2020)

Bear Market said:


> Yeah, but the effects don't necessarily have to be on the Stereo Out, do they? My mastering chain sits on an aux (or sometimes two serial auxes if I'm working a CPU-heavy chain) that feeds the Stereo Out. It definitely seems to help with multicore performance on my Logic rig.




That is very wise, AND gives you more control that doing so directly on the stereo output.


----------



## double-m (Jun 14, 2020)

SupremeFist said:


> Leaving the stereo out blank is a ridiculous piece of advice: there's a ton of producers who mix into compressors and other master-bus fx.



Yes i did (blank stereo out) and some aux channels instead. But it does nt effect on my hard cpu single peak.
Whatever i tried (see my post from this morning) was not effecting the heavy cpu hit on one of 16 cores /32 hyperthreads.

And yes i´m mixing into my mastering chain too.
Gives me better control during the full production process.


----------



## SupremeFist (Jun 14, 2020)

Bear Market said:


> Yeah, but the effects don't necessarily have to be on the Stereo Out, do they? My mastering chain sits on an aux (or sometimes two serial auxes if I'm working a CPU-heavy chain) that feeds the Stereo Out. It definitely seems to help with multicore performance on my Logic rig.


I didn't think of that, thanks!


----------



## jcrosby (Jun 14, 2020)

double-m said:


> Yes i did (blank stereo out) and some aux channels instead. But it does nt effect on my hard cpu single peak.
> Whatever i tried (see my post from this morning) was not effecting the heavy cpu hit on one of 16 cores /32 hyperthreads.
> 
> And yes i´m mixing into my mastering chain too.
> Gives me better control during the full production process.


If I understand you correctly, you said you saw the same behavior on your old Mac Pro. If so this would seem to indicate that one of your plugins is at least part of the behavior. It's true you should notice a pretty substantial difference in the CPU hit, but you should at least understand what role specific plugins are playing before you call support. (This is the first thing they're going to point out to you since it's 3rd party.)

Does the spike go away or go down significantly if you bypass all Ozone instances?

Also what version of Ozone are you using, and is it the absolute latest version?
(Izotope issued new installers in May I believe, presumably for Catalina related issues or optimizations.)


----------



## Dewdman42 (Jun 14, 2020)

putting stuff onto AUX channels will only help by adding threads in playback mode when a dummy track is selected. Any time you select a track that is feeding the AUX, you lose multi threading. And then yes...you must have some cpu hungry FX plugins that are all on one thread in LIVe mode.

When I stop playback my cpu goes to zero. So if yours isn't, then something is amiss with your system or the plugins you are using are heavy...even while stopped.


----------



## double-m (Jun 15, 2020)

jcrosby said:


> If I understand you correctly, you said you saw the same behavior on your old Mac Pro. If so this would seem to indicate that one of your plugins is at least part of the behavior. It's true you should notice a pretty substantial difference in the CPU hit, but you should at least understand what role specific plugins are playing before you call support. (This is the first thing they're going to point out to you since it's 3rd party.)
> 
> Does the spike go away or go down significantly if you bypass all Ozone instances?
> 
> ...



Exactly, i´m going to check this in more detail. As is said Ozone 9 (latest Version) is taking about 30% of the cpu peak. When i switch off Ozone the peak is going down about 30%. When i ms switching off most of the other plugins in the master (4 aux chains) cpu is going down to zero. 
Izotope have´nt announced fully Catalina support yet, but it was the same behaviour (Ozone 30% of cpu) on my old MP, which was running El Capitan.


----------



## double-m (Jun 15, 2020)

Dewdman42 said:


> putting stuff onto AUX channels will only help by adding threads in playback mode when a dummy track is selected. Any time you select a track that is feeding the AUX, you lose multi threading. And then yes...you must have some cpu hungry FX plugins that are all on one thread in LIVe mode.
> 
> When I stop playback my cpu goes to zero. So if yours isn't, then something is amiss with your system or the plugins you are using are heavy...even while stopped.



I was trying to select a dummy audio channel before playback, but unfortumately without any effect on the cpu hit. The mastering chain is splittet to 4 aux channels. I will send a screenhot later tonight.

And yes, the cpu hit is only going down to zero when i disable most of the plugins from mastering chain. Stopping Logic does not bring any effect, the cpu stays at 100%

This might be a diiference between FX plugins and instruments. Since instruments are eating cpu only when Logic is running.


----------



## Dewdman42 (Jun 15, 2020)

no this has nothing to do with instruments or FX, my example was using FX too. I only used an instrument instead of an audio track... If anything my computer should be using more CPU then yours.

It might be related to FX on your master bus, take those off and see what happens, but I think when you have a dummy track selected (to avoid live mode), then you should see multiple threads utilized.

I have heard some rumors about Catalina, so this could always be a Catalina issue and you need to call Apple Support.

What I have described earlier is how it is SUPPOSED to work. You very well may be dealing with some kind of bug, who knows...but otherwise, it doesn't add up what you're saying.

You have a lot of complicating factors you have been talking about which makes it difficult to pinpoint and troubleshoot, so you need to make it as simple as possible and focus on one thing at a time. You did the right thing by, for example, removing Sonarworks (for now), etc. 

If you are talking purely about playback now, then use the dummy track. Period. 

Set the multithreading mode to Playback Tracks mode, and you should be seeing multiple threads when there are multiple channels in your project.

If you are talking about strategies for recording tracks, then we have to talk about all the fancy FX you are trying to run on your master bus, which can be a problem while tracking. Sonarworks potentially also is a problem while tracking.


----------



## Dewdman42 (Jun 15, 2020)

By the way, the best way to create a truly correct dummy track is to create a track, then right click on it and reassign the track to NO OUTPUT. 







Then label it something like this:






That track is absolutely not feeding anything to anything. So it absolutely will not be effecting live mode. if you set up a dummy track as an empty audio track, with no regions, but still a valid audio track nonetheless, then its output is probably feeding into the master bus and LogicPro is presuming the Master Bus needs to be in live mode.


----------



## jcrosby (Jun 15, 2020)

double-m said:


> I was trying to select a dummy audio channel before playback, but unfortumately without any effect on the cpu hit. The mastering chain is splittet to 4 aux channels. I will send a screenhot later tonight.
> 
> And yes, the cpu hit is only going down to zero when i disable most of the plugins from mastering chain. Stopping Logic does not bring any effect, the cpu stays at 100%
> 
> This might be a diiference between FX plugins and instruments. Since instruments are eating cpu only when Logic is running.


Alright. I think I have an answer for you...


This appears to be specifically related to Logic's _stereo out. _
If I added CPU heavy plugins to the output the majority of processing wound up on the 1st core.
When Logic is idle that same core would maintain the core spike on the same core, (also thread 1).
If I moved those same plugins to a track Logic would idle at nearly zero %.
When I added the same CPU hungry chain to tracks and duplicated the track twice, (3 tracks in total), Logic would idle at zero, and divide the load across 4 threads when in use. (Thread 1 seems tied to real time processing).
When I left Ozone on 2 of the 3 tracks, and move one instance to the stereo out threads 2 and 3 maintained the same CPU use, the 1st core spiked up to 100%, sometimes with an overload message.
I tried this a few other CPU eating plugins (Elevate and IK Tape), same story.
I also could reproduce the behavior in 10.5.1 and 10.4.8, so 10.4.8 behaves the same way.

I'm pretty damn sure this is a bug introduced in somewhere in 10.4...

I tend to keep the stereo out light when writing because it does eat up single core use. I hadn't even noticed this until now so thanks for pointing this out. However, thinking back about past LPX projects where I've loaded up the stereo out, I don't ever recall seeing spikes hang around when Logic was idle... (Also the way CPU use on thread 1 doubles when 1 instance is moved to the stereo out seems suspicious.)

The _potentially_ good news is I actually got a request from Logic support this weekend about a bug I filed. I was going to send the files in they requested tonight but I'm going to screen record this as well and send it along too... No idea if they can/can't look into bugs outside of the one assigned to them. (Apple's super rigid like that...) But I'll send it anyway just in case they can hand it off to someone else who can... 

Like anything it's probably just going to be a waiting game with no answer until fixed. In true apple fashion, the last time they reached out they never replied once they received my files.. We just have to hold out breath and wait..

In the meantime see the pics below...


















Ozone on Track Inserts only:







1 Instance moved to the Stereo Out:


----------



## jcrosby (Jun 15, 2020)

The riddle continues!

I just screen recorded what will be going to Apple shortly and discovered another issue related to this. Ozone CPU processing continues when you use Ozone's bypass. I thought ok, maybe this is partially and Ozone thing... Nope. I tested with Elevate and it does the same thing. Also to be clear, all processing audibly bypasses, in other words both plugins have indeed stopped processing...

Interestingly IK Tapes do bypass, so I'm assuming this is somehow related to whatever they changed or deprecated in 10.5 that caused some plugins to break.

I've got this all documented with me explaining it and will ship it off shortly... No we wait 


Ozone bypassed but CPU is still consumed:


----------



## double-m (Jun 15, 2020)

jcrosby said:


> Alright. I think I have an answer for you...
> 
> 
> This appears to be specifically related to Logic's _stereo out. _
> ...




WOW thanks a lot for doing these tests..
I agree with some your results and was doing a test session as well.

But had to find out the more I test the more illogical it gets...

Here are my results:

1. 
I found out that its does nt make any any sense to split plugin into different aux channels before the stereo out. It was an advice from Apple, but there is no difference and all my auxes are addressing the first cpu thread only. 
In this aux case its also no difference if Logic is running or stopped.

Also no difference if Logic settings are in Playback & Live mode or in Playback mode only.
Dummy audio track also no better result.









2.
1X Ozone on Audio 12 Logic Playing (cpu threads 1-4 working)









3. 
1X Ozone Audio 12 Logic STOP (NO cpu level)









4. 
1X Ozone INSTR 2 / Logic Playing (cpu thread 1-4 active)









5. 
1X Ozone Instr.2 Logic STOP (cpu 1-4 activity)
(Rembember: on a audio track was NO cpu activity STOP mode)
On an instrument channel cpu load in PLAY & STOP Mode. Same behaviour like auxes.


----------



## double-m (Jun 15, 2020)

6. 
1X Ozone on Instr.2 BUT in LIVE mode. Now the last cpu thread is hitting up.
In this case a little cpu difference when logic is playing or stopped, but not much.

Tried the same with an audio channel in LIVE mode, but difference on CPU load when LIVE or not.








7.
4X Ozone Audio 2 & 4X Ozone Audio 12 (Logic Playing)








8.
4X Ozone Audio 8 & 4X Ozone Audio 9 (Logic playing)








9.
4X Ozone Instr. 5 (Logic Playing)









10.
4X Ozone Instr.2 & 4X Ozone Instr.5
Whatever instrument or audio channel i choose, its addressing ALWAYS the SAME 1-6 cpu threads.
I thought this should be more balanced related to channel numbers and cpu thread numbers.


----------



## double-m (Jun 15, 2020)

I have made some more testings like this, but the more i did, the more confusion and illogical results were coming up.
So it seems to be quite tough to get things sorted and explain these points to Apple support.

And btw. i also had hard single cpu hits on my old machine on Logic 10.3.3
So i´m not sure if this is an issue since Logic 10.4.
But who knows.

As the last one, i can show my typical mastering setup where about 8 audio tracks are routet into 4 aux channels before it goes to the blank stereo out.
The single cpu hit is coming frome these 4 auxes ONLY.








As a conclusion its just hard to figure out how we can force all other cpu threads (we payed for) to work.

Have not tested any project with a big arsenal of instruments on this computer yet, but this might force more then 6 threads go to work.

The question marks in my head are getting more instead of less.


Anyway, thanks a lot guys, take care and speak soon.


----------



## jcrosby (Jun 15, 2020)

double-m said:


> I have made some more testings like this, but the more i did, the more confusion and illogical results were coming up.
> So it seems to be quite tough to get things sorted and explain these points to Apple support.
> 
> And btw. i also had hard single cpu hits on my old machine on Logic 10.3.3
> ...


Scratch my previous post. The reason you have a core spike is because you're routing each bus into one another, which is like having a super long stereo out chain. I was able to duplicate this by feeding busses into busses into busses.

When I did processing on individual tracks processing all sat around the lower side of your image in threads 2 onward. When plugins are divided among tracks Logic can run a series of processes in parallel. Running busses into busses resulted in core one shooting up. Serial processing must requires high single core resources, (which is actually consistent with what I've seen in Live.. I'd be surprised if this wasn't the behavior under the hood of all DAWs.)

Basically feeding busses into busses add infinitum is like stacking up 30+ plugins all on one track. I actually tired something similar when David Earl did a video about this years ago, I found the same thing. Too many plugins on the same source will bring any mac to its knees. (And probably a sign that you're overprocessing.) This is probably partially why Logic's insert slots are limited to a specific amount.

The two things that aren't normal however are CPU use when idle, and CPU being consumed when bypassing a plugin with its internal bypass.


----------



## double-m (Jun 16, 2020)

jcrosby said:


> Scratch my previous post. The reason you have a core spike is because you're routing each bus into one another, which is like having a super long stereo out chain. I was able to duplicate this by feeding busses into busses into busses.
> 
> When I did processing on individual tracks processing all sat around the lower side of your image in threads 2 onward. When plugins are divided among tracks Logic can run a series of processes in parallel. Running busses into busses resulted in core one shooting up. Serial processing must requires high single core resources, (which is actually consistent with what I've seen in Live.. I'd be surprised if this wasn't the behavior under the hood of all DAWs.)
> 
> ...



You are propably right, but feeding bus into bus was also suggested by this article from Apple to avoid cpu issues. At least we can resume that workaround does nt bring any effect.






Logic Pro/Express: Tipps zum Ausgleichen der Multi-Core-Leistung


Logic Pro und Logic Express 8 oder neuer können auf Mac-Computern mit 2, 4 oder 8 Kernen alle Kerne verwenden. Beachten Sie die folgenden Tipps zum Ausgleichen der Leistung auf einem Multi-Core-System, wenn Sie mit Logic arbeiten.



support.apple.com





And yes i have a lot of plugins in this bus chain, but most of them are bypassed. But yes, still enough to creat this peak.

Avoiding live mode has not brought any result as well.
This was only effecting on instrument channels, not audio.

As mentioned before, its the same bus chain i was working with on my 2008 Mac Pro.
The old machine was peaking as well, but the difference from 2008 MP to 2019 MP is very tiny in this case. I have expected much more power, even from one processor core.

About the bypass thing you are talking about:
Maybe its a bug, but for my understanding this way if bypass is ”soft bypass” which does not bypass the processing. Its just bypassing the processed audio. Its for flawless bypassing without interruptions and without any crackle. The only plugins who dont have this ”soft bypass” are the Logic ones. They dont create interruptions and crackles when using the main (full) bypass button.

Btw.
How is offline bouncing on your system.
i´m dissapointed that its bouncing the in the same slow way as on my 2008 MP.

Btw.2
May i ask what you are doing as an pro audio guy ?
Are you a producer or mixing engineer ?
Just wondering because you mentioned Elevate for example, which is a very great limiter and stuff.

Cheerz


----------



## Dewdman42 (Jun 16, 2020)

The AUX channel chaining does work and will help, providing you are not in live mode and you have the multithreading preference set to Playback Tracks.




> Avoiding live mode has not brought any result as well.
> This was only effecting on instrument channels, not audio.



Audio tracks need to be record enabled by clicking the R button in order to go into LIVE mode, or the INPUT monitoring button selected. if you are in live mode you will know because the cpu thread meter at the far right will be spiking.

if and when you're in LIVE mode, then regardless of whether you chain through the AUX...all plugins in the signal path, including the master buss will be put on that last thread (at the far right of the meter)...which might be how and when you overload the single core capability or your MP.



> As mentioned before, its the same bus chain i was working with on my 2008 Mac Pro.
> The old machine was peaking as well, but the difference from 2008 MP to 2019 MP is very tiny in this case. I have expected much more power, even from one processor core.



Well expecting more from the MP then you got is understandable. What kind of 2008 Mac Pro did you have? What processor was in it? The new MP has unreal amount of multi-core performance capability when lots of threads are active, but each single core is only "decent". Not as good as a few other current models actually. But still should have been significantly better then your 2008 model. But i would not have expected "double". There were a lot of threads about this on the internet a few months ago, here, on gearslutz and on the logicPro forum, perhaps other places.

here is a chart I did a few months ago showing relative performances, based on data from Geekbench, for several older and newer computers...












> Btw.
> How is offline bouncing on your system.
> i´m dissapointed that its bouncing the in the same slow way as on my 2008 MP.



How you route your channels can sometimes determine that only a real time bounce is possible.[/QUOTE]


----------



## double-m (Jun 16, 2020)

Dewdman42 said:


> The AUX channel chaining does work and will help, providing you are not in live mode and you have the multithreading preference set to Playback Tracks.
> 
> 
> 
> ...


[/QUOTE]

Thanx @Dewdman42 !

Here are my results with and without LIVE tracks and different buffer sizes (audio tracks only).


1.
Dummy audio track (10) selected // Playback & LIVE mode // small buffer:







2.
Dummy audio track (10) selected // Playback mode ONLY // small buffer:







3.
Setero Out selected // Playback & LIVE mode // small buffer:







4.
Dummy track (Audio10) selected as LIVE (rec armed /red) // Playback & LIVE mode // biggest buffer possible (I/O buffer 1024 /work buffer BIG / 32bit summing instead of 64):







5.
Dummy track (Audio10) selected // Playback mode ONLY // biggest buffer possible (I/O buffer 1024 /work buffer BIG / 32bit summing instead of 64):







For me, all these settings are eating very similiar amounts of cpu threads.

- No matter im LIVE mode or not
- No matter if Playback & LIVE or Playback only
- No matter if the dummy live track is armed (rec light red)
- No matter which buffer size

That the buffer size doesn't seem to play a role in this case is what amazes me the most..
Buffer 64 or 1024 // work buffer small or big // summing 32 or 64 Bit 
= almost no difference on cpu load.


My old MP: 
Model early 2008 // 2X 2,8 Ghz Quad Core Intel Xeon

I was working with this machine on exactly the same kind of projects with pretty simliar cpu loads
in comarison to the new MP.
Also bouncing a project tooks exactly the same time.
(Maybe you r right that something is forcing both machines for real time rendering, even when offline
bounce is selectd. I dont know..


On another topic, the new MP is even significantly slower than the old machine.
The old MP (2008) is booting in seconds (with SSDs). The new MP tooks ways longer to start.
Even waking up the monitor from sleep takes much longer then the old beast.

But i guess this has something to do with the new security chip from current Mac s.



So, right now i´m still struggelin and testing routing configs to force the new MP for better cpu loads and faster workflows.
Hopefully i will see some more cpu threads working in the future.

But for now i think a 16core machine is quite oversized and overpaid to work with Logic.


Thanks again guys !


----------



## double-m (Jun 16, 2020)

Project bounce of this song (length 6:38) takes 8:00 minutes.


----------



## Dewdman42 (Jun 16, 2020)

I can understand your frustration, especially after you spent as much as you did on the MP.

In any case, just to clarify....

You were never in LIVE mode in any of those tests. You would need to enable a track for recording or monitoring by turning on either the red R button or the I button on the track header. That is slightly different behavior then Instrument tracks which go live simply by selecting the track header.

You can tell you were not in live mode because your visual spike was on the left end of the cpu meter rather then the right.

That being said, LIVE mode obviously has nothing to do with the problem you're experiencing, so take that out of the discussion...

The multi-threading preference should make a little difference in how many threads get created by using the AUX chain approach, according to the Apple document. it does for me. Apparently it doesn't for you and I don't have answer for your about that. It its entirely possible that LogicPro/Catalina are not handling threads the same way on your MP as they do for my cheesegrater or your 2008 cheesegrater. But that is why you need to get Apple Support involved if so, nobody here can help you with that.

Did you try calling Apple Support yet?

There is at least one other person I have talked to that had some kind of problem and their audio device manufacturer was supposedly working closely with Apple to try to figure it out... Also on a new MP. The new MP is also Catalina and I've heard about some odd problems like this...but I suggest you try the gearslutz forum because there are some threads there talking in great detail about the new MP performance..

You should also try to remove tracks one at a time, or plugins one at at time, in order to see when the spike goes away, until you can narrow down the search. What you have now is complex enough that is difficult to pinpoint the problem you're having, which might be plugin related, might be catalina related, might be related specifically to MP hardware(though unlikely), or might be some combination of all of the above. Your MOTU sound card could also be a factor. The fact that you're getting the spike regardless of buffer size is also indicative to me of some kind of systemic problem that is spinning that first thread out of control. You don't really have that many plugins in your project...so honestly I think its some bad player somewhere in all that you are using. 

Get rid of sonar works first, then start removing plugins one at a time until you see the spike go away.


----------



## Dewdman42 (Jun 16, 2020)

double-m said:


> But for now i think a 16core machine is quite oversized and overpaid to work with Logic.



I have felt for quite some time that 16+ cores for LogicPro is complete overkill in terms of the amount of money spent. Many people feel the i9 is a better CPU because of slightly better single core performance, but if you see my chart above..the 12 core is probably the sweet spot. Most people working in LogicPro simply do not need 16 cores at all, even remotely close. if you have lots of dollars to burn, then why not. The 8 core, in my opinion is ok too, but kind of underpowered for how much it costs. But the 12 core is pretty decent machine really...though expensive.

The i9 is almost as good multi-thread performance as the 12 core, but superior single core. You are running into single-core barrier right now. But I personally think the barrier you are running into is due to a "problem". I don't know what the problem is, but its a problem, that is not the normal performance for your machine. But in any case, that problem is exceeding the single core performance of your machine. Having an i9 probably would hit the same problem, unless the problem is related to the Xeon and Catalina and something about how it is handling multi-threading incorrectly in your machine... but the problem still could be one of your plugins too.


----------



## Dewdman42 (Jun 16, 2020)

double-m said:


> Project bounce of this song (length 6:38) takes 8:00 minutes.



That's weird. that's not real time bounce then. And something is grinding on your CPU as a problem. that's all I can say. Hope you can find the culprit.


----------



## jcrosby (Jun 16, 2020)

Dewdman42 said:


> Did you try calling Apple Support yet?



Definitely. Ask specifically for someone from _Pro Apps, _and request that they document the behavior by remotely recording your screen.


----------



## jcrosby (Jun 16, 2020)

double-m said:


> You are propably right, but feeding bus into bus was also suggested by this article from Apple to avoid cpu issues. At least we can resume that workaround does nt bring any effect.
> 
> 
> 
> ...


Offline bouncing is pretty quick for me. Exporting on both my MacBook and my hackintosh are significantly faster than my old MP was, and of course much faster than real time bouncing. Your machine taking that long doesn't seem right, a call to support seems mandatory.

I compose for TV, trailers mostly... I also do some mixing and mastering for some local clients, but that's fairly infrequent compared to composing. The mastering I do is typically for the club though which is severely unforgiving. If it doesn't stand up to other commercial tracks it's immediately audible.  It's fun and I like the challenge, but composition is what keeps the lights on...

That's one of the reasons why I like Elevate. It's the only other limiter I've heard that matches, if not outright beats Ozone's IRC III/IV. Both hold up to masters that have to be obscenely loud to compete with other commercial tracks.

This is obviously a completely different approach than I take for orchestral music!! I actually do try and take a tasteful approach, "club" music is just one of those genres where the loudness war will win every time, fighting it is futile


----------



## double-m (Jun 16, 2020)

Thanks a lot for this friendly support on this site guys !

I´m on Mac & Logic for decades, since Logic was engineered by a german brand called Emagic, haha..
But i never heard about this kind CPU handling before. But well, we are learning day by day..  

I will try to reach the Apple pro support for sure and i´m also familiar with gearslutz.
If anything interesting is coming up, i will report here.

@Dewdman42
Just for your information, i did almost all things you suggested in the right way.

For example switching from Motu /or Sonarworks to internal core audio /internal speakers.

Also was switching all my plugs on and off. So i can bring down the cpu to zero, by bypassing all plugins from the aux chain. 
As i mentioned before, Ozone 9 is eating more then 30% of the the left single cpu thread.

Also got what you tried to explain about live channels..
I created a high peak on the last cpu core (fully right side) by arming an instruments track into live mode.
Just could´nt recreate this with an audio track too. Even when the recording sign turned into red, which you can see on example #4 from my last testing. 


Anyway, i won´t talk endless about the same topic here.
But the good thing is i have learned something new, which is pretty important when it comes to the pro support chat with Apple.

So, thanks again, all the best and take care.
Hope i can report something positive to you guys soon.

Cheerz


----------



## Dewdman42 (Jun 16, 2020)

double-m said:


> Also was switching all my plugs on and off. So i can bring down the cpu to zero, by bypassing all plugins from the aux chain.
> As i mentioned before, Ozone 9 is eating more then 30% of the the left single cpu thread.



Alright, well at least you know Ozone9 may be a problem, perhaps ozone9 doesn't work great on Catalina? That would be the difference between this machine and your 2008.

However, the Playback Tracks setting should have given you more threads too.. in my view. if that is the only one you noticed that was taking a lot of CPU, then that is the culprit....OR..it could be that for some reason you are not getting as many threads allocated as you should. I mean based on your images, I think LPX should have allocated something more like about 15 threads, and we never see that many in your images...so...something is loading up the first thread with a lot of work... That is presuming you had the multi-threading setting set to *Playback Tracks* mode.

Its always possible that LogicPro/Catalina/Xeon are not fully taking advantage of all your cores in terms of thread allocation strategies...but you will just have to take that up with Apple Support at this point.




> Also got what you tried to explain about live channels..
> I created a high peak on the last cpu core (fully right side) by arming an instruments track into live mode.
> Just could´nt recreate this with an audio track too. Even when the recording sign turned into red, which you can see on example #4 from my last testing.



In the images above of your testing, you had selected an empty track that with no regions and not routed to any AUX, much less to the stereo buss (I think, its might be german). So of course it did not go to anything LIVE or use any CPU.

In order to get an audio track into live mode....

Select one of the tracks that actually has plugins and is routed through your AUX chain and then hit the R or I button to enable LIVE mode on the audio track. You would then see all of the plugins on that track, along with the AUX chain and the master bus all go to the thread at the right end...and probably 100%..


----------



## double-m (Jun 17, 2020)

Dewdman42 said:


> Alright, well at least you know Ozone9 may be a problem, perhaps ozone9 doesn't work great on Catalina? That would be the difference between this machine and your 2008.
> 
> However, the Playback Tracks setting should have given you more threads too.. in my view. if that is the only one you noticed that was taking a lot of CPU, then that is the culprit....OR..it could be that for some reason you are not getting as many threads allocated as you should. I mean based on your images, I think LPX should have allocated something more like about 15 threads, and we never see that many in your images...so...something is loading up the first thread with a lot of work... That is presuming you had the multi-threading setting set to *Playback Tracks* mode.
> 
> ...




Alright, got it. 

I resumed that Ozone was already a big bummer on my old 2008 MP.
This behaviour is´nt new for me. I just expected some more headroom on the new machine, even on a single cpu core.
But you explained very well that a single core is´nt still that powerful.
And of course my old MP was running on full limit. But i remember the core distribution was quite the same. There was always one big peak on the left /cpu core 1.

So its pretty the same behaviour on both MP´s.
This does nt look like that it could be a Catalina problem.

I just have to force LPX to use more cores somehow.
Hopefully the Support can give some usefull advises.

Thanks mate


----------



## Soprano_Sundays (Apr 7, 2021)

Did anyone ever get to the bottom of this.

I have encountered a similar problem, on small projects (with quite a few CPU intensive plugins) with only vocals and a few other rhythm section stems Logic seems to assign all processing to one solitary thread.

The only solution I have found is to duplicate tracks with plugins that are CPU heavy and then it starts to use other threads (Essentially a load of fake tracks 🤣) - I basically have to duplicate the vocal chain to get it off the same thread as the mix bus - pretty crazy.

Definitely nothing to do with live tracks.

With larger projects it seems to spread the processing out - even when I load multiple instances of super intensive plugins like Acustica Audio / Soothe at 4x oversampling

If anyone has any ideas of how to fix that would be great?


----------



## mybadmemory (Apr 7, 2021)

Well. One thing is to realise that spikes usually only occur if you have a software instrument track with midi input selected and active. So resting on an empty audio track or the stereo out track certainly helps with this issue for playback.

For recording though, that's obviously impossible. The only thing I've noticed there is that some updates have improved this, while other have made it worse again. Nowadays I don't really get the problem often enough to notice or care.


----------



## Soprano_Sundays (Apr 7, 2021)

mybadmemory said:


> Well. One thing is to realise that spikes usually only occur if you have a software instrument track with midi input selected and active. So resting on an empty audio track or the stereo out track certainly helps with this issue for playback.
> 
> For recording though, that's obviously impossible. The only thing I've noticed there is that some updates have improved this, while other have made it worse again. Nowadays I don't really get the problem often enough to notice or care.


Thanks for the reply!

Sure I do realise that but this is definitely not the issue here unfortunately. Some kind of weird bug where logic doesn't distribute the load. Essentially what Logic is doing is loading up one thread for the mix bus plugins as well as using the same thread for the vocal track, super annoying.

Haven't had it until recently - maybe as most of the time working on larger projects.

The only solution at the moment I have come up with to shift the load to other threads is to create duplicate fake tracks with heavy cpu plugins loaded - then I use one of these that has been assigned to a different core to and copy the audio across which is slightly ridiculous, lol.


----------



## Soprano_Sundays (Apr 7, 2021)

double-m said:


> Alright, got it.
> 
> I resumed that Ozone was already a big bummer on my old 2008 MP.
> This behaviour is´nt new for me. I just expected some more headroom on the new machine, even on a single cpu core.
> ...


Did you ever get the figured out? Where Apple support any use?


----------



## sourcefor (Apr 7, 2021)

Yeah I get those spikes but on the right side, then I make a track with NO OUTPUT and select that when playing back and it seems to help most times, but not all! But when I try to record a midi track all breaks loose and there are pops and clicks then playback just stops, sometimes, very random but often! I hope we can get to the bottom of this, as I know the machines are powerful enough!


----------



## Soprano_Sundays (Apr 7, 2021)

sourcefor said:


> Yeah I get those spikes but on the right side, then I make a track with NO OUTPUT and select that when playing back and it seems to help most times, but not all! But when I try to record a midi track all breaks loose and there are pops and clicks then playback just stops, sometimes, very random but often! I hope we can get to the bottom of this, as I know the machines are powerful enough!


Yeah have tried the audio track with no output but doesn't work for me unfortunately. When I change the threads to automatic it usually makes it worse and the 'playback tracks' only also is worse. In fact changing these settings usually makes Logic use less threads! 🤣

24 threads and it's only using the last one for about 20 intensive plugins!


----------



## sourcefor (Apr 7, 2021)

Soprano_Sundays said:


> Yeah have tried the audio track with no output but doesn't work for me unfortunately. When I change the threads to automatic it usually makes it worse and the 'playback tracks' only also is worse. In fact changing these settings usually makes Logic use less threads! 🤣
> 
> 24 threads and it's only using the last one for about 20 intensive plugins!


Ouch this really sucks all the way round!


----------



## Soprano_Sundays (Apr 7, 2021)

Soprano_Sundays said:


> Yeah have tried the audio track with no output but doesn't work for me unfortunately. When I change the threads to automatic it usually makes it worse and the 'playback tracks' only also is worse. In fact changing these settings usually makes Logic use less threads! 🤣





sourcefor said:


> Ouch this really sucks all the way round!
> 
> 
> sourcefor said:
> ...


Potential small breakthrough. If I change the threads down to 4, 6 or 8 it seems it may spread the load slightly better. Still can't understand why the audio channel (vocals) with the most plugins has to be processed with the same thread as the mix bus. 🤦‍♂️😬


----------



## Nimrod7 (Apr 7, 2021)

Hey guys I am not sure if it's posted elsewhere, but have you seen this video by Mark Payne?
Probably one of the best on the subject:



It's saying M1 but the explanation and testing methodology applies to non M1s Macs.


----------



## Soprano_Sundays (Apr 7, 2021)

Nimrod7 said:


> Hey guys I am not sure if it's posted elsewhere, but have you seen this video by Mark Payne?
> Probably one of the best on the subject:
> 
> 
> ...



Thanks Bill! Useful information and this definitely helps with the larger projects.

Was just running a larger project to look at the spread of the load, seems Logic always uses one thread for the stereo out.

Unfortunately, does seem that it limits the cores used when on smaller projects. Still trying to figure out how to get Logic to keep tracks away from the stereo out core / thread on these smaller ones.


----------



## Marsen (Apr 7, 2021)

Soprano_Sundays said:


> Potential small breakthrough. If I change the threads down to 4, 6 or 8 it seems it may spread the load slightly better. Still can't understand why the audio channel (vocals) with the most plugins has to be processed with the same thread as the mix bus. 🤦‍♂️😬


Don know it's already mentioned. Did you set multiprocessor support in kontakt on or off?


----------



## Dewdman42 (Apr 7, 2021)

Soprano_Sundays said:


> Unfortunately, does seem that it limits the cores used when on smaller projects. Still trying to figure out how to get Logic to keep tracks away from the stereo out core / thread on these smaller ones.


its not that LogicPro is "limiting" anything, nor that its a bug either. There are limits to what DSP can do in parallel. the mix bus has to wait on the earlier channel to do their DSP before it an do its own DSP. It may or may not make any sense for it to be on a different thread...ESPECIALLY if there is any live channel involved. Non-live channels can do a lot of under the covers pre-processing ahead of time and use threads in more complicated ways to achieve that. But live channels can't operate on anything ahead of time. By the way, AUX channels are kind of treated like live channels in some cases not always, it depends on what is feeding them.

None of us really know what the internal threading strategy of LogicPro is exactly...there is always some speculation out there about VePro or some DAW some super intelligent thing to make better use of cores, but honestly none of us really know what they are doing...the complications of figuring out how to turn a mixer configuration with sends and busses and everything feeding master busses, etc...some live channels and some not live channels...leads each DAW to make some choices about the best way to operate and to parallelize the computation with threads whenever possible. But bear in mind that there is also overhead associated with threads. It could very well be that Logic could be choosing to use a certain strategy under the hood that mostly people will have more tracks then they do cores...so keep the threading strategy more simple. We don't really know, but I think you're assumption that the master bus should have its own thread, is not necessarily true, nor is it necessarily a "bug".

the reason live channels get their own devoted thread is to make sure they aren't having to share a thread with other channels, since they are purely live..there is no pre-processing that can happen...so they have to be able to get their work done quickly if you expect to use a low latency setting.

If you try to create a complicated channel with a lot of plugins on it...and complicated aux sends, etc..all feeding a master bus that has some CPU heavy plugins on it...there is no DAW in the world that won't cough up blood at some point...it simply can't be parallelized as much..especially if there is any live channel feeding into it somewhere in that signal chain.

As others have suggested, first make sure you create a dummy track, not an audio track, I want you to right click the track header, reassign it to "nothing", and label it as "CLICK ON THIS DURING PLAY", and make sure to always select that track header before hitting play every single time unless you are going to record, then obviously you need a track enabled for record (selected), in order to record on it. Otherwise, always select the dummy track that points to no channels whatsoever.

The other thing is to have a look at your mixer routing to see if you are creating long signal chains with lots of plugins...by virtue of sends and output to busses, etc.. in the end, that could result in less parallelization then you might think....and if you put too many plugins on one signal path like that...and especially if the signal path is live...then your computer will cough up blood...there is only so much that LogicPro can parallelize to threads.


----------



## Soprano_Sundays (Apr 24, 2021)

Dewdman42 said:


> its not that LogicPro is "limiting" anything, nor that its a bug either. There are limits to what DSP can do in parallel. the mix bus has to wait on the earlier channel to do their DSP before it an do its own DSP. It may or may not make any sense for it to be on a different thread...ESPECIALLY if there is any live channel involved. Non-live channels can do a lot of under the covers pre-processing ahead of time and use threads in more complicated ways to achieve that. But live channels can't operate on anything ahead of time. By the way, AUX channels are kind of treated like live channels in some cases not always, it depends on what is feeding them.
> 
> None of us really know what the internal threading strategy of LogicPro is exactly...there is always some speculation out there about VePro or some DAW some super intelligent thing to make better use of cores, but honestly none of us really know what they are doing...the complications of figuring out how to turn a mixer configuration with sends and busses and everything feeding master busses, etc...some live channels and some not live channels...leads each DAW to make some choices about the best way to operate and to parallelize the computation with threads whenever possible. But bear in mind that there is also overhead associated with threads. It could very well be that Logic could be choosing to use a certain strategy under the hood that mostly people will have more tracks then they do cores...so keep the threading strategy more simple. We don't really know, but I think you're assumption that the master bus should have its own thread, is not necessarily true, nor is it necessarily a "bug".
> 
> ...


Thanks for your reply and insights.

Unfortuantely, this isn't to do with any live active tracks. I had tried all the things you mentioned previously before I posted on here and they didn't solve the problem.

This does seem to be a bug - as when I change the number of threads, for example 32 to 12. Logic does redistribute the load, which means potentially it is expecting higher track counts when set at 32 threads vs 12 - hence why it is limiting thread use on smaller projects. Also when I duplicate the vocal chain multiple times I can shift the load to other threads, essentially creating a bigger project with dummy tracks.

For now I seem to have solved the problem by limiting the number of threads Logic uses based on track numbers in the session.


----------



## Soprano_Sundays (Apr 25, 2021)

Marsen said:


> Don know it's already mentioned. Did you set multiprocessor support in kontakt on or off?


Haven't actually checked this out, so thanks for the heads up!

Not using any kontakt in the session in question - only audio tracks.


----------



## LamaRose (Apr 25, 2021)

Kontakt 6 solved most of the issues on my 2015 MBP... N.I. is/was _the Guilty_! UVI and Sine run like WD-40. 

But soon I switch to the M1 out of necessity... hope this isn't a cluster muk.


----------



## Dewdman42 (Apr 25, 2021)

Logicpro isn’t “limiting thread use”. As I tried to explain before there is no point usually to use two threads for one track. And eventually it needs to put more then one track per thread. I have noticed also that sometimes I could create a small project with only half a dozen tracks but on my 12 core system I would see only 3-4 threads in use in the meter. I even made a special juce plugin just to create artificial cpu load to try to figure out what logicpro was doing. Never really did figure out exactly how and when it decides to put a track in its own thread vs being added to a thread shared with another track. There is some algorithm it is using internally that must be based on the assumption that eventually there will probably be more tracks then there are cores so might as well start sharing threads. I dunno, we don’t really know we can only guess. It’s probably considerably more complex then we can guess in how it decides to allocate tasks to threads and cores. The only thing we know for sure is that a live channel gets its own thread at the end.

Unless you’re getting dropouts I would not worry about it


----------



## Soprano_Sundays (Apr 25, 2021)

Dewdman42 said:


> Logicpro isn’t “limiting thread use”. As I tried to explain before there is no point usually to use two threads for one track. And eventually it needs to put more then one track per thread. I have noticed also that sometimes I could create a small project with only half a dozen tracks but on my 12 core system I would see only 3-4 threads in use in the meter. I even made a special juce plugin just to create artificial cpu load to try to figure out what logicpro was doing. Never really did figure out exactly how and when it decides to put a track in its own thread vs being added to a thread shared with another track. There is some algorithm it is using internally that must be based on the assumption that eventually there will probably be more tracks then there are cores so might as well start sharing threads. I dunno, we don’t really know we can only guess. It’s probably considerably more complex then we can guess in how it decides to allocate tasks to threads and cores. The only thing we know for sure is that a live channel gets its own thread at the end.
> 
> Unless you’re getting dropouts I would not worry about it


Sure, I have it sorted now. But I disagree it is limiting thread usage - like I and you said it would appear based on apparent expected track numbers for a high thread count. IE - If you are asking it to use 32 threads then it will expect a high number of tracks.

The project where this was most apparent was when a vocal track (with high numbers of plugins was being processed by the same thread that was also processing the stereo out plugins) - again this is totally unrelated to live tracks.

The reason this is relevant is that I have been using more Acustica plugins recently which have a high CPU load.

Also a previous poster posted multiple screenshots demonstrating the issue which is not related to active live tracks.

I can actively see Logic changing the assignment of threads when I adjust the number of threads available - and this is going from overloading one thread to splitting the load between multiple threads.


----------



## Dewdman42 (Apr 25, 2021)

I hear you, I wasn't really talking about live tracks in my last post. I was talking about how the other non-live tracks get allocated to threads. 

If I understand you correctly you are saying that when you lower the thread count preference in LogicPro, that somehow signals Logic Pro to assume there will be less tracks and spread the tracks more across less threads, then it would across more threads. I find that illogical and hard to believe, but I'll take your word for it for now....something to test myself later. Good info to know if true.

If you are getting the results you need then great!


----------



## Soprano_Sundays (Apr 25, 2021)

Dewdman42 said:


> I hear you, I wasn't really talking about live tracks in my last post. I was talking about how the other non-live tracks get allocated to threads.
> 
> If I understand you correctly you are saying that when you lower the thread count preference in LogicPro, that somehow signals Logic Pro to assume there will be less tracks and spread the tracks more across less threads, then it would across more threads. I find that illogical and hard to believe, but I'll take your word for it for now....something to test myself later. Good info to know if true.
> 
> If you are getting the results you need then great!


Yes that's definitely what I've encountered, an active change in thread assignment based around the number of threads set. I have also used the method of creating new duplicate tracks which then get assigned to different threads, which I can then use instead of the original track. Hopefully, that makes sense.


----------

