I was just wondering if any of you were experiencing the same thing. Oddly enough,its supposed to be more cpu effecient, according to the release notes. I tried switching the new "live playback option" on and off, to no difference.....With the same exact settings, same project, I get less spikes in 10.2.0 than 2.1.
Tried deleting different plist files. Still the same. Maybe 3rd party compatibility....

 

move components folder and test without any plug.

 

On the contrary it seems that the threads are better shared among the cores in my system

 

fuck logic…. i have it but i hate it and do n0t using… I have a legit Logic… i was fucking stupid to buy it… waste my cash…

 

Try changing the "Processing Threads" and "Multithreading" Settings under Preferences >> Audio and see if this helps. This of course only makes sense on multicore CPUs

 

Balance with core seems better for me. Also overall looks better when it comes to performance.

 

Yeah, I tried all different settings. I'll test some more. Maybe some project files got corrupted and are causing spikes. its not constant high cpu, just spikes that seem to cause more overload messages. The overall cpu usage/core multi threading seems pretty much the same.
thanks for the reponses everybody

 

Do you know what Live mode is and does?

 

I quote from this Document "What's new in Logic 10.2.1", p. 46 f., which is free and can be found at http://logicprogem.com/LogicProGEM/LPXv10_2_1.html

"Logic's Multithreading

Here is how those Cores and Threads relate to Logic. There is a "Processing Threads" setting in Logic's Preferences ➤ Audio ➤ Devices Tab. Its popup menu displays the maximum number of Threads available on your computer. Most Apple computers use Hyper-threading, so the maximum number you see in this menu, divided by two, is the number of Cores available on your computer (listed in your Hardware Settings).

The default setting in Logic is "Automatic" where Logic decides how many Threads it uses. To monitor the activity of the individual Threads, select the Custom Control Bar Display and double-click on the CPU Meter, which opens the standalone Load Meters window . Each vertical bar on the left represents one Thread indicating its activity (the load). The number of bars reflects the setting in the Processing Threads menu.

Two Thread Distribution Modes

Logic uses two different modes when it comes to distributing the audio processing on Channel Strips to the
available Threads:

Playback Mode

This is the default mode where Logic tries to spread the load of each Channel Strip across the available Threads. If you have "too much going on" on a single Channel Strip (too many CPU-intensive Plugins), then you might overload a single Thread (error message!), especially if Logic assigns other Channel Strip to that same Thread too.

Please note that this is not necessarily a Logic limitation and more of a technical challenge. A Plugin acts as one unit and its processing can't be split up by the application to be processed on multiple threads. To do so, the Plugin itself has to be specially coded to divide its workload to multiple Threads (maybe something for the future). For now, all the Plugins on a single Channel Strip act as the main audio processing thread that has to be processed in series on a single Thread.

Your only option for a "fully loaded Channel Strip" is to split the audio signal (and load) to an Aux Channel Strip, which, as a separate Channel Strip, can be handled by a separate Thread.
In general, whenever an audio signal can be rendered in parallel, Logic will use multiple Threads. For example:

• Multiple Audio Channel Strips.
• Multiple Instrument Channel Strips, even ona Summing Stack.
• Channel Strips sending their signals via the Sends to one or more Aux Channel Strips.
• Multi-Output Software Instrument (MOSI) using separate Aux Chanel Strips for the individual outputs.

Live Input Mode

The Live Input Mode is some mysterious Logic "thing" that makes the already complex subject of Thread-distribution even more, let's say, "interesting". However it is very important, especially when trying to understand the new "Multithreading" settings in LPX 10.2.1.

When selecting a Software Instrument Channel Strip or selecting its Record Enable Button, Logic enters "Live Input Mode" when you start playback or play that Track via MIDI. This takes about 100ms to engage. You might have noticed sometimes when playing your first note on your MIDI Keyboard that the newly selected Track has a little delay on that first note. This is the Live Input Mode kicking
in. Live Input Mode will also be enabled on an Audio Channel Strip, not when it is selected, but when it is record-enabled.

The Live Input Mode has a major implication about the way how Logic distributes the signal processing across multiple Threads. Now all the Channel Strips that are part of the signal flow related to that selected Channel Strip are handled by a single Thread. This is done to ensure low latency during recording (remember, you selected the Track, so Logic assumes that you want to record on it). The major downside, as many Logic users will know, is the higher risk of a system overload message. If you think about it, if an Instrument Channel Strip has CPU-intensive Instrument Plugin, plus lots of CPU- intensive Audio FX Plugins, routed to multiple Aux Channel Strips (with their own Plugins), and all that routed to the Output Channel Strip with even more Plugins, then all those Channel Strips are processed on a single Thread ... Boooom.

 

Last edited: Jan 26, 2016

Yes, I know. Thank you all. Like I said, I tried pretty much all settings and different situations. Im not a full time pro, but I know my way around logic pretty well. Seeing as everybody seems to not be having my problem, I'll check for other problems (plists, re-install, etc..)

 

In theory CPU spikes could be caused by a more efficient program, since the cpu usage may now be right at the threshold where it thinks that it can change C-States, then usage crosses past the threshold and it needs to jump back causing a spike.

 

My Sense is A) This update works best on latest OS, newest hardware...
B) Overall, regardless of all the added improvements, still feels very 'beta'

On 10.9.5, I experienced displeasure and rolled back to 10.2.0
Proceed with caution