DAW Stress Test: Logic/ProTools/StudioOne/Cubase

[Dewdman42]

The difference is the added buffer is so the CPU can compute the data in even longer time periods before spitting it out.

Yes that too, but its not only that.

With pre rendering everything is pointing to it being the equivalent of a hidden freeze file. So the whole thing or large chunks are rendered to a hidden file.

speculative! you don't know if its stored in a file or memory. The point, however, is that its computed before playing back...so that that particularly DSP doesn't have to be computed during playback.

This is how these two technologies were explained to me. I reserve the right to be misinformed,

fair enough. hehe.

DP from what I can tell was raw, not much of a buffer until NextGen, and it I think does exactly what it says it does, renders amounts of a track to probably virtual RAM.

there ya go, you made up for the earlier hidden file comment...

Mostly DAWs will not pre render or freeze tracks that are sending to Aux's, have multi audio out etc.

how do you know that?

That's what I was getting at, and this doesn't seem to be a problem for added buffering though, hence Logic looking great with VEP.

Sure, but most DAWs see VEP the same way, at least DP treats networked plug ins like VEP and UA etc. the same way it treats external instruments. I'm all in on the idea that Logic's smooth buffering is why it's handling VEP better than the others that are not able to pre render VEP tracks.

No, its not an external instrument, not in DP either. DP handles VEP quite well, as well as any of them. It may not be pre-renderable, but DP still benefits from the buffer as always and VEP itself is padding up the buffer when it takes it on a non-armed track.

Logic just overall is using less CPU to play a 100 track orch project, both with or without VEP involved.

On a similar note MOTU guys stated at motunation that with NextGen PreGen™ (lol at the market speak!), it was much smarter to take instances of Kontakt and separate out instruments into their own tracks, since pregen would not work on multi out instruments, but would free up resources on single out Kontakt tracks.

Right so in the case of DP anyway, they are not doing next Gen Pre Gen on the aux outs.. But Next Gen Pre Gen is really something different then what VEP is doing to pad out the buffer size...even on DP.

The red Record button on the track, should not be lit red.

Then it wasn't.

Mostly what you get with heavier plug ins, is CPUs with no overhead left for other plug ins. I would be willing to bet though that I could load those 9 instances in DP and Logic with light CPU plug ins, because probably the CPUs are at 70-80%, enough to where they will not load any more instances of Diva. So in that sense you have a point, it's possible that Reaper in my tests is loading CPUs at a more refined rate than DP or Logic therefore getting more than 12 instances with it's Adaptive FX processing, but that it will not be able to handle as many extra FX on those same tracks.

You're still missing the point. do you want to test the performance of Diva or the performance of the DAW that is calling Diva?

Some of it is VEP, I do believe that Logics process 's for saving CPU is more friendly towards what are traditionally unfriendly processes (towards pre rendering) like VEP. I have VEP here, so I can test that as well, are you running it on the same or a separate machine?

As you can see my my result graphs, the performance was better both with and without VEP. Actually the best of all performance slightly was without VEP.

VEP has been rumored for a long time to do some smart core management, but again, we don't really know that...and the tests I've done I haven't really noticed a substantial difference... I think its a poor justification to use VEP. Use VEP for the workflow it provides.

[machinesworking]

Mostly DAWs will not pre render or freeze tracks that are sending to Aux's, have multi audio out etc.

how do you know that?

Because they say it right in their manuals. In DP you can open the Effects Performance meter see clearly what is being pre rendered and what is not. There are a few DAWs that can freeze Aux tracks, it's rare, must be a bitch to code I guess?

Sure, but most DAWs see VEP the same way, at least DP treats networked plug ins like VEP and UA etc. the same way it treats external instruments. I'm all in on the idea that Logic's smooth buffering is why it's handling VEP better than the others that are not able to pre render VEP tracks.

No, its not an external instrument, not in DP either. DP handles VEP quite well, as well as any of them. It may not be pre-renderable, but DP still benefits from the buffer as always and VEP itself is padding up the buffer when it takes it on a non-armed track.

Logic just overall is using less CPU to play a 100 track orch project, both with or without VEP involved.

Open VEP in DP10, open the Effects Performance Window and look at the results. I have a few VSTis and VEP MAS plug ins open right now, no tracks record enabled. The regular VSTi's are reading as PG or PreGen, the VEP tacks are reading as RT or Real Time.

On a similar note MOTU guys stated at motunation that with NextGen PreGen™ (lol at the market speak!), it was much smarter to take instances of Kontakt and separate out instruments into their own tracks, since pregen would not work on multi out instruments, but would free up resources on single out Kontakt tracks.

Right so in the case of DP anyway, they are not doing next Gen Pre Gen on the aux outs.. But Next Gen Pre Gen is really something different then what VEP is doing to pad out the buffer size...even on DP.

Right, it's just an efficient MAS plug in running in Real Time. They aren't big CPU pigs because they don't run inside your DAW, modern 12 core machines like we have like multiple applications open VS allocating resources to one application, so VEP works quite well to save CPU even on the same computer. Even though it's not using any PreGen etc. type rendering. You can see how a DAW might do this with Reaper, it shows you in it's performance meter that unarmed instrument tracks are buffered at a much higher rate than regular tracks..

You're still missing the point. do you want to test the performance of Diva or the performance of the DAW that is calling Diva?

Hmm? You're coming up with weird logic here. Diva isn't any different than any other plug in terms of taking CPU beyond being hungry. The problem with Low CPU plug ins is they barely stress systems like ours, and the problem again with not doing tests to the limit of a computers ability is DAWs do not load plug ins and general CPU in a linear fashion. I'm sitting here with 102 instances of Massive in DP10, the system CPU is reading 97%, I just loaded another 24 instances and the system CPU literally only went up 1%. They all do this, in wildly different ways, so DAW X will look like it's about to go over your CPU limit, and it will take on almost double what it should, DAW Y will crash in the same circumstance. This is why to failure tests are important, because it not only eliminates the plug in, it eliminates the computer. The percentage difference between DAWs is relatively speaking consistent regardless of the computer setup. Meaning, Logic at the same settings will be the same percentage better or worse than Reaper, DP etc. etc.
The only advantage of less CPU intensive plug ins in a stress test is more precise readings, i.e. 9 instances of Diva VS 19 of a plug in with half is CPU consumption.

As you can see my my result graphs, the performance was better both with and without VEP. Actually the best of all performance slightly was without VEP.

Yes, because VEP runs in real time, but Logic can handle that better than other DAWs. This is the best guess as to why. In the end you didn't experience or at least point out any problems with any of your setups, you're just seeing larger and smaller numbers, which mean nothing.

I'm absolutely not trying to be a dick here, I just really think it's important to be as precise as we can about this. Doing tests not to the limit of your DAW and system proves nothing. My results with DP where it piles on way more than can be logically expected could have been any DAW, most of them seem to load a lot of CPU for a normal project, then kick into overdrive for huge projects.

I've messed with stress tests and various DAWs for about 20 years. I got really interested when I noticed how badly Live performed compared to Logic, so I spent a good amount of time researching it. Osxaudio.com used to be a great resource for developers stepping in and talking about this sort of thing. I'm by no means an expert, but I'm a qualified amateur at this. I'm really not trying to win any argument here, I'm just really interested in how these tools we use and love work. This is why I'm so adamant that just running CPU measuring apps while running a big set isn't a true test of the performance or power of your DAW, or computer for than matter.

[Dewdman42]

Open VEP in DP10, open the Effects Performance Window and look at the results. I have a few VSTis and VEP MAS plug ins open right now, no tracks record enabled. The regular VSTi's are reading as PG or PreGen, the VEP tacks are reading as RT or Real Time.

you are conflating three seperate concepts into two. Just because something cannot be pre-gen'd does not mean its handled like an external instrument. Just because DP calls it real time on the window for musicians does absolutely NOT mean that its running in true real time like an external instrument. Sorry but you are just plain wrong about VEP here.

Right, it's just an efficient MAS plug in running in Real Time.

No, nothing runs in actual realtime, that is just how MOTU labels it for musicians to distinguish between Pregenned and not-pre-genned, but not-pre-genned is still not real time in the same sense that an external instrument is.

Hmm? You're coming up with weird logic here. Diva isn't any different than any other plug in terms of taking CPU beyond being hungry.

Nothing wrong with my logic you just haven't understood it and I'm tired of trying to explain it.

The problem with Low CPU plug ins is they barely stress systems like ours,

Again you're missing the point. You will need more tracks with lighter plugins in order to stress your DAW and isolate that from seeing just how many Diva instances you can do. But anyway I give up...

The only advantage of less CPU intensive plug ins in a stress test is more precise readings, i.e. 9 instances of Diva VS 19 of a plug in with half is CPU consumption.

No. Read why post again if you care to understand, its already explained twice.

Yes, because VEP runs in real time

No absolutely not. Real time according to the DP Gui, but its not actually real time. You are misunderstanding core concepts here. its not pre-genned, and that only applies to DP.

I'm absolutely not trying to be a dick here, I just really think it's important to be as precise as we can about this. Doing tests not to the limit of your DAW and system proves nothing.

according to you. I do not agree. How the machine performs under typical work loads is also interesting to know. And by the way, nobody set out to "prove" anything. Just present the data.

Anyway you have tired me out and I don't wish to engage with you any more. Good luck

[Psuper]

I just know its not worth my time -- people believe what they want no matter what expertise and experience is involved, or lack thereof.

[Jim Rosebrook]

Took a few hours today to further explore the relative CPU efficiency of DAWs on the Mac Platform.

Some people theorize that Cubase in particular may grab a larger amount of CPU Usage with a low track count, but that it would be less steep in CPU Usage as track count increased.

Today's testing explored this issue. Used current versions of all software involved in the testing (Sep 15, 2019) and used only 3rd party plugins. Increased the track count in blocks of 10. Used Intel Power Gadget to measure the CPU Core Usage, let each session run in a loop for several minutes until all measurements were stable.

Point of failure for Cubase appeared at 120 tracks, Point of failure for Logic appeared at 180 tracks.

The relationship of CPU Core Usage vs Track count for both Logic and Cubase was directly proportional.

Many reasons to prefer one DAW over another. Use whatever makes you happy.

CPU Core Usage 2.jpg

[Psuper]

There's too many variables people frankly know little about to make a proper comparison, which is why you take any 'results' with a cup of salt, and can typically toss them out anyway.

No one knows how an individual system is setup. Any performance test needs to be on a newly clean slated system #1. Then apps should be loaded on their own drive (at the very least a clean equal partition on the same drive) only after all the core system hardware and software updates were done (and done only once if possible). And this is only the tip of the iceberg as the very first steps to take, not even getting into the system core settings or inner setting of each app which there are dozens, many of which can severely affect performance.

If you guys are just putzing around then cool. However If you are trying to be conclusive in any way you need to put the work in, and show your work.

[Jim Rosebrook]

Use whatever DAW makes you happy. Both Logic and Cubase perform well.

I do believe my system is fairly typical of what someone might have as a up-to-date, well-powered laptop rig. Nothing on it should be hampering Cubase in any way. For my purposes, this testing was rigorous enough to indicate that Logic has an edge over Cubase in CPU efficiency at this moment in time.

My curiosity is satisfied anyway.. which is all this is about for me.

The emerging interactive plugins (iZotope) that can't be frozen and used to their full benefit makes this something to think about...

[Coxy]

There's too many variables people frankly know little about to make a proper comparison, which is why you take any 'results' with a cup of salt, and can typically toss them out anyway.

No one knows how an individual system is setup. Any performance test needs to be on a newly clean slated system #1. Then apps should be loaded on their own drive (at the very least a clean equal partition on the same drive) only after all the core system hardware and software updates were done (and done only once if possible). And this is only the tip of the iceberg as the very first steps to take, not even getting into the system core settings or inner setting of each app which there are dozens, many of which can severely affect performance.

If you guys are just putzing around then cool. However If you are trying to be conclusive in any way you need to put the work in, and show your work.

But Logic came out on top here.

[Psuper]

There's too many variables people frankly know little about to make a proper comparison, which is why you take any 'results' with a cup of salt, and can typically toss them out anyway.

No one knows how an individual system is setup. Any performance test needs to be on a newly clean slated system #1. Then apps should be loaded on their own drive (at the very least a clean equal partition on the same drive) only after all the core system hardware and software updates were done (and done only once if possible). And this is only the tip of the iceberg as the very first steps to take, not even getting into the system core settings or inner setting of each app which there are dozens, many of which can severely affect performance.

If you guys are just putzing around then cool. However If you are trying to be conclusive in any way you need to put the work in, and show your work.

But Logic came out on top here.

Anyone should assume a proprietary exclusive program for Apple should be at the top or at least near it in its class. Methodology however... I've yet to see anyone post anything remotely valid in that sense. I won't waste my time as I mentioned, but apparently some of you want to so go at it, but do it right if validity matters.

[Dewdman42]

If you don’t like it, post your own results otherwise stop complaining about the facts as they may be.

[Dewdman42]

I would like to see S1 and reaper and dp added to the test, going until crackles. Also would like to see how low each can go in latency before crack up at various project sizes. A truly thorough test would basically be a chart for each daw on one machine that has different track counts and different buffer sizes with cpu usage for each node on that grid and a note about when drop outs start happening. It would be easy enough to see patterns and draw conclusions

However the problem with the max out stress test approach is that there are different ways to max out the cpu, some of which are hardware bound rather then daw bound. Or various plugins could cause it too. So that adds another set of variables.

Also most people don’t actually need 180 tracks. So how and when it actually maxes out is a moot point, unless it happens in a real world situation. But on the same note, high cpu usage also doesn’t matter if nothing drops out. Yet it’s still interesting to know if a daw is a bit more efficient with the cpu somehow then that provides some head room for the future unknown when you decide to try to run some new pluginthst needs more cpu.

As had been stated numerous times any of these daws can work fine and the decision should be based on workflow. Nonetheless the data is interesting

[Psuper]

If you don’t like it, post your own results otherwise stop complaining about the facts as they may be.

I just know its not worth my time -- people believe what they want no matter what expertise and experience is involved, or lack thereof. More importantly, posts like those tend to be personal reasons in the guise of helpful.

The 'facts' so far is the ones I've stated about methodology and how people should expect a proprietary app to perform. All you've done in your last post is regurgitate my initial statements. I stated I won't waste my time (and never would use an Apple or buy pre-made systems), but more importantly others shouldn't buy into piss-poor methodology. But again, for shits go for it, my point has been made you can PM me if you'd like to dispute anything I've stated.

[Dewdman42]

nothing at all wrong with the data that has been provided, nor the methodology used to get it. Its just data.

Why do you suppose Apple's logic pro is able to out-perform Cubase in this case? I mean, we can guess that its Apple so they are using some secret work arounds inside, and coding outside of the CoreAudio framework, but I find that unlikely. And that is pure speculation really.

I think its far more likely that Cubase is coded on top of some Steinberg framework that was originally designed for VST and has been adapted to run on the mac... My presumption would be that Cubase is doing something that does not jive 100% with CoreAudio...or has been built on top of layers of stuff in order to have one codebase that hits both PC/Mac as well as VST and CoreAudio, etc..

[pdxindy]

Thanks for posting your results...

[Coxy]

Anyone should assume a proprietary exclusive program for Apple should be at the top or at least near it in its class. Methodology however... I've yet to see anyone post anything remotely valid in that sense. I won't waste my time as I mentioned, but apparently some of you want to so go at it, but do it right if validity matters.

But again, Logic came out on top here.