Noel Borthwick

12 hours ago, winkpain said:

For what it's worth, information-wise, I use Melodyne quite a bit, stand-alone and ARA in CW.

Every project that I've used with Melodyne/ARA in CW has this \Melodyne\Transfers folder in the CW project folder file, and every one of them is empty.  The \Separations folder located in \My Documents\Celemony (or wherever determined from within Melodyne Preferences) is the folder with all the pertinent data in it, it would appear. And this folder can grow quite large.

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.

7 hours ago, bitflipper said:

I got to wondering if you could say that about any file. So I saved your last post and loaded into Adobe Audition as raw audio. It plays, albeit very briefly. Here's what it looks like:

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.

7 hours ago, kc23 said:

Hello

In the release info for 2022.11, in the Bug Fixes section, it says:

-Regression: Mono hardware outputs always output as stereo

Does this mean that, at last, the External Insert plugin has been fixed and it will recognize a mono output without hijacking the whole stereo pair?

Hopefully, it does.

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.

4 hours ago, winkpain said:

So, how/where are we looking in Process Explorer to see this thread priority reading?

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.

4 hours ago, winkpain said:

AND more pertinently for us Focusrite folks, this MMCSS issue (the inability to take advantage of the setting) is a Cakewalk dead-end for now until Focusrite makes the necessary changes. Do I understand that right?

Yes but its pretty much a status quo as before so you aren’t gaining or losing anything.

3 hours ago, Mark Morgon-Shaw said:

Reset Config To Defaults "

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

2 hours ago, winkpain said:

So, does this mean that for those of us with Focusrite interfaces/drivers there is no benefit, for now,  in enabling this new MMCSS setting in CW?

AND as to your comment on using Process Explorer, is this to suggest that setting the priority for Cakewalk there should have an effect within CW? When I do so (for example I choose realtime: 24 within Process Explorer - as shown in attached screenshot), and with MMCSS enabled or not in Settings in CW, the label shown when hovering over the Performance Module does not change/still shows Time Critical (15).

Also,  so much thanks for the continued improvements!

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

15 hours ago, HOOK said:

I've used Cakewalk to record only audio for 27 years.  You heard me...lol.  But I've begun learning to use the MIDI features over the last few months.  I've been having this stuck note issue on occasion so I'm glad to see an option to stop it.  But I'm curious to know...is there something that I'm doing to cause these stuck notes, or is it just a nuisance we all have to deal with?

Also...with this option enabled, roughly, how long of a delay are we talking about when stopping playback?

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.

5 hours ago, Billy86 said:

Regarding this: 

The Use MMCSS option in Edit > Preferences > Audio - Playback and Recording now excludes setting MMCSS for ASIO drivers by default. 

If your ASIO driver supports MMCSS by default, no action is needed. If your ASIO driver has an MMCSS option in its control panel, you need to explicitly enable it now to get MMCSS performance from the driver.

If MMCSS isn't supported, you can explicitly select Enable MMCSS for ASIO Driver to get MMCSS performance from the driver.

To check if the driver is running in MMCSS mode, hover over the performance toolbar and it should show the Audio Thread Priority as "Realtime". If it shows "Time Critical" or something else, try enabling MMCSS for the driver.

My performance tool bar read "Time Critical" when I hovered over it.  So I followed the above steps, and it still says "Time Critical." Do I need to change something else? I'm using a Focusrite 4i4 Gen 3. The Focusrite Control software doesn't mention anything about MMCSS . Not sure if the 4i4 supports MMCSS? I've reached out to Focusrite to find out.

Thanks. 

 

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.

33 minutes ago, Olaf said:

I've seen that you've made the full installer available, so that everybody can use it, which is great. Downloaded it, installed, replaced my 3 piece puzzle installer to the latest version I've had before. Usually I look for the full installer on other sites that provide it, but it was hard to find lately, and I also suspect having it done in one piece should be more reliable, so that's all great.

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.

4 hours ago, Light Grenade said:

Great update, love all of the new features. 

Since updating, some plugins are intermittently opening as a blank white screen. If I open one of the offending plugins when a mix is playing back, it can lock up the project and it instantly closes with no error message. 

Offending plugins, I can tell are

• Sonnox Drum Gate
• Oeksound Soothe
• Izotope Neoverb 
• Soundtheory Gulfoss 
• Softube American Class A
• Native Instruments Replika 

I have tested the same plugins in Reaper, and I don't get the same problem. I have also updated all of my drivers and W10 is on the current build. This is intermittent, and only seems to happen when a project gets heavier. 

I'm also getting an intermittent error message during auto-saving which says 'Cannot find or open file' 

And two intermittent error messages when trying to export 

• When trying to export and MP3 - ''An unknown error occurred during processing, possibly caused by an invalid parameter''
• When trying to export a WAV - ''Catastrophic failure'' 

These issues might not be related to this build exactly, but they have only cropped up since updating. I am using no new plugins.

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.