Noel Borthwick

As far as multiprocessing goes buses are tracks are pretty identical so I don't see why you should see a difference if you are testing the same chain of plugins in a bus vs a track. However, you have to be careful to eliminate dependencies on other other tracks routed to the bus. The bus has the additional load of waiting for all its dependencies to be computed before it can mix its inputs. You can also try this test using aux tracks instead of buses and put your plugins there. Behind the scenes as far as mixing goes there is no difference between a track or a bus. They are all mix buses internally.

That implies that you have added a scan path that contains non vst dll's.

MMCSS is always on by default. What changed is that we no longer turn on the ASIO MMCSS flag, because some drivers misbehaved with it. Load balancing is off by default since again some plugins don't do well with it. 64bit mixing has a trade off since it takes some additional bandwidth, so its not enabled by default. Multiprocessing should always be enabled.

@Piper Can you send a crash dump with the plugin that was crashing? We can contact the plugin vendor with the issue since its a plugin bug.

@msmcleod or @jon sasor [cakewalk] may be able to point you to some notes. We have an updated mackie control surface dll that I assume you are using in Cakewalk.

Checked or unchecked? If checking the double precision box did that then it typically means that there is some floating point overflow going on in the signal chain. By switching to double precision there is more headroom so it sidesteppped the issue.

Please forward any recipes to @Jonathan Sasor and we can look into it for next release.

I appreciate that troubleshooting these kinds of issues is very frustrating and laborious. Its an insane number of permutations of things that can cause such problems so unfortunately thats the only way. If you come up with a recipe that we can reproduce we can try and isolate it further and communicate with the developer in more technical terms.

Its not your system. The crash is from the plugin. Only the developer can solve it since it crashes in their code.

The dump file you sent is NOT from the 2022.11 release. In fact its a crash from a 2022.09 build. Are you sure that you are running the latest version, or did you send the wrong dump file? Clearly the same crash occurred in 09.

Re 1. Please try setting BounceFlushTailsMaxDurationSec to 0 in preferences configuration file and see if that prevents the crash. Re 2. Try turning on Send All Notes off on Stop under VST settings

Delete all is new and has a confirmation prompt.

Perhaps post in this section as well. https://discuss.cakewalk.com/index.php?/forum/45-track-project-templates/

You can reset the device and reload the driver's in Cakewalk, by control clicking the reset audio and midi button on the toolbar next to the transport.

Maybe you had a mix of 32 bit and 64 bit plugins with different ID's. It works fine here.

In theory yes. It was likely not implemented for that gesture.

2022.11 Update 1 has been released. Thanks for your help everyone.

Is it reproducible and new to this build? Capture a hang dump file and send a link.

@El Diablo 2022.11 EA build 21 has improvements for app startup on a network when there is no internet. There should be no delay when starting the application now. Shutdown should also be quicker.

Note that the EA has been updated to build 21 (see link in main post). There are several improvements and fixes including improvements for slow startup when there is no active internet connection. We plan to release this build tomorrow so if you can give it a quick look. New for Build 28.11.0.021 Delete All now available in effect bin menus Additional support for quick grouping in FX Chains Issues Resolved in Build 28.11.0.021: Crash when quick group bypassing FX Chains when other effects are in the bin Quick group support for track effect bin Delete command Don't require SHIFT for quick-group recursing FX Chains, if you're invoking from an effect already within ProChannel FX Chain Quick group delete (CTRL+SHIFT) FX Chains across multiple tracks fails to remove the plugin instance in the other track FX chains Quick group replace/delete (CTRL+SHIFT) effect from track effects bin should also affect ProChannel FX chain Improved project load performance Show Clip Stretch amount to 2 decimal places Incorrect plugin menu behavior Quick Group insert FX into ProChannel FX Rack inserts into track bin instead App startup can be slow when running on local network without internet ProChannel can be empty after inserting a new audio track

You said it's a WASAPI wrapper. If it is doing low latency AND sharing, then it's not using WASAPI shared they are using something other than WASAPI.

Well even if they are doing WASAPI they are likely using WASAPI Exclusive mode rather than WASAPI shared. WASAPI shared mode cannot go lower than 10 msec for any USB devices so there isn't anything they could do to enable that. It's at the OS level. We don't flag the FL studio driver. You can check the current list of flagged drivers in %appdata%\Cakewalk\Cakewalk Core\drivercompat.json

MMCSS is just a mechanism to let all realtime threads run at a very high priority so that other tasks on the PC don't interfere with audio processing as far as possible. Have you turned off MMCSS altogether in Cakewalk or just MMCSS for ASIO? If your system has enough bandwidth MMCSS won't help that much.

No, I don't think so. Just watch for anything unusual with load times. Not waiting for the load just meant that the UI could flicker during project load since it would show the UI before all operations had completed.

I've had the RME UFX for a long time and have had no issues with their ASIO drivers. The only thing is the device doesn't work well in WASAPI mode and in ASIO it doesn't support changing latency from the host side - you have to do it via the driver panel. Relatively minor issues.