New Logic update 10.4.5 is here!

[Dewdman42]

Yep. The only way to deal with hungry plugins like diva is to get the fastest clock possible even if it’s less cores

[bayswater]

I wasn't suggesting parallel processing. Just using auxes chained serially with one plugin on each channel.

[StevenTOAST]

I wasn't suggesting parallel processing. Just using auxes chained serially with one plugin on each channel.

 

Makes no difference. The entire chain gets processed to a sigle core. I tried by routing from track to aux via send knob and via output routing but the result is the same.

 

What makes a difference in my case is using Vienna Ensemble Pro on the same machine, it can distribute efficiently a single AUi to multiple cores - with minimum latency.

[Sascha Franck]

Fun fact, on my Macbook Pro, in the summer, my winter projects would stop playing due to CPU thermal throttling (22 Celsius indoor during winter vs 24-28 during the summer). 3.1 throttled to 2.6 Ghz. So I learned that 400 MHz can make a huge difference

 

Time to move to Qaanaaq (Thule) it seems.

[jonljacobi]

Perhaps you can spread the load over a chain of Aux channels. Maybe you could also spread the load over several instances of the VI? Each instance with a different note range.

 

With u-he Diva I don’t even need to play chords in order to get a fairly high core usage.

 

Regarding serial auxes, in my experience they still share the same core, I never noticed an improvement.

 

Fun fact, on my Macbook Pro, in the summer, my winter projects would stop playing due to CPU thermal throttling (22 Celsius indoor during winter vs 24-28 during the summer). 3.1 throttled to 2.6 Ghz. So I learned that 400 MHz can make a huge difference

 

Dry ice.

[jimdilian]

so there no way to (Toggle Track On/off) with a single "Key Command" anymore ???...... WHAT ? why ? that key command is very important to me I use it all the time.. don't understand ...SO '? do we have to Hit 2 different "Key Commands" for Toggle Track ON / OFF ?........ this is not good..... Edited June 17, 2019 by jimdilian

[JamesK]

regarding cursor on faders...as you can see in the video previously posted...the arrow cursor turns in to a tiny line (white/black/gray as needed) that indicates which fader you are moving, and importantly, gets the arrow out of the way of obscuring the scale/tick marks on the fader. I like getting the arrow out of my sight.

 

I observe the same behavior in 10.4.4. The "inconsistency" is, if you select a track in the arrange window, then move the cursor to a non-selected track in the mixer and drag, the cursor does not change. The cursor changes to the little "dash" when you move the fader on the selected channel strip. Once the cursor change has occurred the "cursor on fader" remains the little dash-line.

 

 

I have been getting that error with the Dash being stuck when moving to other areas as well.

[Ploki]

Perhaps you can spread the load over a chain of Aux channels. Maybe you could also spread the load over several instances of the VI? Each instance with a different note range.

 

Not really. You can’t start the second plugin in the chain until the first plugin has finished its processing on the process block. Audio doesn’t stream through plugins like it does through guitar pedals. There is a process block of data and each plugin gets its turn to operate on the block of data. The second plugin in the chain needs to see the final results of the first plugin for that process block before it can do anything. in theory a daw could possibly break up process blocks into smaller chunks of time so that while plugin 2 is working on the results from plugin 1, another thread could start working on the next process block for plugin 1. But what if the plugin is time based in some way such that the results from plugin 2 need to be taken into account by plugin 1 in the next process block, etc.

 

Fundamentally a plugin chain needs to happen serially because the actual computed results of each step along the way effect what the next plugin gets as input.

 

There may be some advanced situations where a daw could do some smart stuff to parallelize more, but remember that all the plugins have a fairly simple callback interface with the daw. Generally it’s probably better for the daw to keep things simple. When you have more then a few channels playing back it’s all moot anyway as all cores will be working away.

 

Wasn't that "theory" pretty much how DigiDesign TDM worked?

 

re:diva

it has multicore switch, but i had limited success with it.

[jonparadise]

Regarding the change in behaviour of the Toggle Track On/Off key command, I'd guess it's because Logic currently has no way of knowing if you want to just switch off the CPU usage of the track, or disable it completely.

 

So while switching on will work - as whether the track is disabled or CPU bypassed, it will 'switch on' - switching it off can now mean more than one thing.

 

Hopefully they'll add additional key commands in upcoming updates.

[nor17]

What makes a difference in my case is using Vienna Ensemble Pro on the same machine, it can distribute efficiently a single AUi to multiple cores - with minimum latency.

 

I have the same experience; on a 4790 imac (8threads) some "heavy" kontakt libraries play with problems (crackling) on Logic solo, while using LPX and Vienna on the same imac and kontakt loaded into Veppro give better performance. Even better than increasing the latency on LPX compared to the double buffer of Veppro.

[Sascha Franck]

I have the same experience; on a 4790 imac (8threads) some "heavy" kontakt libraries play with problems (crackling) on Logic solo, while using LPX and Vienna on the same imac and kontakt loaded into Veppro give better performance. Even better than increasing the latency on LPX compared to the double buffer of Veppro.

 

That's quite astounding, especially given that in general, Logic can still be considered one of the more efficient sequencers and that the computer further has to deal with whatever overhead of an additionally running program.

Hm, perhaps I should've jumped onto the deal Vienna had running a while ago...

[StevenTOAST]

(posted in wrong thread, my apologies)

[jimdilian]

Yes I think it was a The wrong way of doing things.. with "Tonggle Track On/off" in the mean time.. while They FIX this..

I just cannot work without that Key command working as it should.. I don't understand Logic Pro X Theme..

How they cannot ThinK about this.. ??.. it's quite amazing.. it is more than obvious that it need it new commands changes.. especially with the "New" feature of Turning OFF a Track and it Effects.. maybe the Logic Pro X Theme need more Money or More PROfesional Programmers.. who knows..?..

this update has been the Worst update of Logic Pro X for me.. a lot of things has NOT been fixed.. and More problems..

amazing how One of the most Richest Companies in the world.. delivers Things this way..a real disappointment.

 

Hopefully they'll add additional key commands in upcoming updates. maybe in 7 months.

[jonljacobi]

As to Apple fixing this stuff, more money and better programmers sounds like a solution, but you have no idea what what the code base they are working with is like. Is it easy to decipher? DAWs are very, very complex pieces of multi-tasking software with loads of interdependencies and Logic is more complex than most. It ain't easy, and especially not easy to get up to speed on.

 

I'm not saying it can't be done, but generally speaking, the best people to fix a problem are often those that created it.

 

BTW, I've been meaning to say this for a while, but I have noticed that if you make a video or GIF of the issue and send it to a company, things tend to get fixed a lot faster. Human nature and not having to figure out exactly what you are talking about. I have to do this all the time for my work.

[schlomojorgensen]

On a side note regarding performance and single core overload: I like to record myself singing a lot of the time, and I also like to have quite a few fx going in realtime, like eq, compressor, delay and reverb and so on, to inspire myself as a singer. To avoid single core overload I load up my "live" fx chain in Apples "au lab" instead.

That is, I listen to my singing in au lab as I play my song in Logic AND record in Logic. So: this enables me to record without getting cracks and artefacts in my recording. Impossible to do in Logic otherwise!! Amazing that this workaround works at all. (Of course the recording track in Logic is plugins- free...)

 

[skijumptoes]

As to Apple fixing this stuff, more money and better programmers sounds like a solution, but you have no idea what what the code base they are working with is like. Is it easy to decipher? DAWs are very, very complex pieces of multi-tasking software with loads of interdependencies and Logic is more complex than most. It ain't easy, and especially not easy to get up to speed on.

They should have done the rewrites before releasing LPX in that case, LPX felt like work in progress on release - was an obvious reskinning of LP9 at the time with some cool new features - it didn't have the changes Final Cut Pro (X) had, for example.

 

In the meantime they've really been bringing it up to speed, in certain areas it does need an overhaul, question is would you risk pulling it all apart now? I don't know how long they can keep bolting elements on, but it is stable, i find the interface to be great and snappy still, one of the most efficient DAWs out there, and so many people rely on it as it is. Any major changes will break certain elements of the environment which would really cause upset.. People rely on certain tricks for their setups to work how they have been for years.

 

Can't really fault it at it's base level. Sure, some elements don't fit my workflow too well (In regards to external multidevice MIDI connectivity mainly), and some DAWs have features such as chord track/progressions that would fit into the general design of what Logic is... Some PDC issues, niggly bugs with the zoom and regions... But hey, it's not a broken mess like some people like to paint... Far from it.

[jonljacobi]

I think it's pretty stable all around. It certainly gets the job done. I've found it to be very much an onion, and I've continually changed the way I use it over the last year. Actually, a month ago I would have sworn I would never work with separate windows again, yet I now keep a floating transport and a separate mixer which I use most of the time rather than the info pane.

 

Also, my needs are pretty simple, and I very much appreciate that I can get all the stuff I don't use out of the way and define my own key commands.

 

That said, with the pretty much free-form modular routing and javascript hooks, it's got to be a very complex beast. It simply can't be that easy to get your head around if you're new to it, even if it's explicitly written (no obscure variable/function/procedure names) and well commented and documented.

[Sascha Franck]

Yet another crash when loading a Kontakt patch, nothing else running.

I really don't think this is ready for prime time at all. I had the occasional crash before, but it has always been related to certain non- or just half-supported plugins. Kontakt certainly doesn't qualify as that.

And as said, 4.5 already crashed twice when trimming a wavefile, so there's nothing esoteric I'm doing, just basic every day stuff.

[stpro]

I have no information but probably They will give 10.4.6 before 10.5

[stratquebec]

I hope so! Imagine how buggy would be 10.5...under Catalina... OMG!

Apple should stop the development of new features of MacOS and Pro apps for a full year and concentrate on bug fixes.

[bayswater]

Perhaps you can spread the load over a chain of Aux channels. Maybe you could also spread the load over several instances of the VI? Each instance with a different note range.

 

Not really. You can’t start the second plugin in the chain until the first plugin has finished its processing on the process block. Audio doesn’t stream through plugins like it does through guitar pedals. There is a process block of data and each plugin gets its turn to operate on the block of data. The second plugin in the chain needs to see the final results of the first plugin for that process block before it can do anything. in theory a daw could possibly break up process blocks into smaller chunks of time so that while plugin 2 is working on the results from plugin 1, another thread could start working on the next process block for plugin 1. But what if the plugin is time based in some way such that the results from plugin 2 need to be taken into account by plugin 1 in the next process block, etc.

 

Fundamentally a plugin chain needs to happen serially because the actual computed results of each step along the way effect what the next plugin gets as input.

 

There may be some advanced situations where a daw could do some smart stuff to parallelize more, but remember that all the plugins have a fairly simple callback interface with the daw. Generally it’s probably better for the daw to keep things simple. When you have more then a few channels playing back it’s all moot anyway as all cores will be working away.

I thought about this and decided to try it out. I created a project wth one EXS24 track with KH Concert Strings 2 loaded, and then put 16 instance of Wavs Q10 in the insert slots. The track has a load of scales all superimposed on each other so there are a lot being played at any point. Let that play for a few minutes and got a screen shot of the CPU chart, shown here at One Channel.

 

Then I changed the output from Stereo out to Bus 3 > Aux 1, changed the output of Aux 1 to Bus 4 > Aux 2, and so on until there were 15 Aux channels. I left one instance of Q10 in the Instrument tracks and move the other 15 instances to the 15 Aux tracks. So the plugins are in series. Played it and got another CPU chart shown as Sixteen Channels.

 

You can see that going to more channels doesn't increase the number of threads, but even the one channel version was using 6 threads on a 6 processor i7. And the overall load is different across the processors, the variation in the load is the same, implying that the load from the EXS24 is spread across more than one processor. (When Logic is idle, nothing registers on these charts other than the occasional blip). The more interesting thing though, is that the 16 channel version clearly uses less CPU.

One Channel

Sixteen Channels

[jonljacobi]

I have no information but probably They will give 10.4.6 before 10.5

 

I'm guessing it's not far off given the bugs reported here and the number of changes.

[Dewdman42]

some of the multi threads are happening at the OS level, not within LogicPro. If you look at LogicPro's CPU meter while doing that, you will see its only using one core as far as its concerned. But Logic makes calls to OSX and OSX may fork threads appropriately. I almost never observe my system CPU to be completely on just one core....

[Dewdman42]

Anyway Logic also says in its docs somewhere if you have it in Playback+Live multithreading mode, then the currently selected channel...the one you are playing through and need low latency, etc.. will be using a single core. And from my own tests I recall that even if I setup extra aux's, if that live channel was bussed to them, they all shared that one core.

 

If you switch to Playback only mode, then Logic adds some latency and does some other smart things to spread the load around a little more somehow, but this is generally not the mode you want to use if you're trying to play in a part and need low latency on a hungry plugin, which is really what we're talking about.

[bayswater]

Dewdman, if you were addressing those last two posts to me, I have two comments: 1) it's pretty clear from watching the Activity Monitor that as the load increases in Logic, even on a one VI one track project, the pattern of that load shows on more than one processor. 2) One of the early posts was saying that a chain of plugins on a VI channel was using up a lot of CPU. I suggested that splitting the load over several channels might help. While the load is not necessarily being split over processors, the version of this project with 16 channels clearly uses less CPU than the version with one channel. It seems to me that regardless of the reason for this, it suggests an approch to deal with CPU overload. load.

[Dewdman42]

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

[bayswater]

No. I'll have a look.

[bonebones]

Guys I'm stumped here. It seems the project setting of 'Only Load Plugins needed for Project Playback' is defaulted to on in all of my templates. That means the hundreds of tracks that I write in 3rd party AU DAW's like NI Maschine don't get loaded by default!!! I loaded tunes in front of clients and they were like - what have you done to the tune? only to discover that I had to click on Maschine for it to load! No Midi and no Audio doesn't necessarily mean something is not running/triggering in the background. I'm concerned that I have to forever remember that. At the very least can't they have left it off as default in existing projects? Bizarre. Anyone else?

[Dewdman42]

I agree, its a cool option, but the default should be for it to be off and since its a project setting, you have to at least once when you open the project, uncheck the box in the project settings.

[robinloops]

The ability to override the option globally would be a good idea too.