Noel Borthwick

@Sergei Pilin there is no cookie cutter one size fits all way to handle load balancing because there are too many CPU/Hardware combinations and Windows itself isn’t a realtime OS. Additionally the actual load varies from project to project based on track count, plugin count and the actual load of individual plugins. Also notably there are different types of cores - virtual cores exposed by hyperthreading on Intel systems, and in some more modern hardware there are e-cores and p-cores.

In general reducing the thread count lower than the number of cores, could have a detrimental effect on large projects, which is why by default Sonar exposes one thread per core. We allow you to tweak it to your personal requirements. It may or may not improve performance in all scenarios. There is now also support for management of p-cores and e-cores which you may not be aware of. 
See this help topic.  You can instruct the engine to avoid using e-cores. Some users with such systems reported improved performance, but others did not. As noted above mileage may vary. 

In general Sonar is vastly improved over CbB because I streamlined many core operations that led to suboptimal multi-threading which is why you see better distribution of load in task manager. More importantly low latency performance is drastically improved allowing projects to run at very low latency that would choke the CPU before.

PS: you didn’t mention what CPU are you running on. How many cores does it have and what version of windows are you using. Also have you changed settings in the BIOS or made other system level tweaks that would impact how the cores are used?

He's referring to the project itself routing to multiple hardware outputs. If you export everyone's mic in that scenario you are summing all the outputs which is likely something you did not intend to do. 

For example if you had a headphone output and main out, both with be summed leading to doubling the output.

Not surprising. thats a very old plugin and it was known to have some problems esp with 64 bit processing. Its also possible that the plugin internal state was corrupted in a preset. Changing the preset and editing the settings may resolve the issue.

This is unlikely to be related to updates or installation. One of your plugins is misbehaving. If disabling all plugins from the main toolbar restores audio then its one of the plugins. Also try turning off 64-bit double precision in the audio settings if it's enabled, in case one of the plugins has a problem with it.

This is l likely an incompatibility with your graphics driver and opengl which the lps use. I think there is a way to disable opengl with the plug-in via an ini setting. I don't remember the value right now.

4 hours ago, brundlefly said:

I was going to suggest the same after testing with all 24 (!) OUTs enabled on my main DAW but only one used in the project, and finding the delay is in excess of 2 seconds. It's been a long time since I used more than 2-3 ports on that DAW, and my laptop has only a single OUT so hadn't noticed it.

@Noel Borthwick I'm also wondeirng if it's necessary to send messages to all ports serially, or only per-port - i.e. could the same message be sent simultaneously to all ports or would some drivers still have trouble with that?

It definitely seem like this needs to be defeatable for users who encounter it and have MIDI interfaces that aren't sensitive to high-speed messages.

 

@brundlefly if I remember correctly I made this fix to resolve problems you were having 😂 

And no there is no way to send a single message that's not how the API works.

Anyway I'll move this to a PM so we don't clutter this thread with the details. 

3 hours ago, Matthew Carr said:

After some fun trying out other interfaces, different driver modes and re-installing Sonar on other systems, all with no effect, I went back to changing settings and I think I've found the root cause.

If 'Zero Controllers When Play Stops' is enabled, in the project MIDI section, then the delay occurs.

 

If this option is not checked, there is no delay - the transport returns to start point immediately the stop button is pressed.

If the option is enabled, but there are no Midi tracks in the project, then the delay is not present.

The behaviour can be replicated by creating a new project with the Basic template (1 audio, 1 midi track) - on my system at least.

This is definitely a regression specific to Sonar, as with this option checked in CbB there is no delay.

Hopefully this helps in solving the issue!

 

Its good that you were able to narrow down your delay. This is not a bug.
In Sonar for hardware MIDI ports, we intentionally introduce a 1 msec delay before rapidly sending CC's across all 16 MIDI channels to reset the MIDI hardware. The reason for this is it would found that there are some MIDI drivers that will hang if you rapidly send CC's to them. MIDI is a serial protocol and there is no working around that. If there are many ports it can add up since its 16 channels per port. Overall, its much better to introduce a small delay rather than hang some devices.
If you have a lot of MIDI out devices not being used, consider disabling them in preferences or simply turn off the zero controllers option if its not doing anything specifically useful to you.

Follow the instructions in this link and submit a hang dump.
 

All older Cakewalk plugins are not DPI aware.
Where did you disable display scaling? You can disable it from the cog menu in the plugin window. 
Then delete and reinsert the plugin. 

6 hours ago, Bristol_Jonesey said:

I'm afraid this doesn't fix my issue with LPEQ & LPMB

Both of them open with a completely blank UI

This thread is about the LP-64 a completely different older plugin and the fix has nothing to do with the LPEQ, so make a different thread.
Its likely something specific to your system or Win 10. The older LPEQ and MB work fine here.
Try turning off DPI awareness from the cog for the plugin window and re-insert the plugin and test again. 

We aren’t responsible for crashes in every plugin in the universe you know? The fact that it crashed for you in Sonar vs Cbb is not necessarily significant. Crashes are caused by unexpected behaviors so its entirely possible that a buggy plugin may crash in very specific or even random circumstances or depend on timing of operations.

If you have a repro send a dump and we can tell you if the crash is actually caused by something in Sonar or not. You can report crashes and attach links to dump files from the help menu in Sonar. 

The crash is fixed in the latest Sonar release. Worked around I should say since the actual bug is in the LP-64 not Sonar.

22 hours ago, Amberwolf said:

That's complete data loss, a situation that should never be allowed to happen by the code itself.  I would report this as a data loss bug.  The bakers may disagree, but:

If it could happen in the situation you had there (in a perhaps never-activated install of demo? post isn't clear about that part), it could also happen anytime a reactivation becomes necessary for any reason, including a program fault where it "forgets" it was activated because of whatever issue.

So a user could be working along, doing things normally on what for them has been an already-activated version of Sonar that the've been using for however long without issue, then they go to save, and because it has somehow become inactivated (reason doesn't matter), it has to be reactivated before they can save.   If at that time, the version being run has a required update available*** when activation is attempted, and it wont' activate and thus won't save before updating, all the user's unsaved work is now lost.

**** (are they all required?  Or can you skip them? I don't have direct experience with Sonar's updates, or have it to wait for them to come up and then test)

 

 

Data loss is a really big problem, to me (and presumably to most artists and other computer users).

 

I do everything I can to prevent it, saving often, always saving as new files never over the top of one, etc., using autosave, versioning, everything any program has to make it harder to lose data.   (and copying to external drives that are not connected except during backups, etc).   

But...a situation like the above could, even with frequent saves, still create a dataloss situation, if it came up. 

Completely incorrect information here. There is no way the program will switch from an activated state to a non active state mid session. The OP ignored the warning on opening the app and continued to work and saved much later. I'll add a persistent nag but if the user refuses to read warnings and doesnt save thats not the programs fault.

We'll look into it. Technically MIDI files are not "projects"

Thanks for sending dumps and data required to diagnose this. While most users wont be using such high I/O counts its easy to run into this problem inadvertently with software like VoiceMeeter that have virtual outputs. Sonar now handles upto 1024 I/O’s and if it exceeds that it will handle it gracefully without crashing

Can you try a different audio interface to rule it out? If you dont have anything handy use your onboard audio device.

Are you using any control surfaces?

Yes I meant pause. Both scroll lock and pause have been around for at least 15 years or more.

11 hours ago, gmp said:

I opened a CWP from 2010 since a client wanted me to work on it. In Sonar I couldn't open the synthrack and browser. Cakewalk support verified the bug, which if I had Sonar premium I could have fixed it by putting the Workspace as None. I found another solution, open CbB and save the file with the synthrack open. I'm glad this happened before 8/1/25

@gmpCan you send me the project in question?

On 7/10/2025 at 9:21 AM, Jan said:

P.S. Just noticed - while writing this - that when I came back to Sonar and hit "Play" the window would update only once per second (a slideshow essentially). Not sure what caused it. Maybe related?

You pressed scroll lock. That throttles ui updates

Check your mailbox

4 hours ago, msmcleod said:

From my conversations with Noel about this, unlike MacOS which forces you to use ARM64 plugins if you run as ARM64, and forces you to use x64 plugins if you're running in Rosetta,  ARM64EC will allow you to run a mixture of ARM and x64 plugins. 

What I'm not clear about is whether ARM64EC will run only ARM64EC & x64 plugins,  or ARM64, ARM64EC and x64 plugins.  I suspect its the latter though.

There will be a small performance  hit when running x64 plugins on an ARM machine though, as it'll be emulating the Intel code.

The performance hit is miniscule. In fact in some cases Prysm does an admirable job and it may even result in improved performance since its running ARM instructions not X86. From a battery life POV it will definitely use less energy running the plugin under emulation than an equivalent laptop on X86.

5 hours ago, pedwal wally wally wha said:

Early tests suggest that many x64-based VST3 plugins, including those from major manufacturers like Native Instruments and Waves, can be used on WoA, but iLok-protected plugins might not work, according to Steinberg Support. 

Well yes - ILok installs a driver. If they don't support WoA then the activation is not going to work. Has nothing to do with plugins themselves.
Besides drivers, there is nothing special required for running X64 code on arm for the most part (barring bugs in Microsoft's Prysm emulation layer itself). I found a few issues while porting and reported it to Microsoft.

3 hours ago, pedwal wally wally wha said:

just asked which plugins they tested with, keep yer wig on

We tested with the plugins we ship with and some of the normally used plugins like NI stuff etc. Thats like asking which plugins have you tested that work on Windows 11. Its not our call.

3 hours ago, Wookiee said:

You infer that it is the teams/Cakewalk responsibility to ensure someone else's product works with theirs. Why? There is nothing they can do if they don't, can they? They obviously make best efforts to ensure that their software is compliant with the standards of ASIO, current Direct X, VST 2/3, the current MIDI requirements, the currently supported OS's, the majority of Graphics standards. 

What I personally think you should be doing is asking the plugin creators what plugins work on the ARM architecture, that is the real first question to ask.

Then, and only then, if they say they are ARM compatible, but fail in you chosen host product, do you ask that products creator to resolve the issue. 

You are inaffect asking Cakewalk to ensure that their product runs on all the permutations of potential PC hardware combinations, plus test all third party plugins. When we know full well that Cakewalk, applies the latest SDK libraries to their products, but frequently third party creators don't test their products on all other potential hosts. I know this for a fact because when I have approached a number of third party plugin producers with errors. Their response is "Oh we don't test on xwz hosts." The most interesting thing with those plugins is, the Cakewalk team have identified the issue in the plugins creators code, and supplied them with the fix, whilst building a workaround into Cakewalk's code just incase they don't fix it.

Correct. Its not Cakewalk or any other DAW vendors responsibility to test every plugin in the universe. We test with the big suites and otherwise follow up when there are specific customer compatibility issues that are proven to be DAW specific problems. In any case this mostly doesnt apply to ARM 64 because Microsoft writes the emulation layer. If someone encounters a problem with a plugin not working on ARM, the first contact should be the plugin vendor.