Noel Borthwick

@IgoRr I've sent you a PM with some builds from last week to try and find if any one changed the performance. Test and reply to the PM.

To clarify the hang change tweak did not solve the problem with the full export dialog, right?

Thanks for sharing your feedback and sending us dump files. Glad its working for you now.

@minminmusic just to rule something out can you disable the hang detection in Sonar and see if that changes anything? To do that add the variable HungAppTimeoutSec to cakewalk.ini like this and set it to 0. Then restart the app and try again. This should disable Sonar's hang detection. Perhaps your export startup takes a long time...

Thats why I asked if hes picking export Advanced.

And to clarify when you choose it from the control bar you are picking the Export Advanced option to open the dialog? This seems very random why it would make any difference since both are executing the identical command on the UI thread but just from different locations. I'm almost certain that this is some bizarre thread timing issue that is affecting one of the plugins that has a vulnerability in its thread safety.

So the only thing that affects it is running the command from the toolbar vs the menu?

Nope that's not it. There is no such things as too many plugins as far as export goes. I've seen projects with 500 or more plugins from some users. It will take as long as it needs to process since there is no deadline unlike playback. That is weird although I've heard about a similar issue where experience behaved differently depending on how it was invoked. I'll look into it. I thought I had asked you to disable flushing plug-in buffers some plugins don't react well to that. Have you tried disabling that yet?

Even real time bounce should be immune from that. Real time bounce runs the transport so it's similar to playback but it's not clocked to the audio device. I.e it's not susceptible to dropping out unlike actual playback. Dropout detection due to starvation direct apply here. If it so happens to take longer to process than realtime it will continue at whatever pace it can.

Talk with support. I believe you can cancel and then choose to resubscribe at the new rate after the current membership expires.

Record a brief video of your actions. Including manually opening the start screen.

The dumps were hangs not crashes

There are zero changes that would have changed anything with the audio engine. The only changes between the prior version and this are whats listed which are mainly crashes and stability fixes. Something else is going on with your system. Load can be affected by background processes or Windows itself. Try rebooting and ensure nothing is running that would consume CPU resources. Run DPC latency checker etc to troubleshoot. Any system or driver changes can impact streaming performance in Windows. You could also validate whether you see the same thing in CbB.

Fast-bounce direct to MP3 is not recommended because the encoding generally can't keep up with the rendering. It shouldn't crash but you can get failures and/or bad audio. Please send me the dump file. Fast bounce should have no bearing on MP3 export. There is nothing that it needs to keep up with, since the MP3 exporter is just using LAME which isn’t asynchronous. It can be run as fast as it can encode - it is self throttling as a result.

Ensure that Windows isn’t additionally using the same audio device while Sonar is using it. With some drivers it can cause problems irrespective of whether its ASIO or WASAPI. Focusrite is one example. i.e don’t use the browser to play audio or Youtube etc.

I'm glad you were able to root cause it through a process of elimination. In a project that huge that's the only way. It's difficult for me to answer why this might be ok in cbb and not sonar definitively. Due to sonars optimizations it processes audio much faster. If the MDN tape plug-in has a latent thread safety problem, then it's far more likely to be exposed in sonar for this reason. You are simply getting lucky in cbb with the timing because it's slower. Changing the bussing structure can change order of processing and may or may not impact the processing. If you can build a small project that repros the hang send it to me and I can try see if I can diagnose further.

This could very well be a problem with the driver that manifests after long term use. Try leaving Sonar looping and playing for several hours and see if this manifests.

There is no change in behavior in Sonar in this regard. Make a different thread for this. Is it only context menus that are interrupted? Which specific menus in particular?

That plugin doesn't properly follow the VST3 spec for exposing plugin sidechains. We'll look into whether we can do a workaround for such plugins.

No it definitely does not. Once you are signed in it stays signed in until you sign out or the sign in token expires.

The full feature list is huge. The website will be updated soon but you don't see huge feature lists there typically. You can read more here or in the online help.

You can simply solo the tracks in question and publish as a new BandLab song for each. You can use the same master project to do the exports and it should work fine. If you are just exporting a stereo mix to bandlab then only check "Project Mixdown" in the publish to bandlab dialog.

There is now a new 2025.08 release. Please continue any further feedback relevant to the new release in the corresponding thread.

Holy crap thats a lot of plugins. The dump shows a hang that is most likely being caused by one or more of the plugins. Do you have UAD2 (hardware) plugins also in this project? I would definitely disable plugin load balancing and retest. Plugin load balancing requires well behaved plugins since it will parallelize processing at the plugin level. So if there is even a remote chance of the plugin poor thread safety it will show up. This is a partial list of the plugins involved in the dump. I got tired of scrolling through... c:\program files\common files\VST3\Nuro Audio\Xrider.vst3\Contents\x86_64-win\ Xvox Pro.vst3 Cradle The God Particle.vst3 Supernova.vst3 P821 MDN Tape.vst3 soothe2_x64.vst3 THR VoxGuru.vst3 Tape MELLO-FI.vst3 Filterstep_64.vst3 VSX.vst3 StereoLab.vst3 MoonEcho.vst3 uaudio_sound_city_studios.x64.dll uaudio_topline_vocal_suite.x64.dll uaudio_ua_1176_rev_a.x64.dll LIMITER.vst3

Something appears to be causing it to hang if you are seeing that message. Capture a dump and send it.