I am not here to report an anomaly...

[RexRed]

I am not here to report an anomaly...

Contrarily, I am here to compliment how nicely the last update improves Cakewalk Sonar's performance; both recording and playback and plugin overhead balancing.

A substantial gain in system stability and a prime reason why the subscription is truly worth its weight in gold...

Thank you to the developers, this update hit the nail on the head, further cementing Cakewalk's dominance in the market as the industry standard!

When I scrub my brain I really cannot imagine how Cakewalk could be any better at this point!

Not even an occasional hiccup. Cakewalk is truly a work of mastery and fine tuning of PC assets.

Again, THANK YOU to any and all responsible for this engine update...

You have a very satisfied customer and fan! ⭐

Edited August 23 by RexRed

[Matthew Simon Fletcher]

Well said and thanks for sharing!

[Noel Borthwick]

Thanks for your feedback. The last update is possibly the most important performance update we’ve done in more than 15 years actually. 

The work started with trying to resolve some somewhat unrelated timing discrepancies with VST’s and also to solve some severe problems dealing with huge synth projects. However, as part of profiling the app to find the root cause of these, as a happy accident I discovered a major bottleneck that was preventing the multiprocessing engine from efficiently load balancing. The reason this was not discovered earlier, is that the problem was obfuscated in some completely unrelated transport functionality and it never showed up as a problem earlier. Imagine searching for a needle in a haystack… The net effect was that the engine would be unable to independently process tracks as efficiently as possible. This had a knock on effect to all processing including our plugin load balancing technique. Once this issue was resolved many longstanding issues magically disappeared. We also fine tuned a lot of the VST processing code so now it has the minimum overhead, allowing for much better low latency throughput.

It doesn’t stop there. For the next update we have been working on improving MIDI editing performance, better support for large scale projects, and resolving some longstanding MIDI rendering issues. Already multi-track PRV editing performance has been massively improved. We’re talking hundreds of times faster to perform certain operations!
 

[GIM Productions]

I have always thought since it was called Pro Audio that this is the best pro DAW on the market, which is why I am waiting for the full license as soon as possible because I want to be the owner of such an important tool for my work.👍

[Glenn Stanton]

12 minutes ago, GIM Productions said:

why I am waiting

no need to wait, you can join up at bandlab and start using Sonar today.

[sjoens]

Wondering if-n-how this might affect the longstanding >Sonar hangs in background processes because of some plugin or audio issue and won't reopen< issue.

[Noel Borthwick]

This is raw engine performance optimizations so it won't magically solve bugs in plugins unfortunately 😉

[GIM Productions]

16 hours ago, Glenn Stanton said:

no need to wait, you can join up at bandlab and start using Sonar today.

I know this, but I don't want to depend on anyone, I have always purchased my software, wavelab, kontakt, including all versions from twelve tone onwards and I would like to continue doing so

[Glenn Stanton]

true, but if they only get around to offering the perpetual license in late 2025, when you could switch to it, why wait? and as a subscriber you'll also have the actual weight, as a paid user, to promote the conversation about perpetual licensing to keep the sales and marketing team up at night... 🙂 

[GIM Productions]

18 hours ago, Glenn Stanton said:

true, but if they only get around to offering the perpetual license in late 2025, when you could switch to it, why wait? and as a subscriber you'll also have the actual weight, as a paid user, to promote the conversation about perpetual licensing to keep the sales and marketing team up at night... 🙂 

I'm glad you have precise information on the release of the full license, but until then I'm working on the new releases with CBB which works perfectly

[Mr No Name]

Hello, I was wondering, has the new engine optimisation been added to the Cakewalk DAW? or only the new SONAR?

[noynekker]

53 minutes ago, Mr No Name said:

Hello, I was wondering, has the new engine optimisation been added to the Cakewalk DAW? or only the new SONAR?

My understanding is for any new features, you'll need to buy the BandLab membership, which is new Sonar . . . ($$)

[Matthew Simon Fletcher]

The new engine optimisations are in Sonar.
My understanding is that Cakewalk will only be getting a limited amount of bug fixes and maintenance so that it continues to function rather than any big changes.

Would highly recommend updating to anyone who hasn't or is considering it; it is definitely worth it for the performance boost alone if you're running more than a few instruments

Edited September 3 by Matthew Simon Fletcher

[Terry Kelley]

I have to load CbB beyond rational thought with VSts before it even flinches. If someone notices a difference between CbB and Sonar with a few instruments, something else is amiss. CbB can handle A LOT.

Excluding Arturia Augmented "Anything" ... And no, it doesn't get any better in Sonar. 

Edited September 3 by Terry Kelley

[Starship Krupa]

2 hours ago, Terry Kelley said:

I have to load CbB beyond rational thought with VSts before it even flinches. If someone notices a difference between CbB and Sonar with a few instruments, something else is amiss. CbB can handle A LOT.

Excluding Arturia Augmented "Anything" ...

I've been trying to compare performance between NuSonar and CbB and had to create a project with 20 instances of A|A|S Player (which is a soft synth that used to challenge my systems) in order to force either one of them to drop out on my laptop. My laptop is a  7 year old 2-core i7 with 16G RAM. Forget trying to force it on my main system, which, although in its day was a Concorde, is not exactly bleeding edge.

I'm always amused when people ask about whether this or that system based on a current processor is sufficient to run Sonar or CbB. One of the devs uses an i7 3770 system as the main computer in his studio! I myself only upgraded from my i7 3770 system a year and change ago because parts got so cheap (I got the processor for free from a generous forumite who was upgrading).

It becomes, as you say about Arturia Augmented Whatever, a matter of how efficient the plug-ins are. I've messed about with Thread Scheduling Model and the results seem to point to model 2 being the sweet spot with NuSonar.

Once you load it up enough to be at the edge, it's interesting to add plug-ins to see which ones bring things to a halt. Sometimes having the plug-in's UI open makes a difference, so that's a test for whether the plug-in devs are making use of OpenGL to offload GUI processing to the GPU.

[noynekker]

25 minutes ago, Starship Krupa said:

I've been trying to compare performance between NuSonar and CbB and had to create a project with 20 instances of A|A|S Player (which is a soft synth that used to challenge my systems) in order to force either one of them to drop out on my laptop. My laptop is a  7 year old 2-core i7 with 16G RAM. Forget trying to force it on my main system, which, although in its day was a Concorde, is not exactly bleeding edge.

I'm always amused when people ask about whether this or that system based on a current processor is sufficient to run Sonar or CbB. One of the devs uses an i7 3770 system as the main computer in his studio! I myself only upgraded from my i7 3770 system a year and change ago because parts got so cheap (I got the processor for free from a generous forumite who was upgrading).

It becomes, as you say about Arturia Augmented Whatever, a matter of how efficient the plug-ins are. I've messed about with Thread Scheduling Model and the results seem to point to model 2 being the sweet spot with NuSonar.

Once you load it up enough to be at the edge, it's interesting to add plug-ins to see which ones bring things to a halt. Sometimes having the plug-in's UI open makes a difference, so that's a test for whether the plug-in devs are making use of OpenGL to offload GUI processing to the GPU.

Lol, you make it sound like a contest, a drag race . . . let's see if we can blow it up ! In my humble comparisons  between CbB and NuSonar, the new audio engine optimizations are just marginally better . . . I'll take it . . . especially for my well aged I7-3770 CPU, and wonder if many here just want their iZotope Ozone plugins to keep up with the times, without $$ upgrading CPU's and Cores. When I first read about this new feature of optimization, I kind of thought it was geared towards the newer computer systems, a few tweaks here and there to the startup INI file . . . poof !

I really like the improvement, but for me only a minimal improvement, until I do an upgrade I'm thinking . . .

[Noel Borthwick]

3 hours ago, Terry Kelley said:

I have to load CbB beyond rational thought with VSts before it even flinches. If someone notices a difference between CbB and Sonar with a few instruments, something else is amiss. CbB can handle A LOT.

Excluding Arturia Augmented "Anything" ... And no, it doesn't get any better in Sonar. 

Even with a modest project using virtual instruments at low latency, the performance gains with Sonar are very significant.
Sonar will allow you to run at 64 or even 32 samples with instruments that were impossible in CbB. Of course if all you do is run at 1024 or higher then you aren't going to notice the low latency performance.
Even besides realtime performance we've additionally been focusing on improving speed when performing common editing operations. Those are certainly gains that any user will see on any hardware.

24 minutes ago, noynekker said:

In my humble comparisons  between CbB and NuSonar, the new audio engine optimizations are just marginally better . . . I'll take it . . . especially for my well aged I7-3770 CPU, and wonder if many here just want their iZotope Ozone plugins to keep up with the times, without $$ upgrading CPU's and Cores. When I first read about this new feature of optimization, I kind of thought it was geared towards the newer computer systems, a few tweaks here and there to the startup INI file . . . poof !

I really like the improvement, but for me only a minimal improvement, until I do an upgrade I'm thinking . . .

Its anything but a marginal improvement - depending on the workload you throw at it. Imagine a project with 128 instances of Kontakt - Try doing that with Cbb and run at low latency. Not that most users are going to do that, but the fact that the engine now has the headroom to handle this allows more modest projects to run at far greater stability, especially at low latency. 

[Starship Krupa]

I think a big part of the issue with experiencing these performance gains is that we're all used to staying inside the constraints of whatever hardware we've been using.

Being conservative with the number of plug-ins, freezing tracks, favoring plug-ins that are less resource-hungry, mixing at higher latency, getting used to whatever speed editing operations happen at. We've developed good habits. 😀

Also, just because Sonar's plug-in handling has improved, that doesn't magically make all my iZotope plug-ins leaner. It only means that Sonar itself is more efficient at hosting them. The rest is still up to the plug-in developers.

Edited September 4 by Starship Krupa

[Terry Kelley]

My point isn't about how good Sonar is (it is), it's that if a few instruments bring CbB to its knees, something else is happening that I doubt Sonar itself will correct irrespective of the block sizes. Sonar has some awesome improvements but CbB isn't a slouch by any stretch.

I play with Sonar and has some advantages but I have yet to find one of my overloaded projects that works in Sonar but not in CbB.  When I have to freeze Arturia Augments Everstuff to get CbB to play without glitching, I have to freeze in Sonar too. I'm sure there is some thinly sliced addition or subtraction in VSTs that would make Sonar hang on a bit longer.

Or am I giving the developers that worked on CbB and it's predecessors too much credit.

[Terry Kelley]

3 hours ago, Starship Krupa said:

I've been trying to compare performance between NuSonar and CbB and had to create a project with 20 instances of A|A|S Player (which is a soft synth that used to challenge my systems) in order to force either one of them to drop out on my laptop. My laptop is a  7 year old 2-core i7 with 16G RAM. Forget trying to force it on my main system, which, although in its day was a Concorde, is not exactly bleeding edge.

I'm always amused when people ask about whether this or that system based on a current processor is sufficient to run Sonar or CbB. One of the devs uses an i7 3770 system as the main computer in his studio! I myself only upgraded from my i7 3770 system a year and change ago because parts got so cheap (I got the processor for free from a generous forumite who was upgrading).

It becomes, as you say about Arturia Augmented Whatever, a matter of how efficient the plug-ins are. I've messed about with Thread Scheduling Model and the results seem to point to model 2 being the sweet spot with NuSonar.

Once you load it up enough to be at the edge, it's interesting to add plug-ins to see which ones bring things to a halt. Sometimes having the plug-in's UI open makes a difference, so that's a test for whether the plug-in devs are making use of OpenGL to offload GUI processing to the GPU.

Interesting points. I ran an i7-4790 up until recently (switched to an i7-12700k) and I've been totally impressed with what CbB could handle. I'm sure Sonar would be better but CbB most impressive.

I have a couple of VSTs (inst and effects) beyond Arturia that drag the system down. In several DAWs I've used, none of the performance meters show any obvious high loading. As I built up a project, when it finally does goes south and tweaking the block size doesn't help, I know exactly where to go to fix it. Freeze time or temporarily disable something. Very, very rare though.