Noel Borthwick

We install all redists that are REQUIRED by Cakewalk so using the installer provided should address any Cakewalk related issues.

Not all companies can keep up with the latest versions that is normal. However waves does test with Cakewalk and report issues to us. Changes on incremental releases are very unlikely to affect global compatibility.

Doubtful. It could be a general hang in the system or even a bug. Hard to say without the ability to reproduce it. Is it happening consistently with your project? However smaller buffer sizes can expose certain bugs or race conditions more readily so its a possibility that you may not run into it at a larger buffer size. In any case there is a simple resolution to switch to the default scheduling model.

Great. That error message is primarily for diagnostics in cases where some tracks are inadvertently set to output silence. You can disable it by setting the "WarnSilentBuses" flag to 1 in the Initialization File section in preferences.

Incorrect information. CbB started development from the last version of SONAR Platinum. The first CbB release was in fact identical other than a few bug fixes. There were exactly zero teething problems other than transitioning the activation system and some installer changes to removed bundled 3rd party licensed plugins. There is no comparison to any prior version of SONAR anymore. Cbb is a vastly improved and more stable program with thousands of bug fixes and hundreds of new features since then.

@LittleStudios you are using the "aggressive" thread scheduling model. The error code 19 means "Multiprocessing the audio tasks timed out waiting for completion". This is likely some corner case with your project that is leading to this. "aggressive" mode is not heavily tested so I suggest switching back to the default thread scheduling model. This is completely unrelated to the current update btw.

Check if the track has sends that have been assigned to "none". That can also cause this issue. If you can't find out why send the cwp file and we can take a look.

I've fixed the underlying issue that would leak buffers so it should be no longer a problem. A warning isn't appropriate since the user could be in this state while manually creating patch points and routing them.

That's a different issue. Are you referring to tracks assigned to "none"? Depending on your export settings they may have been getting skipped since they are not audible. The OPs situation was that that he had buses assigned to patch points, but the patch points were not assigned to a track so it was leading to a boundary case.

You should remove references to the dead patch point then. Why keep patchpoints that are no longer in use. You had buses that still output to those patchpoints. These are corner cases that cause issues like this. Edit: @gmp I've identified and fixed the underlying issue that could lead to this dropout happening for next release. It will work ok with patchpoints that are partially connected.

@gmp the issue is caused because you have the first two tracks going to the Vocal Mix bus. However the Vocal Mix bus goes to a patch point Aux S/PDIF which is not assigned to any track input. This is a corner case that leads to the buffer overflow. Why is this patch point being used if its not assigned? I added a new track and assigned its input to Aux S/PDIF and the problem goes away. I'll see if there is a way to catch this case and handle it better.

Yes. From the help: 12 [Internal] Internal audio buffer memory limit overflow. Contact support with recipe/project file.

@SomethingElse Osey What specifically is the problem?

@gmp We'd need a test project to investigate. What is the dropout code reported?

Source category clips in bounce is simply a shortcut to select the clip and export. Since it's going through a stereo bus there will be a gain increase due to the pan law. It's not the same thing as bounce to clip.

We own the licenses to them all. It was intentionally not included in the free set of released plugins when we first released Cbb. It may be released in the future.

Look ahead is not related to processing cost. Rather it is required to allow the processor to look at historical audio ahead of time. That is what causes the delay because the plugin needs to buffer audio in advance before it can start processing it.

The free version will not do MIDI extraction. Celemony no longer allows it.

If you are running the free version of Melodyne 5 or the player, MIDI extraction no longer works. You need to purchase one of the other products.

2022.02 has now been officially released. Thanks everyone for your feedback!

The issue is fixed if you download build 27 linked from the main post.

Please follow up via PM.

That is only a single data point and doesnt prove anything definitively. The cause could be any number of reasons. You haven't answered the question of whether it happens only on a specific project for one. it could be system load related, timing or a million other things that differ from one version to another. Follow normal troubleshooting by isolating the problem if its project specific. If you can narrow it down to a plugin or something else and send us better repro steps then there might be more to follow up on. But for now there is not enough to go on.

That something else would be environmental. As mentioned there is nothing in the code that changes behavior of loop toggling.

Awesome thanks for verifying that.