New Logic update 10.4.5 is here!

[bayswater]

I was responding to you yes. Did you report what the LPX cpu meter is doing while doing your AUX-chain approach?

I see what you mean. The LPX performance meter shows only one thread active. But I'm still not sure what I'm seeing because:

 

1. The Activity Monitor CPU meter shows activity on six processors while LPX shows one thread.

2. The level of activity on the LPX meter and the six AM meters are in concert: they all rise and fall at the same time

3. If I increase the note density on a range within the MIDI region, on the next pass, the LPX meter and all 6 AM meters show increasing activity at the same time

 

2 and 3 above imply to me that what the LPX meter is showing on one thread is the same activity being shown on 6 processors in AM.

 

I tried another sequence that has 200 audio tracks, followed by 128 MIDI tracks playing 32 instances of Kontakt. In this case, LPX shows an even load across 12 threads, implying that hyperthreading is happening. But AM shows activity only on 6 processors wile the audio tracks are playing: no hyperthreading, but then shows hyperthreading when the MIDI tracks are playing. While the activity is shown as even distributed across 12 threads in LPX, it is not even across the 12 AM meters. Numbering the processors from top to bottom or left to right, it shows lower activity on even numbered processors, and higher activity on lower numbers processors.

 

So what's going on here? It looks to me as if there is no one to one correspondence between the threads reported by LPX and the processors reported by AM, and that regardless of how LPX reports the way activity is spread across threads, the Mac, as reported by AM does not necessarily link one processor to one thread.

 

Regardless of that, there is still the question of why the 16 channel version consumes less CPU overall than the 1 channel version. How can that be if both use only one processor? And regardless of the answer to that question, does it not imply that spreading a heavily populated channel strip across several Auxes is a possible way to improve processor efficiency?

[Dewdman42]

The LPX meter shows the threads that LPX is actually running. What you see on your system meter is the entire operating system. If moving things around on channels causes LPX to still only use one thread on one core...regardless of what you see in the system meter...there is not much point to it., that being said, if you measure "better performance" in some way, by all means use it.

 

But in order to make sure you're really getting better performance, I recommend you use a test that will be exactly the same...either you run it through exactly the same section of music...or make a test project that has nothing but repeating 16th notes or something...so that you can compare accurately. Then look into using something like the following command line to measure cpu usage on the system

 

iostat -w 3 -I -c 60 | awk '$1 !~ /^disk/ && $1 !~ /^KB/ { print $10 }'

 

The above measures average CPU across all cores, every 3 seconds for 60 times (3 minutes). if you send the output of that to pbcopy then then you can paste the results into Excel and average that too. So try that with AUX chain vs single channel chain...

 

iostat -w 3 -I -c 60 | awk '$1 !~ /^disk/ && $1 !~ /^KB/ { print $10 }' | pbcopy

 

Something like that..

[Dewdman42]

also bear in mind that even though LPX might not fork additional threads, which is what it reports in its own meter...the OS might fork threads at certain times or have multiple threads ready to do certain jobs it deems capable of being done on a thread. LPX basically makes calls to Apple API's...which in turn requests the OS to do things for it.. So the OS could be making some use of threading and multiple cores...regardless of wither LPX is telling it too. That would be the case regardless of whether you break up your chain into AUX channels or not. The LPX meter basically tells us LPX is attempting to put that whole plugin chain on one thread...but requests to the OS may use multiple threads as it can.

[facej]

The way to get accurate measurement of Logic Pro X and resource utilization is to run it from "Instruments" (part of Xcode) and let it show you what is actually happening.

 

Activity Monitor, iostat, top, all the tools...are sort of system-wide.

 

If Logic Pro X is actually processing a channel 1 plugin at a time, in sequence, then it *might* not get run on the same core/thread for every plugin. Might be simpler to explain if we think of a channel strip (AUX) as a synchronous processing stream as opposed to an asynchronous processing stream. Multiple synchronous channels can be processed asynchronously, with an eventual requirement to cause all the audio to output synchronously.

[Dewdman42]

yep, good point...and if you have your system cpu meter set to 3 seconds or something, even one second...it would average out across more than a single core.

[Ploki]

how does logic know which plugins are for playback? all my projects so far loaded up fine.

[Sascha Franck]

how does logic know which plugins are for playback?

 

It knows:

- Whether a track is selected (which makes it "needed for playback").

- Whether it's set to monitoring.

- Whether there's regions on a track (this is possibly the most astounding thing).

[Ploki]

oh... So when you put regions on the track it wakes the track up?

[Ashermusic]

oh... So when you put regions on the track it wakes the track up?

 

 

No but if the project was saved with regions those load up when you open the project.

[robinloops]

If you select a track it will activate the plugins. So if adding regions doesn’t, just select it when you add new regions.

[Ploki]

oh okay. none of my project appeared problematic with this feature so far, i didnt even notice it.

[bayswater]

the OS might fork threads at certain times or have multiple threads ready to do certain jobs

This must be what is happening assuming both LPX and AM monitors are accurate. The OS is clearly using 6 processors, and the load on them is more than the system or any other background processes would invoke.

 

As for comparisons between two approaches, the projects used in my example are the same except in one case 16 instances of Q10 are all in one channel strip, and in the other they are in 16 sequentially chained channel strips. Otherwise they play the same sets of scales on a single instance of EXS24.

 

I could take more precise measures as you suggest, but just from looking at the three summary AM measures (system, user, idle) you can see that the user load is about half or less using 16 channels compared to using one channel.

[Dewdman42]

I don’t believe you that it’s half. Make more accurate measurements

[bayswater]

Look at the charts I posted earlier. Those are shots taken while these projects were in playback. The exact ratio doesn't really matter. The first set showing 16 channels is clearly showing significantly less CPU consumption than the second set showing 1 channel.

[Dewdman42]

A project can vary drastically from moment to moment about how much CPU use is happening, so that is simply not a valid comparison. A claim of half or double is a highly dubious claim. Make a more accurate test if you really wanna know.

[bayswater]

I don't think it's worth the effort. This looped a passage that's about 15 seconds long and it ran for about 10 minutes. The load was even across that time. Sure, a more accurate test will narrow down the actual numbers, but it won't change the conclusion.

[Dewdman42]

I just did this test.

 

Scenario 1: ZebraHZ instrument feeding into 12 random FX plugins on a single channel

 

Scenario 2: ZebraHZ instrument feeding to chain of AUX channels with the same plugins and settings.

 

project is playing a series of 16th notes and seems to maintain a rather steady and consistent CPU usage..

 

Result

 

Single Channel used 3% average CPU on the system with the following meter in LPX

 

 

AUX chain used 4% average CPU on the system with the following meter in LPX.

 

 

In both cases, iStatMenus was showing more then one core active. By my reckoning, the single channel was more cpu-efficient then a chain of AUX plugins.

[bonebones]

I just did this test.

 

Scenario 1: ZebraHZ instrument feeding into 12 random FX plugins on a single channel

 

Scenario 2: ZebraHZ instrument feeding to chain of AUX channels with the same plugins and settings.

 

project is playing a series of 16th notes and seems to maintain a rather steady and consistent CPU usage..

 

Result

 

Single Channel used 3% average CPU on the system with the following meter in LPX

 

single.jpg

 

AUX chain used 4% average CPU on the system with the following meter in LPX.

 

multi.jpg

 

In both cases, iStatMenus was showing more then one core active. By my reckoning, the single channel was more cpu-efficient then a chain of AUX plugins.

 

Interesting, I am going to assume you are using 64 bit summing? Turn that off and I imagine that spike reduces for scenario 2.

[Dewdman42]

I was yes. will try 32bit summing later...But why do you think it would reduce the cpu for the chain of AUX's and not for the single channel scenario? just more channel summing going on I guess maybe... Anyway I'll try that tomorrow.

[m0joe]

Yes, this is happening to me now as well. I know people say you should back up a version before upgrading etc. But for me, this is the first time in ~10 years that Logic has just totally crashed upon updating. I guess I got lazy a few years and began to trust Apple. I have a recent time machine to go back to, but it'd be great if Apple (or someone on this board) could provide a fix.

 

I just downloaded my new version of Logic Pro 10.4.5 and now it won't open, it crashes every time. Any one else having this issue?

It is just a single session file that won't open from any disk. All older sessions open just fine. Very odd.

[roundabout]

The LPX performance meter shows only one thread active. But I'm still not sure what I'm seeing because:

 

1. The Activity Monitor CPU meter shows activity on six processors while LPX shows one thread.

2. The level of activity on the LPX meter and the six AM meters are in concert: they all rise and fall at the same time

3. If I increase the note density on a range within the MIDI region, on the next pass, the LPX meter and all 6 AM meters show increasing activity at the same time

 

2 and 3 above imply to me that what the LPX meter is showing on one thread is the same activity being shown on 6 processors in AM.

 

A thread can be assigned to a core, but that is not a fixed relationship. It can, and will, be moved to different cores when it has work to do. Basically, the system activity monitor is of little use in analyzing Logic performance. It doesn't tell you the important information about how Logic is allocating work to threads and it doesn't show you transient peaks.

[Dewdman42]

+1

[schlomojorgensen]

It's like a car without steering wheel!

[bayswater]

So the increase in idle processor percentage and decrease in user percentage is irrelevant?

[skijumptoes]

It's all irrelevant (to the music) if you're not utilising the CPU to the point that it actually causes you a problem! Edited June 19, 2019 by skijumptoes

[bayswater]

Well put.

[Dewdman42]

Interesting, I am going to assume you are using 64 bit summing? Turn that off and I imagine that spike reduces for scenario 2.

 

Re-ran the test with 32bit summing and you're right...with 32bit summing it was same overall avg cpu usage.

 

I also ran a couple more tests (with 32bit summing), to make one more comparison about whether the instrument track is selected (ie, in live mode) or not. It did not make any difference to the overall system cpu usage, however the LPX meter does show something interesting...though it may not really matter...

 

With the instrument track selected in Live mode, the meter looks like this, both with single channel and aux-plugin-chain approach:

 

 

If I select another empty dummy track, then the instrument track we are looking at is not in live mode anymore...and we get two interesting meter showings, with more then one thread getting used, but interestingly, the single track version seems to be using the second thread more then the aux-chain approach. It has the second thread up more often and to about the same level as the first thread. The aux-chain approach only occasionally brings the second thread in, and to much lower level.

 

Single Channel:

 

 

AUX-plugin-chain

 

 

But bottom line, looking at the overall system avg cpu, they all used the same 4% avg cpu. so this is kind of interesting, but I think irrelevant..

 

And as someone said....it doesn't really matter until you start getting dropouts... Most macs today can handle quite a lot of tracks without dropouts, so this is usually not even worth worrying about, but where most people run into dropout problems is when they try to reduce their latency to the lowest possible and use a cpu-hungry plugin on a channel in live mode. Then, it all funnels through one thread and if you run out of CPU power to handle it, you get your drop outs. I don't think any amount of chaining through aux channels or other tricks will get around the fact that in live mode, LPX puts all plugins in the signal path onto one thread and if your computer can't keep up with that, then you pretty much need to disable some plugins with low latency mode and/or increase the buffer size until you can record your part. It is what it is.

[stpro]

LPX can use all core while working but problem is When you do "File/Export/All tracks As Audio Files" here is using 1 core during this process..

i tried Mojave 10.4.4&LPX 10.4.5

[Sascha Franck]

Fwiw, the inspectors channel strip faders and knobs can't be controlled with the mouse wheel anymore. Very annoying. And a doubleclick onto sends or faders doesn't take you to the appropriate bus in the mixer anymore. I know. shift-clicking does a similar thing but it a) requires an additional key (which is bad if you need your left for something else) and b) doesn't select the bus, which is not great, either.

[bonebones]

Interesting, I am going to assume you are using 64 bit summing? Turn that off and I imagine that spike reduces for scenario 2.

 

Re-ran the test with 32bit summing and you're right...with 32bit summing it was same overall avg cpu usage.

 

I also ran a couple more tests (with 32bit summing), to make one more comparison about whether the instrument track is selected (ie, in live mode) or not. It did not make any difference to the overall system cpu usage, however the LPX meter does show something interesting...though it may not really matter...

 

With the instrument track selected in Live mode, the meter looks like this, both with single channel and aux-plugin-chain approach:

 

Livemode.jpg

 

If I select another empty dummy track, then the instrument track we are looking at is not in live mode anymore...and we get two interesting meter showings, with more then one thread getting used, but interestingly, the single track version seems to be using the second thread more then the aux-chain approach. It has the second thread up more often and to about the same level as the first thread. The aux-chain approach only occasionally brings the second thread in, and to much lower level.

 

Single Channel:

 

singlechan.jpg

 

AUX-plugin-chain

 

auxchain.jpg

 

But bottom line, looking at the overall system avg cpu, they all used the same 4% avg cpu. so this is kind of interesting, but I think irrelevant..

 

And as someone said....it doesn't really matter until you start getting dropouts... Most macs today can handle quite a lot of tracks without dropouts, so this is usually not even worth worrying about, but where most people run into dropout problems is when they try to reduce their latency to the lowest possible and use a cpu-hungry plugin on a channel in live mode. Then, it all funnels through one thread and if you run out of CPU power to handle it, you get your drop outs. I don't think any amount of chaining through aux channels or other tricks will get around the fact that in live mode, LPX puts all plugins in the signal path onto one thread and if your computer can't keep up with that, then you pretty much need to disable some plugins with low latency mode and/or increase the buffer size until you can record your part. It is what it is.

 

 

Very interesting and thanks for going to those efforts. It basically reinforces my thought process. There's no point in 64 Bit summing because realistically there is no audible difference (I am using a Burl Mothership with up to 192K pristine sample path) and the CPU hit is not worth the while. This will change when the nMP comes out in which there will be no disadvantage using 64 bit summing because there will be no CPU hit! And as you point out, unless you are playing on it - never have a CPU intensive channel or laden sample library engaged! If you are editing, open the plug in but select a different track!