[CLOSED] Cakewalk 2021.01 Hotfix Preview [Updated to build 93]

[Darrenpatrick]

I just installed build 88 and now I see there is a build 91. Did I miss something in between?  Ok, now I’m up to build 91. Have to say I’m very impressed with the response of the baker team, way to go guys

Edited January 27, 2021 by Darrenpatrick
Add info

[Noel Borthwick]

Just now, Darrenpatrick said:

I just installed build 88 and now I see there is a build 91. Did I miss something in between 

No just a few hours  We had a few builds today.

[Promidi]

6 hours ago, Noel Borthwick said:

• Increased contrast of PRV clip outlines so they are visible regardless of current theme.

 

Thanks for this.  It makes a huge difference. 

Any chance the intensity can be adjusted (Either in prefs or registry)

[chris.r]

A bug or intended?

1. Here I have set the threshold to 1/8 

2. Watch the shorter note on the left, it's within the 1/8 threshold and longer above not. When I select Section 2 and press delete, the longer note gets truncated to match the shorter note's end time, and not at the Section/selection start... is that intended? On the right side everything seems ok (lower note split at Section end).

3. Now everything behaves yet differently when I engage Ripple edit, as per picture below. Notes from right side are handled correctly. On the left, the long note is now cut at the Section start as expected but the short note is also cut and not left untouched (remember it was within the 1/8 threshold window).

 

[chris.r]

Also some weird stuff going on here when working with keyboard. After I selected Section 2, I click Delete on the keyboard, then I undo, now clicking Delete does nothing. When I switch to another program and then back to Cakewalk, clicking Delete again now deletes according to selection rules and not to the Arranger Track rules (only both highlighted notes on the right are deleted).

[Noel Borthwick]

Build 93 has been posted. Thanks for your support testing this hotfix. In particular, please test ASIO with MMCSS enabled (and disabled) since there are some specific optimizations to the audio engine in this area that should make it more efficient.  You will need to reboot your PC after installing this update to test this properly. 
The following new fixes are in this build.

• Ripple edit delete using section overlaps crops the clip at the end of the left sections 
• MMCSS threads not properly unregistered on engine termination
• MMCSS threads could exceed quota with repeated changes to preferences
• CbB no longer attempts to set ASIO thread priority when MMCSS is not enabled
• Plugin Load balancing threads were not being released
• Remove unexpected dropout message when creating or loading new projects
• Unexpected sample rate conversion message when bouncing audio
• Add Instrument Track not putting audio track in folder / unable to remove from folder

[Will.]

Question:

Don't know why I'm asking this, but - do I have to install these hotfix builds, if I don't have any problems? The only problem I had, was the Ripple All issue. That was solved with Build 88. 

[solarlux]

39 minutes ago, Will_Kaydo said:

Question:

Don't know why I'm asking this, but - do I have to install these hotfix builds, if I don't have any problems? The only problem I had, was the Ripple All issue. That was solved with Build 88. 

Its easy to install and its good to install : )  Updates are very good and easy to install

Edited January 28, 2021 by solarlux

[Promidi]

1 hour ago, Will_Kaydo said:

Question:

Don't know why I'm asking this, but - do I have to install these hotfix builds, if I don't have any problems? The only problem I had, was the Ripple All issue. That was solved with Build 88. 

These are preview hotfixes.  They are released to address specific issues that the Bakers believe are serious enough to warrant their release.

Use the list of fixes in the release notes to help you determine whether to install them or not. 

If you are not affected by anything listed in the hotfix, then you could hold off until the next pubic release.

That being said, I have installed all preview hotfixes to date (I'm now on 2021.1 Build 93) and I have never had an issue with them.
 

[solarlux]

4 minutes ago, Promidi said:

These are preview hotfixes.  They are released to address specific issues that the Bakers believe are serious enough to warrant their release.

Use the list of fixes in the release notes to help you determine whether to install them or not. 

If you are not affected by anything listed in the hotfix, then you could hold off until the next pubic release.

That being said, I have installed all preview hotfixes to date (I'm now on 2021.1 Build 93) and I have never had an issue with them.
 

Yes and i like  it very much if i can install update

[Will.]

5 minutes ago, Promidi said:

These are preview hotfixes.  They are released to address specific issues that the Bakers believe are serious enough to warrant their release.

Use the list of fixes in the release notes to help you determine whether to install them or not. 

If you are not affected by anything listed in the hotfix, then you could hold off until the next pubic release.

That being said, I have installed all preview hotfixes to date (I'm now on 2021.1 Build 93) and I have never had an issue with them.
 

Yeah. Don't fix what isn't broken, right? 

Then again, why not? Can always revert back, should I run into a problem. Plus, it will help the developers. 

[Noel Borthwick]

The idea of posting early access is for users to test them early and report back if there is a regression. So its in your best interest to install it early, considering how easy it is to roll back if necessary. All these changes are going into the final release which will go out shortly.

[solarlux]

Idea is genial and we all here can test and make feedback : ) I like it.

Edited January 28, 2021 by solarlux

[chris.r]

I see now, with the hotfix 93, the changes when deleting an arranger section with ripple edit on. Still got question regarding the note that I've highlighted. Here's my starting point: I have non-destructive editing and split midi notes on, and the overlap threshold set to 1/8 so when I select and delete Section 2 both, the note below on the left, and above on the right are within that window and should be left untouched, and the other two cut at the Section 2 boundaries (right on bar 2 and 3).

But only the right side notes are handled properly, on the left see the highlighted note, shouldn't that one be cut precisely at bar 2?

Actually the same happens without Ripple Edit, see the note on the left, if I get it correctly it should get cut earlier (because it didn't fall within the overlap threshold window), like the note below on the right, no?

Please post some explanation if I'm getting it wrong. Thx

[msmcleod]

22 minutes ago, chris.r said:

I see now, with the hotfix 93, the changes when deleting an arranger section with ripple edit on. Still got question regarding the note that I've highlighted. Here's my starting point: I have non-destructive editing and split midi notes on, and the overlap threshold set to 1/8 so when I select and delete Section 2 both, the note below on the left, and above on the right are within that window and should be left untouched, and the other two cut at the Section 2 boundaries (right on bar 2 and 3).

But only the right side notes are handled properly, on the left see the highlighted note, shouldn't that one be cut precisely at bar 2?

Actually the same happens without Ripple Edit, see the note on the left, if I get it correctly it should get cut earlier (because it didn't fall within the overlap threshold window), like the note below on the right, no?

Please post some explanation if I'm getting it wrong. Thx

For trailing notes:
If none of the notes end within the section end time + overlap threshold, then the notes will be split at the end of the section. However if one or more notes end within the section end time + overlap threshold, then any other notes after the threshold will be cropped at the threshold limit. Clips cannot be slipped on a note by note basis, so it keeps as much of the note duration as it can.

For leading notes:
Leading notes that start before the overlap threshold, but end after the section start + threshold will be cropped at the section start.


It's worth pointing out though, that although the logic does its best to ascertain which sections notes belong to, it cannot possibly get it right every time. There's no way an algorithm can work out the musical intent of your notes.

The larger you make your overlap threshold, the more you should expect to have to tweak the clips afterwards. Personally, I keep my threshold at a tiny amount - i.e. 1/64, 1/128 or 1/256.

We did discuss more verbose methods of associating notes to sections, such as being able to individually assign notes to a section. In this case, it'd probably get it right every time, but it would be an arduous task for the user to pick these notes on a note by note basis.  So we went with a threshold.

[chris.r]

23 minutes ago, msmcleod said:

However if one or more notes end within the section end time + overlap threshold, then any other notes after the threshold will be cropped at the threshold limit. Clips cannot be slipped on a note by note basis, so it keeps as much of the note duration as it can.

Thanks, that explains it, although it's still a non entirely expected behavior, we're talking about a note that *should get cut before the end of clip (*according to what's happening on the other side) so it's perfectly doable.. but it's fine, a matter of taste I would say  

23 minutes ago, msmcleod said:

It's worth pointing out though, that although the logic does its best to ascertain which sections notes belong to, it cannot possibly get it right every time. There's no way an algorithm can work out the musical intent of your notes.

For simplicity, the easiest algorithm to accomplish note association with the right section after editing would be to use the percentage of the note i.e. where the note overlaps for more than 50% of it's length there it should be left belonging (with an unaltered length/starting point)... in my non-programmer's opinion.

23 minutes ago, msmcleod said:

We did discuss more verbose methods of associating notes to sections, such as being able to individually assign notes to a section. In this case, it'd probably get it right every time, but it would be an arduous task for the user to pick these notes on a note by note basis.  So we went with a threshold.

Absolutely! Keep it simple and efficient. ?

Edited January 28, 2021 by chris.r

[chris.r]

27 minutes ago, chris.r said:

For simplicity, the easiest algorithm to accomplish note association with the right section after editing would be to use the percentage of the note i.e. where the note overlaps for more than 50% of it's length there it should be left belonging (with an unaltered length/starting point)... in my non-programmer's opinion.

Or give the user ability to set the percentage for overlapping notes manually. Because otherwise, by using the threshold thing, there will be always, or often enough, some tweaking necessary after moving sections (I'm trying to say that this solution is naturally leading to some note changes). Last thing you'd want is to have the note lengths and start points altered. If they are unaltered then it's much more simple to move the whole notes along if necessary, after edits.

Edited January 28, 2021 by chris.r

[chris.r]

Ok, I checked again with the example that I posted above, and after I deleted Section 2, I then slip-edited the resulting two clips and:

• on the left I could get the cut note's length back by extending the clip end
• on the right I couldn't get the cut (lower) note's position back - this is an unwanted side effect - the note is permanently altered

This is to show that in this example note percentage might work better than overlap thershold as the altered note would simply be moved along with the whole section.

/end of digression (sorry!)

[chris.r]

Back to reality  maybe I have another question, please let me know if I get that wrong.

Here's my starting point:

Here I'm getting expected results when deleting section:

But when I do 'Cut' and 'Paste' the threshold rules do not apply:

and when dragging the section with mouse results are yet different (the right side misbehaves):

(just tell me I should stop it )

[msmcleod]

2 minutes ago, chris.r said:

Back to reality  maybe I have another question, please let me know if I get that wrong.

Here's my starting point:

Here I'm getting expected results when deleting section:

But when I do 'Cut' and 'Paste' the threshold rules do not apply:

and when dragging the section with mouse results are yet different (the right side misbehaves):

(just tell me I should stop it )

The overlap threshold only applies to arranger drag operations, and delete.

Normal cut/copy/paste are unaffected... else it'd get far too confusing, as it's a deliberate arranger operation.