How to reduce CPU load within Logic and CPU threads allocation

Hello, guys

 

I noticed that when I use Omnisphere 2 the performances of Logic drop down. I know that Omni is known to be kind of a cpu hog, and I would like to know if you got any suggestion. Also, I noticed that when I open my CPU meter in Logic, only one of my 12 threads is being used. I guess that's kind of a problem, as I would like all the threads to be working so that the CPU load could be less.

For non-multicore-enabled plugins (ie, most of them), the plugin has to be processed on one core for performance reasons. That's why when you play an instrument, one core is loaded heavily, as that instrument (and any plugins on those channels) is processed by one core in live mode.

 

It's possible to run out of CPU resources if a plugin requires more CPU processing than one core in your CPU can handle - even if you have eg 7 other cores sitting idle.

 

This is why fast single thread performance is useful for heavy CPU plugins like Omnisphere.

 

From your screenshot, you seem to have plenty of CPU headroom, so everything is normal.

 

The fact that some people would like to see the CPU load evenly distributed across their cores is a psychological thing, but doesn't bear much relation on what is going on technically. Leave Logic to handle how to distribute loads, it does it fine.

Ok, now I start to get the picture. Still, I see that this has an impact on Logic performances. For instance, the column on the volume fader they are lagging when going up and down, whereas normally, with no heavy stuff going on, they are fluid. Does it mean my machine is not powerful enough? You can see my specs here on the bottom.

Your machine is way more powerful than mine. I get no display lags in general, but I'm not running retina dsplays or anything. The graphics are always lower priority than the audio processing. If you are getting a laggy GUI when running Omnisphere in the above configuration with the CPU load you display in your screenshot, then something is wrong.

 

However, if you're machine is heavily loaded and really can't cope doing everything you are asking it to do, then you'll need to use less resources (bounce, freeze etc).

A few things:

 

Logic appears to dedicate at least one thread to "audio output," using other threads to calculate information that can be done in parallel. It knows how the computational workload has to flow, and it knows how to apportion all of the available threads properly.

 

How you set up your mixer seems to have a lot to do with how well it performs. Remember that library patches are built to be independent, easily added and removed, and they are of course "implemented" in the mixer. (Each one is a little mini-lesson in what the mixer can do at the hands of a professional sound designer.) So, there's a lot of redundancy in that final setup and you can usually simplify it – at the cost of now not being able to so-easily add and remove factory patches. (And, frankly, I find that this makes the whole thing much more manageable.) Also, many patches include filters and stuff that ... well, solo them and listen for yourself ... "do they actually make a difference that I can hear?" If not, switch them off. You can always switch them back on.

 

And finally: No matter how powerful your machine is, I still think it's a very good idea to get to know "bounce" and "freeze." Logic's designers obviously put a lot of thought into making these facilities powerful and easy to use. When you do so, Logic no longer has to calculate "one second's worth of sound" in one second or less: it can now safely take 1.002 seconds or more. The "we must do it in real time" constraint is completely gone. And, it no longer has to consider "everything at once" – unless you want it to. What you get is a pure-audio track – a "stem" – which you can re-generate at any time, and you mix from there.

 

This usually creates a multi-step workflow, which requires you to plan ahead a little, and it does change the nature of what you're focusing on at any particular time, but I find that this is really not a bad thing. For one, now you are listening much more closely to a generated track that typically represents part of your intended final product. The track has less "stuff" going on overall, so its characteristics and any flaws will now stand out more clearly. Put the fine-shine on this part of the project, then move along to the next one. Then, on to the next stage and so on.

 

Yes, it's really amazing what Logic can do with "just plop things onto the screen and hit Play." But, that's not the only way to do it. The "old school" workflows still work well, and Logic's engineers planned their product from many angles.

So,

 

The Logic GUI related to the fader volume is lagging when I use some patches instead of others. I guess it' because of the heaviness of those.

I read somewhere there's a way to split the load into different threads, but at the same time I trust what des99 said and maybe I shouldn't worry much about it.

 

As far as freezing is concerned, I usually end up using multioutput Kontakt instances for saving power, and with multioutput I cannot freeze. I have the on/off button but you have to save and revert to actually make it work when needed. So, any suggestion about this?

I read somewhere there's a way to split the load into different threads, but at the same time I trust what des99 said and maybe I shouldn't worry much about it.

 

You can certainly split the load, of say a channel with 14 plugins on by moving 7 of them to a different channel strip. But you can't move, say "half a plugin" onto a different channel strip, so if *one* plugin alone is maxing out a core in realtime, then your computer is struggling, to try and reduce CPU consumption (play less voices, reduce long release times, play lass layered patches, turn effects off and so on). You can always turn those things on again after you record the part and freeze of bounce.

 

As far as freezing is concerned, I usually end up using multioutput Kontakt instances for saving power, and with multioutput I cannot freeze. I have the on/off button but you have to save and revert to actually make it work when needed. So, any suggestion about this?

 

Well, if resource consumption is a problem, then I'd suggest moving away from multi-output/multi-timbral Kontakts and instead use single instances of Kontakt for each CPU heavy part - that way you can freeze them if necessary. Or you can bounce - but this is all dependent on your projects and workflow so you'l need to best assess these things for yourself in light of how you need to work.

Great, now I definitely have a better view of the matter, as far a splitting the load its concerned.

 

About multi-output instances, I always though that having just one instance of Kontakt for, let's say, all the violins1 single articulations, would be better. I usually use 16xstereo outputs, load maybe 8 patches, one for each articulation, and then create a separate track for each of those patches, having them related to the main one. I always thought this would be less heavy on the cpu or memory than opening a single instance of Kontakt for every single articulation.

The CPU load is how many voices you have to process, and what CPU each of those requires, plus the effects if they are also running. It isn't any more or less efficient by splitting that over multiple instances, as the total voices and CPU calculations are the same in both case. (Although you might be using more effects CPU depending on what the instrument is doing.)

 

However, you gain some flexibility with multiple instances and not having to deal with Kontakt's awful multiple-output assignment, at the expense of more tracks to manage and a bit more RAM used (as each instance requires a certain amount of memory - the sample memory footprint though will be the same.)

 

So, swings and roundabouts really, but understanding the resource allocation helps better inform your decisions as to how best to manage your available resources.

Alright, perfect! I'll now put these notions to work

Hello, guys

 

I noticed that when I use Omnisphere 2 the performances of Logic drop down. I know that Omni is known to be kind of a cpu hog, and I would like to know if you got any suggestion. Also, I noticed that when I open my CPU meter in Logic, only one of my 12 threads is being used. I guess that's kind of a problem, as I would like all the threads to be working so that the CPU load could be less.

 

There's several AU Instruments that run high, but the issue is also the presets within a AU Instrument.

The problem I ran into is, yes I'll use freeze or bounce the track, but I can't even play the instrument first because the CPU runs high on the last single core on my MacMini.

 

So to get around that I use an external method, then once I MIDI record using that external method, I move that recorded MIDI region to the internal AU Instrument, then freeze the track, now I'm good to go.

 

I don't know exactly what you mean by an "external method", but sure, if you run the standalone app or some other host outside of Logic, and you look at Logic's CPU meters while doing it, then Logic is not registering the load of things that are not running within Logic.

 

It doesn't mean you have a magic CPU, or the instrument somehow decides to be much more efficient running in a different host...

If the CPU has to decide between redrawing a screen graphic or producing sound, it's going to penalize the screen-draw.

 

I still recommend that you explore freeze/bounce. You probably focus your attention on one area of the project at a time. Well, when you think you've finished that part (at least for now ...), then go ahead and freeze or bounce it.

 

"Bounce in place" is appropriate when you think that this section is really finished – at least for now. You're satisfied with your plugins and your automation. This prints a new audio-only track that represents the final output after all of these things have been considered, then mutes the sources.

 

"Freeze" is intended for the case when you might wish to make additional adjustments, but you want to get "the computational heavy-lifting of producing the basic instrument sound" off your plate. And you can "freeze" it at two points: before or after the plug-ins. Freeze is designed to be extremely-unobtrusive: "just toggle the snowflake."

 

Both of these are intended to be "easily re-doable." You actually aren't ever "losing" anything. You're just giving Logic the opportunity to pre-calculate what it would otherwise be forced to re-calculate every single time you hit "Play." And, since the computer is now generating the output "to a file," it is not constrained by "in real time" in generating it.