Noel Borthwick

1 hour ago, Eric Swardt said:

Followed each step. Where do I find the dump file?

Did you actually get a crash dialog which shows the dump file location? If not it was not detected as a crash.

I didn't supply the instructions to clean uninstall the app  I doubt that was required to solve this issue.
But yes there should be a caveat that doing that will remove any plugins installed to the VstPlugins folder.

I think there is an actual bug here however. If I move the mouse over the left of a track and scroll, and then immediately move the the effects bin it scrolls the view properly. However if I wait a couple of seconds with the mouse over the effects bin it wont scroll anymore. Will look into it and see. why that happens.
Edit: its actually not a bug. in CbB we support scrolling the FX rack unlike Platinum. So its attempting to scroll the rack instead of the tracks view. You can verify by adding plugins to the rack. We'll see if its feasible to improve the behavior in the future.

Have you tried starting Cakewalk without your audio interface plugged in? PS please change the title of your post since we have isolated that it is unrelated to 2022.02

Also, another couple of things to try:

Start cakewalk and repersonalize by holding down CTRL when clicking the Cakewalk icon. Respond to the prompt and allow it to re-personalize. Check if this resolves the issue.

If that doesn't work add the line below under the WinCake section in Cakewalk.ini that is found under %appdata%\Cakewalk\Cakewalk Core. Then try starting the app. If it crashes send us the dump file.

[WinCake]
ExceptionHandlingSeverity=7
 

If you look in task manager do you see a cakewalk.exe process after the splash screen disappears?
Usually issues like this mean something is causing the main process to terminate. Try and backtrack to any changes you might have made earlier since you mentioned that it was working earlier.

You can easily verify if it's specific by rolling back to the prior release and retesting. If it's a problem that appeared days after updating chances are it's unrelated.

26 minutes ago, Eric Swardt said:

A new problem suddenly popped up. Cakewalk fails to start. When I click on the Cakewalk icon on my desktop the splash screen will appear for about 1 second and then disappears, after which nothing happens.

This thread is for feedback specifically about the 02 release. If you have a general issue and need assistance post it on a different thread.

5 hours ago, Tim Elmore said:

I am running CbB 2022.02 in Windows 10 (Version 10.0.19044.1586). Here is what I am experiencing:

1. Vertical scroll always works while over the clips pane.

2. Vertical scroll always works when the mouse is to the left of the clips pane, but not over the FX bin.

3. If I do a vertical scroll to the left of the clips pane, but outside the FX bin, and then try a vertical scroll over the FX bin within one second, it works. It continues to work if I wait less than one second between vertical scrolls.

4. Vertical scroll never works while over the FX bin if it has been at least one second since since doing a vertical scroll.

It's funny that this reminds me of the one second delay that was put into CbB a while back (never in Sonar versions): After scrolling, if within one second you move the wheel again while over a control, it will scroll instead of adjusting the control. If you wait longer than one second after scrolling, moving the wheel will adjust the control instead of scrolling. This safety delay is intended to minimize the chances of inadvertently adjusting a control when trying to scroll instead. Maybe for scrolling purposes, CbB confuses the FX bin as a control 🙂. I know it sounds weird, but there seems to be a connection.

Right as you guessed we have a timer to prevent inadvertently changing control values. People complained about accidentally changing values while meaning to scroll so this delay was added to alleviate such issues. 
I don’t remember if scroll wheel works on the effects rack but it it is treated no differently from other track or mixer controls.

The error message you list is not ours but from the Microsoft installer from the redist itself.
This link seems to indicate that your windows installers may need repair.
https://thegeekpage.com/the-feature-you-are-trying-to-use-in-on-a-network-resource-that-is-unavailable-in-windows-10-fix/

Also read this. https://answers.microsoft.com/en-us/protect/forum/all/the-feature-you-are-trying-to-use-is-in-a-network/80d4be22-aab6-47f0-a7dc-8a3131fc8df0?page=2

It seems that a registry entry on your pc may be pointing to a non existent drive which may be confusing the Microsoft installer. Check the path that it lists in the error message and follow those links.

@Twaddle  did you follow this procedure and still have no success?

BTW your post isn't about running Cakewalk. It's that you can't run the installer...

17 hours ago, Olaf said:

Thanks for the tip.

It's strange that that "none" option existed in the sends - there's no such bus in the project, to be routed to no hardware output. And all buses are routed to the Master. Maybe the send to "none" option should not be available in the send menu - as it doesn't seem to do anything. If you want to keep a send, but disabled, you can just turn it off. If you don't need it at all you can delete it. So it seems all possibilities are already covered.

Sends are treated similarly to outputs. So if a bus is deleted, any sends to it are assigned to “none” rather than being deleted. Its probably there to allow the user to reassign it later otherwise you would lose settings and send automation. Also to facilitate undoable bus deletion so multiple reasons.

Well, its a plugin crash what help do you need?  You posted the text file not the dump file.

3 hours ago, sjoens said:

Hey Keni, he's asking about ProChannel which the FX button has no control over.

The global FX button also bypasses prochannel fx.

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.

7 hours ago, LittleStudios said:

Thanks, Noel!  Another question, as a test, last night I increased my buffer size to see if that would help.  Could this issue also be caused by using a buffer size that was too small for my system and my current project?

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.

4 hours ago, Olaf said:

That's exactly what it was. I removed it last night, and now the problem's gone away.

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.

On 3/13/2022 at 7:51 AM, Starship Krupa said:

Did they? I was unaware of that.

Completely different? I never used SONAR X3, but my understanding is that Cakewalk by BandLab was originally based on the SONAR X series code. Of course, I was never aware of anything called "CbB Sonar Platinum," is that something that BandLab did before the Cakewalk by BandLab that was based on the SONAR code and has been under active development for 4 years came out?

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.

21 hours ago, Olaf said:

After installing Update 1, I've had the following problem. An audio track that is routed to the Master is detected as assigned to an unused hardware output, on project load. Of course the track is not silent, and it plays alright, because it's not routed to any hardware output, but that's how it's recognized.

And I've started having audio dropouts - I believe the code is 19.

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.

On 3/13/2022 at 11:08 AM, David Baay said:

@Noel Borthwick Maybe a prompt is needed when removing the last send/receive end of a patchpoint, asking the user if the patchpoint should be removed, similar to removal of a synth prompting to remove related tracks. I recently discovered I had a "send to nowhere" from the Metronome bus because I had deleted the click track it was feeding and forgot about the patchpoint.

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.

58 minutes ago, Sean MacGillivray said:

Noel, this was actually super helpful for me in working around a different issue! I was super excited to get Task Queues for exporting bounces, as I have an entire record in one session file and so being able to set up a variety of time ranges + export settings is really ideal.

I was finding that certain songs would write a small placeholder file at the beginning of the task, and would appear to export the audio, but then would never write the final file. The issue was reproducible to an extent but would occasionally not happen when I exported those tracks subsequent times.

After reading your comments about null busses, I remembered that I have four additional channels which are not assigned to any output bus because they're just holding lanes for editing purposes. The four songs which exhibited the issue consistently were the ones which had wave data in these channels.

Cakewalk complains about these channels every time I open the session - I can't say I wasn't warned! - but until I started using the Task Queue it had never been a problem to leave their outputs assigned to nothing.  I have those channels muted anyway so I just assigned them to the main buss and it totally resolved the export issue; all the files are being reliably written every time now. Thanks for your insight, Noel!

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.

52 minutes ago, gmp said:

I tried it with the update, and it still stops at 4:17

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

7 hours ago, gmp said:

Let me know if you still need a test project

Yes. From the help:
 

12  [Internal] Internal audio buffer memory limit overflow.     Contact support with recipe/project file.