[CLOSED] Cakewalk 2022.11 Update 1 Early Access [Updated to Build 21]

[Morten Saether]

We're pleased to announce Early Access for Update 1 of 2022.11! This release includes a small handful of user reported stability issues.

If you have encountered any of these issues, please check out this release and and confirm that your issue is resolved before we release the official public version. 

Please note that Early Access installers are update installers, which only update from a specific version. To install the 2022.11 Update 1 Early Access build, you must be on the latest public release of 2022.09 or later. 

Download Cakewalk 2022.11 Update 1 EA installer

If you haven't already done so, please read about the Early Access Program before participating.

Please keep responses specific to problems or comments on this release. Unrelated bugs or feature requests should be posted in other threads or the feature request channel.

Thanks again for your participation!
The Bakers

 

New for Build 28.11.0.021

• Delete All now available in effect bin menus
• Additional support for quick grouping in FX Chains

Issues Resolved in Build 28.11.0.021:

• Crash when quick group bypassing FX Chains when other effects are in the bin
• Quick group support for track effect bin Delete command
• Don't require SHIFT for quick-group recursing FX Chains, if you're invoking from an effect already within ProChannel FX Chain
• Quick group delete (CTRL+SHIFT) FX Chains across multiple tracks fails to remove the plugin instance in the other track FX chains
• Quick group replace/delete (CTRL+SHIFT) effect from track effects bin should also affect ProChannel FX chain
• Improved project load performance
• Show Clip Stretch amount to 2 decimal places
• Incorrect plugin menu behavior
• Quick Group insert FX into ProChannel FX Rack inserts into track bin instead
• App startup can be slow when running on local network without internet
• ProChannel can be empty after inserting a new audio track
   

 

[Milton Sica]

4 hours ago, Morten Saether said:

• Improved project load performance
• Show Clip Stretch amount to 2 decimal places

 

Very good and working !

Edited November 23, 2022 by Milton Sica

[Herbert Zio]

Is it possible to include the option to delete all FX Rack plugins at once, instead of deleting one by one from the track?

[Noel Borthwick]

1 hour ago, Milton Sica said:

Very good and working !

Are you seeing a change in speed loading your projects?

[Milton Sica]

9 hours ago, Noel Borthwick said:

Are you seeing a change in speed loading your projects?

I ran tests by opening about 20 projects. All took on average more than 1 minute to open.
Always run the application as Administrator
When opening the application, you can already see better performance, making the START SCREEN screen available much faster. This did not happen in the previous version.
What I can report is that projects that took 1.30 m/1.40 m to open now open in 30/35 s.
I don't know if this was expected.
I don't know what operations are carried out to close a Project, but I think that maybe it also deserves to be observed if there isn't something better in the routines, because I observe that for many seconds the application appears as NOT RESPONDING.
Maybe it was possible to put in the Performance Module or another screen the effective opening time of the project. Suggestion.

Edited November 24, 2022 by Milton Sica

[Lord Tim]

11 hours ago, Herbert Zio said:

Is it possible to include the option to delete all FX Rack plugins at once, instead of deleting one by one from the track?

We should be keeping this thread for questions/issues specific to this release, but I do tend to agree here - it'd be great to get a Delete All item added to this menu:

[Xoo]

1 hour ago, Milton Sica said:

Always run the application as Administrator

Not a great idea and it can cause unexpected problems.

[Noel Borthwick]

3 hours ago, Milton Sica said:

What I can report is that projects that took 1.30 m/1.40 m to open now open in 30/35 s

That's good. Do you have an lot of open plug-in windows in your projects?

Most likely some plugins are doing excessive message activity when their UI is opened the first time, resulting in slowing down the project open. If you close the plug-in UI before saving the project is it still slow to open?

We initially were waiting for all UI activity to finish before showing the project to prevent flicker. Now we only wait for our drawing to complete. 

Is the load time better than prior releases as well or the same as it was in 2022.09 now?

[Noel Borthwick]

2 hours ago, Milton Sica said:

don't know what operations are carried out to close a Project, but I think that maybe it also deserves to be observed if there isn't something better in the routines, because I observe that for many seconds the application appears as NOT RESPONDING

Not responding is shown when the user interface is busy for a long time. Again this is most likely mainly due to plug-ins talking a long time on destruction. See if manually closing plug-in UI before closing the project makes a difference. Are you using 32 but plugins? This will also slow down further in this case because of bitbridge overhead.

[Keni]

OK... I'm sure to be told this has nothing to do with this update, but I do this task constantly and yesterday it was "normal" not after the update.

After a render of a Melodyne clip, the clip's name becomes empty instead of the original clip's name (with Melodyne affixed to the front.)

Now mind you, I might actually prefer this as I'm constantly manually removing Melodyne form the clip's name afterwards, this is near the same but I have to remember the original name as it becomes empty after the render...

I'm only running Melodyne 4 Studio (5 will not load on this OS which I'm trapped with)

[David Baay]

I don’t have access to my DAW to verify but I thought bouncing/rendering a new file always resulted in the clip name being dropped, regardless of what FX are being rendered.

[Milton Sica]

6 hours ago, Kevin Perry said:

Not a great idea and it can cause unexpected problems.

I would like approaches from friends who don't see running the application as administrator is not a good idea.

Do you think you don't need this priority?

I would love to learn about this.

[Milton Sica]

5 hours ago, Noel Borthwick said:

That's good. Do you have an lot of open plug-in windows in your projects?

Most likely some plugins are doing excessive message activity when their UI is opened the first time, resulting in slowing down the project open. If you close the plug-in UI before saving the project is it still slow to open?

We initially were waiting for all UI activity to finish before showing the project to prevent flicker. Now we only wait for our drawing to complete. 

Is the load time better than prior releases as well or the same as it was in 2022.09 now?

I don't have any plugin windows open. All are closed.
In my perception, there was an increase in the availability of the UI.

[Milton Sica]

5 hours ago, Noel Borthwick said:

Not responding is shown when the user interface is busy for a long time. Again this is most likely mainly due to plug-ins talking a long time on destruction. See if manually closing plug-in UI before closing the project makes a difference. Are you using 32 but plugins? This will also slow down further in this case because of bitbridge overhead.

I don't have any plugin windows open. All are closed.
I do indeed have some 32 plugins inserted into the project. Plugins I don't have version 64 to use.

[Milton Sica]

6 hours ago, Kevin Perry said:

Not a great idea and it can cause unexpected problems.

Microsoft support reports this: "The difference between running a program as Administrator or local, is precisely the level at which this program can access your machine. Generally, programs that use this resource are programs that need to change or create records on your computer . The location does not grant these permissions to the application."

What do you base your opinion on?

 

"unexpected problems:"

If you could list some or even make a comparison between one mode and another. Would be great.
I really want to learn about this.

Edited November 24, 2022 by Milton Sica

[msmcleod]

37 minutes ago, Milton Sica said:

Microsoft support reports this: "The difference between running a program as Administrator or local, is precisely the level at which this program can access your machine. Generally, programs that use this resource are programs that need to change or create records on your computer . The location does not grant these permissions to the application."

What do you base your opinion on?

 

"unexpected problems:"

If you could list some or even make a comparison between one mode and another. Would be great.
I really want to learn about this.

The main issue with running as Administrator, is that you lose the ability to drag/drop between applications or Windows explorer (unless of course that application is also running as administrator).

It can be very convenient to select / drag drop clips to a folder in Windows Explorer rather than having to go through the export dialog.

Other issues are largely plugin-dependent - e.g. some plugins use the user's documents folder to store plugin or preset information. Depending on how you are running as administrator (i.e. the administrator user vs just elevated administrator privileges), these may not be found by the plugin.

The final reason is security.  Plugins, by design, run in the same process space as the host DAW, so they have complete access to ALL of the DAW's memory (and other plugin's memory too).  Giving the host application admin privileges also gives those plugins the same admin privileges.  If a plugin was infected with a virus, or even written with malicious code it would bypass any protection UAC gives you.

The only reason I've ever needed to run as Administrator is with older DirectX or 32 bit plugins, and that was only ever needed for the very first time I ran them.

[Milton Sica]

4 minutes ago, msmcleod said:

The main issue with running as Administrator, is that you lose the ability to drag/drop between applications or Windows explorer (unless of course that application is also running as administrator).

It can be very convenient to select / drag drop clips to a folder in Windows Explorer rather than having to go through the export dialog.

Other issues are largely plugin-dependent - e.g. some plugins use the user's documents folder to store plugin or preset information. Depending on how you are running as administrator (i.e. the administrator user vs just elevated administrator privileges), these may not be found by the plugin.

The final reason is security.  Plugins, by design, run in the same process space as the host DAW, so they have complete access to ALL of the DAW's memory (and other plugin's memory too).  Giving the host application admin privileges also gives those plugins the same admin privileges.  If a plugin was infected with a virus, or even written with malicious code it would bypass any protection UAC gives you.

The only reason I've ever needed to run as Administrator is with older DirectX or 32 bit plugins, and that was only ever needed for the very first time I ran them.

There are already some reasons. I would like to go into more depth with regard to the issue of application performance, as I always thought that, running as an Administrator, the application would have powers over the machine that could avoid unnecessary crashes, among other things.

What do you think ?

[Keni]

3 hours ago, David Baay said:

I don’t have access to my DAW to verify but I thought bouncing/rendering a new file always resulted in the clip name being dropped, regardless of what FX are being rendered.

Not in my experience or memory.. the most current was to insert/append the name Melodyne to the front of the current clip name.

Not sure if it behaves differently, but not bounced. I use the render command in the Region fx Melodyne menu tree.

Weird... I’ve always wanted to disable the renaming addition in this scenario, but losing the clip's original name is inconvenient for sure.

[Xoo]

14 hours ago, Milton Sica said:

There are already some reasons. I would like to go into more depth with regard to the issue of application performance, as I always thought that, running as an Administrator, the application would have powers over the machine that could avoid unnecessary crashes, among other things.

There are a few cases where this can help (eg. Pentagon I, old Cakewalk plugin, either needs registry permissions tweaked or CbB to be run as admin) but precious few.  Applications should (for the past >10 years) be written to *not* need administrator privileges, so may actually work worse when run like this (not crash, but behave unexpectely - drag and drop, default folder access and so on).  And it would make debugging more confusing as most people wouldn't (shouldn't!) be running as admin.

Use admin via UAC when you absolutely need to, not as a matter of course.

[Milton Sica]

4 hours ago, Kevin Perry said:

There are a few cases where this can help (eg. Pentagon I, old Cakewalk plugin, either needs registry permissions tweaked or CbB to be run as admin) but precious few.  Applications should (for the past >10 years) be written to *not* need administrator privileges, so may actually work worse when run like this (not crash, but behave unexpectely - drag and drop, default folder access and so on).  And it would make debugging more confusing as most people wouldn't (shouldn't!) be running as admin.

Use admin via UAC when you absolutely need to, not as a matter of course.

Thanks.
I'm going to use it for a few days without administrator exclusivity and observe behaviors. Thanks.