Noel Borthwick

Its failing to insert the prochannel module itself. I can fix the point of failure but the fact that you claim its new could mean that something mode fundamental changed in at the system level. Let me know if removing all redists and reinstalling Sonar helps. Several users have been reporting problems with other apps corrupting the redists. Go to add/remove programs and search for Redistributable and remove ALL the microsoft Visual C++ redists. Then re-run the latest Sonar installer. Let us know if that resolves the problem. If the issue is indeed the redist then all versions of Sonar should get fixed. Note that something like this can also get caused by something damaging a common dll dependency. If so all related dll's will fail to load leading to random crashes. This is typically an installation problem.

@Archerdrummer good to know - are you noticing improvements in your projects/workflow?

Please post this in the Sonar forum. CbB is not in development anymore other than getting minor maintenance updates. Sonar has a lot of CPU optimizations comparatively. The latest Sonar version we just shipped also has some more CPU core optimizations. Plugin load balancing is greatly improved in Sonar as well. You can send me a PM and we can check if Sonar is using all the cores exposed by the OS. If the OS exposes all cores used by dual processor Sonar will use them. Sonar is in fact unaware that there are actually dual processors in use since the OS abstracts that information. All we see is a count of virtual processors. In your case there would be 72 virtual processors and threads. As long as you have about 72 tracks and buses it will utilize those. If you have less than that, it will only use a subset of those cores. The easiest test is to make a project with 72 tracks with the same load on each and you should see typically all cores being loaded. (turn off plugin load balancing for simplicity since that will try and use more threads)

It might help if you posted the link to the article lol. I also have no idea what Sonar 4 is 🤯 Looks like someone went back to 2004!

Its not about resistance! You realize that customization is not some magical thing you just think of and it happens? 😅 Its pretty complex to implement something that works for all themes. It takes design, engineering work and testing. It will come at some point but its not the highest priority thing we have at this time.

@Lynn Wilson I sent you a PM please reply there.

Is it ok now?

Its definitely fixed. His project opens now without crashing.

Can you send the dump file as well as the specific order you are trying to load? This is going to be data specific so we need to get a repro.

The contrast has been tweaked in the latest 2024.11 release which is now available. It's a subtle change but it more visible now even in dark themes.

The plugin browser is where you should be searching. Menus are not designed to be searchable.

Yes this is indeed a Sonar bug but related to persistence. It will be fixed in the next update.

I have verified that the user project crashes after it loads. As described if I load it in safe mode (without ignoring anything) and then save it it loads and plays with no problems. This seems to indicate that there is some persistence related problem with the old file (coming from CbB) and when you re-save the project it self-repairs. Now that I have a repro case I'll look into it and see if I can fix whatever is causing the problem at load time itself. In any case the project should work fine after resaving in Sonar so you should be unblocked. This is one of the main reasons we have safe mode.

Regarding the crash please send the dump file that should have been created, so we can identify if it was indeed a plugin crash or not. You can find the dump file in %AppData%\Cakewalk\Sonar\Minidumps or %AppData%\Cakewalk\Cakewalk Core\Minidumps\Plugins Look at the timestamp to find the actual file corresponding to the crash. It doesnt mean a lot that it didn’t crash in CbB, since there could be myriads of reasons why a plugin may crash in one scenario and not another. If it is indeed a plugin crash we have no super powers to solve it but we can take a look. Please also read this article and this one for more information about plugin crashes.

Fixed it. The MIDI export code was stopping the engine as a side effect of its processing but never resuming it when done.

Yes, I see the same. The interruption is normal while it bounces audio but then it resumes normally for me. I however did have one instance where it was not resuming so perhaps there is some corner case where this happens. Perhaps its dropping out.

Turn that option off.

Its vastly more stable with many hundreds of bug fixes and performance optimizations that CbB doesnt have.

Do you have Sonar set to share the audio device with other apps in preferences? If so when the focus changes from the app the audio engine is intentionally stopped. Dragging a clip to desktop is possibly changing the app focus. Turn off that setting and retest. Also - depending on what clip you are dragging from Sonar, the app may need to render the audio. If it does that it has to interrupt the audio engine (similar to export audio). However we should be restarting the engine after that - if not its an oversight.

Lots of deep infrastructure changes for next release so it's taking longer to complete. If all goes well it should be out next week

A lot of the performance gains come from optimizations for repeated operations that were consuming unnecessary CPU at low latency. Your system has only 4 physical cores so while you will see gains they won't necessarily be that dramatic as they are with lots of cores. The reason is that your system is gated by 8 concurrent processing threads out of which 4 are sharing cores. Your test use also artificial. So practically speaking, with 50 tracks and an equal workload, at best it will process the workload in 1/ 6 the time for each buffer. Whatever gain you see will be proportionate to this ratio as well. In the next update we've shaved off even more cpu cycles, so you will see yet more improvements. some testers reported up to 30 percent gains in their projects.

Please send a dump file as outlined in my post above.

Thanks, I just sent you a PM.

Can you share the project you are using for your test please? ASIO is not more demanding than WASAPI. Its the other way round. Also in WASAPI shared that you were using, you cannot go lower than 10 ms, which is obviously going to use less cpu than 96 samples ASIO. 96 samples in ASIO is 2 msec latency. 10 ms at 48K is 960 samples. In the upcoming build there are is a lot of further work that has been done to optimize the single flow so this same test should be a lot better.