Noel Borthwick

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.

I think there is some confusion about this. When using Melodyne in ARA mode the Melodyne Transfer folder is not used because the audio comes from Cakewalk's project audio folder directly. All assets are managed by the DAW. If you do not use ARA mode and capture audio in Melodyne then it will create a "Transfers" folder beneath our Audio folder. Cakewalk gives the plugin access to the project folder for this correctly. I've no idea what the separations folder is used for but it is not per region data managed by the app. Its specific to Melodyne and not handled by the DAW. I suggest talking to Celemony about how to manage the data in that folder.

Try deleting the target project on bandlab before uploading, or upload to a new project.

We do pass the project file location via the vst3 api and also another API. I'll have to check but Cakewalk itself doesn't create the melodyne sub folder. There must be some interop confusion. I can check with them..

This would be a question for Celemony support. We don’t manage where Melodyne stores transfers.

Not in the near future...

What are you doing in Cakewalk when it crashes? As tim suggested send a crash dump and we can take a look.

The audio will be nonsensical to listen to. Basically the bundle stores wave files of the same bit depth back to back in different chunks. Most wav file importers will grab just the first chunk and ignore the rest.

Its because a CWB file is a RIFF file starting with a Wave fmt chunk and followed by a custom chunk for the project data. Most likely the google code sees the fmt chunk and assumes its a standard wave file as a result. Not exactly wrong because you can rename a cwb file to .wav and it will play something.. All you need to do after downloading the file is to force the extension back to cwb.

Did you already try turning on the new "All Notes Off" option? If you have a reproducible case send a project and we can take a look.

Mix recall doesn't save clip data, so no you cannot use mix recall for this. You will have to save a backup of your project.

FWIW as David mentioned we used to do this by default. I changed it because for some errant VSTi's it would lead to delays when we tried to turn off all notes on stopping playback. You should generally not run into stuck notes even with it off, but if you do you can turn it on as an extra safety.

There was an error on the back end so anyone coming from the 06 release may have seen this issue. It's being resolved as we speak. Thanks for reporting it.

Hook you can’t always rely on cause/effect reasoning to indicate the root problem. Many times its coincidental. This is not necessarily your scenario, but whenever we release an update there is flood of reports about somewhat random issues and most end up being environmental or completely unrelated. Often its because users are focusing on the update and notice things they didn’t before. Or installing the update led to some subtle change in the system (disk space/new redist files, etc) that triggered some different behavior.

Nothing to do with this update. I've seen clips not display when the audio driver is not connected.