Noel Borthwick

Yes. buses cannot start processing until all upstream tracks or other buses routed to it have finished processing their effects. Only then can the bus mix its inputs and proceed to processing the bus fx chain. If you have complex dependencies of tracks and other buses sourcing the main bus then those count towards the "engine load" since they are additive. In other words no matter how many cores you have if the work is serial multiprocessing won't help you.

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.

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.

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

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.

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.

Oh I didnt know they added an MMCSS disable in the driver panel, that is good. He had mentioned it, but it wasn't available at the time. It's not that surprising that you get worse performance if you turn off ASIO MMCSS in both CbB AND Lynx while leaving MMCSS enabled in Cakewalk, since that means the audio engine is running at a much high priority than the ASIO driver. The recommended settings are the following: Use MMCSS ON Enable MMCSS for ASIO ON MMCSS in ASIO driver panel OFF Use MMCSS ON Enable MMCSS for ASIO OFF MMCSS in ASIO driver panel ON NOT recommended: Use MMCSS ON Enable MMCSS for ASIO OFF MMCSS in ASIO driver panel OFF

@HOOK Lynx originally had a problem with MMCSS on a Lynx E44, where the driver would stop responding when Cakewalk enabled MMCSS. We had a case open with them and it was solved on their end back in Dec 2019, after I sent them a lot of info on this. Are you running the latest driver from them and if so, what problem do you see when MMCSS is enabled in Cakewalk for ASIO? In any case this is exactly why I added the ability to disable it from the host level and no longer default to MMCSS being enabled for ASIO drivers.

This is why we advise never installing or using these drivers. What they do is hook into Windows and utilize the audio device via low level WDM. Since at startup time Cakewalk loads all drivers to check for availability, when we hit this driver, it causes symtoms like you saw even if you never intended to use it. Sometimes it will even change the sample rate of your audio interface as a result of being loaded. The best solution is to remove these ASIO wrapper drivers from your system so Cakewalk never sees them. One thing I've been wanting to do is to change how Cakewalk starts up to avoid loading all ASIO drivers once one has been selected by the user. This might help alleviate problems like this. Its a pretty big change so will have to wait for when I have time to tackle that.

I wrote an article with guidelines for diagnosing plugin compatibility. Though to an end user it might not seem that way, the vast majority of problems are caused by plugin’s not being fully robust under a variety of operations. The most common problem areas are with following VST3 protocols, loading and saving state, thread safety, and proper separation of user interface operations from actual processing. Bugs in these areas can result in symptoms that vary from user interface problems, audio glitches, problems bouncing, crashes or hangs. We capture crash reports when possible and they sometimes lead to a resolution, but plugin issues are one of the most error prone areas in any DAW. You say you don’t see the same issues in your other DAW’s but that in itself doesnt mean anything beyond possibly the fact that the plugin vendor has not tested the same operations in Cakewalk. All DAW’s are vastly different in their internal architecture and a feature that works perfectly in one may or may not work in the other. We take plugin compatibility issues very seriously and if it indeed ends up being an issue in Cakewalk we fix it promptly. In fact even if it isn’t our issue we do what we can to work around it - much more than what some other DAW’s do.

That message means the plugin was previously flagged as failing. If you have changed things, then change the VST scan preferences to “rescan failed plugins” and try scanning again.

It's probably not windows itself. Same issues on Mac. I don't think the OS knows if there is no Internet without actually attempting a connection. I was hoping it would return a cached state immediately but apparently not.

It so turns out that there is no Windows API to reliably detect no internet when you are going through a network/router. The known API's report a valid connection even when the router actually has no internet! Likely because from the point of view of Windows it is "connected". I actually tested the API's and they report internet connectivity even though its dead. Windows itself actually pings the microsoft servers to check for internet. See this article. https://blog.superuser.com/2011/05/16/windows-7-network-awareness/ So in a nutshell the only way we can prevent this lag while checking, is by doing the check asynchronously. I'll look into this for a future version...

Please attach or PM the crash dump file for analysis. You can also try turning off flushing of plugin buffers in Preferences Configuration file. Some plugins misbehave with that setting.

How long is the timeout? It's probably doing the check for updates and timing out. It's quite fast when there is really no Internet but perhaps when it's on a lan with no Internet it's less efficient. I've now changed the API to check for an internet connection so perhaps it will improve. How do I test your use case - just have a lan connection with no Internet?

Maybe you added it by accident to an FX bin at some time. Or perhaps Melodyne itself creates the folder even though it doesnt need it. People copy projects with Melodyne all the time. I doubt that the separations folder is necessary and is likely used for internal temporary data. You can prove it for yourself by moving a project to a different machine or by temporarily renaming the seperations folder and opening an existing project. I bet the separations will be regenerarated from the existing project data.