Noel Borthwick

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.

Thats great. Thanks!

Sorry but your file is completely corrupted - likely due to HD corruption. Here is a screenshot of the bad file vs good file in a hex editor. You can see that the data is random in the first file. It's not just the header the entire file has garbage data in it.

Thats normal. I disable it when MMCSS is off. It's supposed to tell you that the setting isn't active unless MMCSS is on. When you turn MMCSS off with Enable for ASIO on, we don't clear that state but gray out the box. >>Running great without either checked. I'll leave it alone... One of the mysteries of the universe only UA can reveal/solve.

Yes, the driver is running in MMCSS mode. Did you capture that with "Enable MMCSS for ASIO driver" on or off?

In the range of 3000 bug fixes. Of course, this also includes fixes in the new features.

I suspect 2 is expected behavior and unrelated to workspaces. If you save the project with the multidock expanded and open, it does retain the size and width, correct?

@Helene Kolpakova To clarify you are saying that both the multidock and the browser sizes / collapsed state is not being retained after open, correct? Please deselect a workspace and redo your test. It's possible that the workspace is restoring the view sizes to what they were in the workspace. Remember that Workspaces are a way to set a project to a certain view configuration so if you don't want this behavior, you should select None as the workspace. Note that the Advanced workspace as shown in your screenshots, is authored with the Window Layout settings checked. This means if advanced is selected, it will always restore the window layout to the workspace, overriding what's in the project. You can also make your own custom workspaces without the Window Layout checked if so it wont try and force the layout of the workspace. Additionally, you can turn off Apply Workspace on Project Load from the workspaces menu as below. This should prevent the workspace being auto applied when you open your projects.

Please don't mix multiple issues in a single thread. It gets very confusing for others to follow.

Well, its important to report the version where the problem occurred It was being implied that the latest release introduced the drawing problem when in fact it did not. So the history is that back in July, I changed the startup code to work around a bug in Vienna Ensemble that was wiping out queued windows messages to draw the app. I changed it to not defer the final app redraw and instead do that synchronously. The result of that is that it "opens the stage" so to speak too early now, before some other parts have completed drawing. This makes it look a bit flickery. We now ensure that we handled all queued redraws before showing the final app.

@HOOK Yeah, that's pretty useless I can't tell either. Same issue with Focusrite. If you install the latest 2022.11 early access build, I added a tooltip to the performance module that shows the thread priority. If you run that build let me know what it shows there. Thats the only way to know.

It should work. I just tested it with my Arturia Keylab and plugging in the device while CbB is running works fine. I get a device inserted prompt and when I choose yes, the MIDI device works fine, and I am able to record MIDI. Are you getting the device Inserted prompt and choosing Yes? Sometimes if you unplug and replug multiple times in a session you won't get the prompt because we avoid displaying redundant prompts. If not, you can also CTRL-click the "Reset Audio and MIDI" icon on the toolbar. This will force Cakewalk to reload the driver. If that doesn't work either the issue is with your device.