Noel Borthwick

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

@ku7431This is almost certainly the issue then. I'll send you all that you can test which should resolve the problem. Look for a pm from me. Edit: I've sent you a zip with the new file.

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

@ku7431 we actually ran into this after installing an update to the latest version of Visual Studio. We have a fix for it but we assumed that end users would not run into it so we were deferring it to the next release. By any chance do you have Visual Studio 2022 installed?

@ku7431 which OS version are you running and did you update the os recently? Can you describe the problem more? What do you mean by "disables cakewalk and won't launch it again"

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.

No the issue you refer to with external inserts is not a bug. Its a design restriction based on the fact that many driver models use stereo pairs. It will require an architecture change to support individual mono channels there so its not quite that simple.

Go to the properties of the Cakewalk process and then the threads tab. Then assuming that you can find the ASIO thread by name you can see the thread priority in that pane. The Focusrite thread is unfortunately not easy to find since its not named so you may not have success. Hence the performance tooltip in Cakewalk is your best bet. Yes but its pretty much a status quo as before so you aren’t gaining or losing anything.

This saves a backup of aud.ini so you may be able to compare the two and narrow down the change.

@winkpain Right because turning it on in Cbb has no effect because its blocked somehow. Regarding process explorer, I think you misunderstood. In your screenshot you are setting the Process priority not the driver thread priority. That won't change anything with the driver because we don't create the driver thread. Also you shouldn't set the entire process to realtime since that's not a good idea The process has lots of other non realtime threads like the UI. Setting the process to realtime could have a detrimental effect on audio and system performance in general! To clarify, I only suggested to look at the ASIO driver thread priority in process explorer not change it...

@Mark Morgon-Shaw that's strange. To rule out something other than the update, have you already tried rolling back and repeating the steps with the prior update? Also, which version were you running prior to this? Was it 2022.09?

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.

Focusrite doesn't appear to be setting up MMCSS as I would expect it. I see the same on my system with the latest driver on a 6i6. The driver does not run at realtime priority (24 and above) and the driver doesn't allow us to change its priority either (the attempt fails) so there is nothing you can do to increase it. I'll get in touch with them and report it in case they are unaware of this. BTW the labels Time Critical and Realtime are just labels I put there to help with diagnosis. Time critical is the priority that our threads run at WITHOUT MMCSS enabled, which is lower than what they can go to. MMCSS priorities allow the audio engine and driver to run at much higher priorities thereby minimizing other system interference leading to audio glitches. To actually check MMCSS priorities accurately you need to use a specialized tool like Process Explorer. We can't check it easily in the application.

This is a one off full installer we’re providing only for this release. Normally its determined based on what version the user is updating from. If its from the previous version we download a “thin installer” that has only the changes. If coming from an old version it gets the full installer. As explained earlier this is to load balance data downloads and keep data costs down as requested by BandLab. We have a lot of users and not only is it expensive its inefficient (and unnecessary) to have everyone download > 500 MB each time.

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.

There are no changes to 2022.11 we know of that could change this behavior. Which build were you running prior to updating? You can always roll back and test if the problem is new to this release. Also try running the full installer linked here:

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.