Noel Borthwick

You need to do that from an admin command prompt

Can you send me the project as well as a dump file of the crash?

Definitely not seeing this here. In fact I was testing a bunch of stuff completely offline today. Sonar launches in about 2 seconds here. If you can repro this please PM me a dump of the process while it is hung in that state and I can take a look.

I get some users want "eye candy" and its a personal preference. OTOH, its actually more fatiguing to stare at a photorealistic screen for some people for many hours in a day because there is too much detail.

There is a fine line between expressing personal opinion / usability feedback respectfully and throwing generalizations around which is why some threads are getting locked. We all know that some users dislike a flat look. Literally any change to UI is going to be divisive. We went through the same thing when the UI was changed in X1. It's been explained innumerable times that this decision was made to make the UI scalable on high resolution displays to handle modern high DPI displays. The approach of using bitmaps which is the only feasible way to handle 3d like imagery, like in past versions of Sonar is gone. And before you ask, there are no plans to have both images and vectors - its simply not feasible to do. That said there are some legit complaints about improving things for users with vision impairments or special contrast requirements and in time we'll do it. There are also plans to add better color customization that should alleviate most of the concerns about contrast etc. FWIW. As a counterpoint, I wear glasses and I stare at the Sonar screen for 8-10 hours a day as part of my work. I find Sonar infinitely easier on my eyes than Cbb where I'm always trying to focus past all the graphics clamoring for attention. If anything, that causes more eyestrain for me. I use the dark gray theme fwiw. Many if not most users have adjusted to the new theming, some quicker than others.

Looks like you have the file association set up to launch CBB instead of Sonar. There was no change in the build itself.

This is incorrect. Sonar uses significantly less CPU for most projects. This is at the heart of most of the optimizatons done.

@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.

@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.

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.

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.

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.