Optimizing Logic a bit.

Hi,

Just performed the Logic multithreading benchmark test at Gearslutz and tried to squeeze as much out of it as possible. That very test is dealing with plenty of EXS instances all running the same instrument (not sure what that does to shared samples, just saying...) and some internal plugins.

You can have a look at the details here:

https://www.gearslutz.com/board/apple-logic-pro/371545-logic-pro-multicore-benchmarktest.html

I posted my (pretty amazing, fwiw) result on the (currently) last page and also posted my settings, but if you don't feel like heading over there (or before the post gets lost), here's the essential things I've changed again.

In the audio setup menu, I'm chosing these:

- High precision (64bit) summing - seems to make no difference to "normal" for this very test, btw, but it might make a difference at more complexed mixer layouts.

- Number of processing threads (makes a difference compared to "automatic"): 24. That's the maximum on my machine, my guess would be that different machines offer different numbers here. Check out the maximum.

- Multithreading set to playback and live tracks (makes a difference, at least once you select one of the actively playing tracks and not choose an empty track, which has been the trick to squeeze the last ounce of juice out of earlier versions).

- Processing buffer set to "large" (makes a difference).

In the EXS, my settings are:

- EXS "Virtual Memory": Disk speed set to "slow" - from all I know (and it's a pretty safe bet in this case...), this will allow the EXS to load as much of the sample(s) as possible into your RAM rather than reading things from your drive. I recommend to check this setting out as it does make a difference on some machines. Especially in these days of large RAM amounts, I would think that loading as much as possible into it will speed up things. Over here it does (but it didn't do much on my old Macbook with just 4GB RAM and a fast SSD).

In combination, these settings make up for a pretty noticeable difference compared to the default settings - and while things may look a bit different in more realistic scenarios, over here the difference is noticeable in all projects, sometimes a little more, sometimes a little less. I suspect certain settings to affect the "snappyness" of Logic (processing buffer) and others (namely number of processing threads) to possibly slow down other processes/programs running in parallel with Logic, but I couldn't care less about those.

Fwiw, I have no idea how (and if so, how much) the "wrapped" EXS siblings, namely Drum Kit Designer, Studio Horns and Studio Strings, are affected by the EXS' virtual memory settings. As they're (at least that's pretty likely) using the EXS engine under the hood, they might be - after all, the EXS settings (which you'll find in the "Options" pulldown on the EXS GUI, btw) are global (not exactly elegant, if you asked me, Kontakt and others are doing it on a per instance/patch base). It's also likely that with the "new" (and IMO rather inefficient...) sample format they're all using (very large "consolidated" CAF files instead of individual samples), RAM usage might get through the roof on some machines. I might check that out a bit more whenever I find the time.

Perhaps that's useful to whomever.

- Number of processing threads (makes a difference compared to "automatic"): 24. That's the maximum on my machine, my guess would be that different machines offer different numbers here. Check out the maximum.

What kind kind of difference did you see when adjusting this from Automatic, was it significant higher track count? Or some other difference?

I've noticed that when i run such tests one of my cores never seems to take the load (i.e. only 7 of the 8 populate), so wondering if i should change this on my machine also.

What kind kind of difference did you see when adjusting this from Automatic, was it significant higher track count? Or some other difference?

On that particular test, I noticed a higher track count - which equals more FX (as there's some on each track), too. Generally, this also seems to result in a bit smoother operation, but I haven't been fooling around with it for too long so far.

I've noticed that when i run such tests one of my cores never seems to take the load (i.e. only 7 of the 8 populate), so wondering if i should change this on my machine also.

In that case, I'd defenitely try to set the multithreading to live and playback. Yet, as long as you're on any track holding plugins, ready to be played (as with a virtual instrument track or a record armed audio track), it still seems as if Logic is reserving its resources for that particular track, also switching it to low latency operation in background (whereas all playback tracks are using some additional (pre-)buffering).

Whatever, defenitely doesn't do any harm to load an own project that's already stressing the CPU a bit and fooling around with these settings. I mean, there's nothing to lose. If things don't work, just go back to the previous settings.

In my case, the most noticeable difference seems to come from the processing buffersize. Defenitely making up for more of a difference than switching between 32 and 64 samples. But then, that Zoom UAC-2 seems to perform extremely well at lowest buffersizes, In that test, I even got one more track running at 32 samples than at 64.

Whatever, the combination of all these things can make a noticeable difference - but from what it seems like to me, the jury isn't out on any "this is the definite best" setting yet. I'd guess that, apart from computers being different, it also depends on what sort of projects you're usually dealing with.

In my live setup, I have 15-24 audio tracks in record with 2-4 FX each, a couple of common reverbs and delays plus 1 or up to 6 live VIs (the latter in a folder stack because they are all fed from the same source and I need to quickly rec enable all those but just selecting the folder track).

The VI track stack definitely likes Multithreading set to Playback + Live, thus enabling buffer settings as low as 64. However, the recording tracks do not approve and crackle like mad until I switch back to Playback.

I've never ran lower than 256 samples.

But generally i live monitor via a desk so it's only when i want to monitor through Logic with the FX chain that Latency and buffer settings plays any significance, and thus the recording can sometimes exhibit timing issues, which causes re-takes.

It's interesting reading people using 32/64 samples though - that just seems an impossibility based on my setup, insanely low!

And thanks for the tips Sascha, looking forward to seeing if i can squeeze a few extra CPU, or even better drop down to 128 and see how that goes on larger projects.

It's interesting reading people using 32/64 samples though - that just seems an impossibility based on my setup, insanely low!

It's all about how you prefer to work - or in my case: have to work. At least for the time being that's gonna be at home (had to move out of my dedicated music refuge, quite a drama, been in there for around a decade, now the owner is claiming it for himself...), so fooling around with my rather large pedalboard (let alone my amps) is out of question. Hence I'm now using software amps whenever possible. And it's not a bad experience by any means (I'm used to DI guitar sounds anyway, having played musicals and other theater stuff for almost ages), but low latency performance is absolutely crucial for that way of working.

And fwiw, most of the high system load at lowest latencies comes from the interfaces drivers. In case they're programmed properly (possibly the leader of the pack: RME), you will really not notice much of a difference in CPU consumption between, say, 128 and 32 samples. It's just that many companies simply don't seem to care about it much, at least not in the somewhat lower end pricing area. Fortunately Zoom came along with the UAD/TAD interfaces, which are really excellent for their prices.