New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Copy-paste bug fix #5555
Copy-paste bug fix #5555
Conversation
8c9369c
to
d3f264d
Compare
@@ -1942,7 +1937,7 @@ void WaveTrack::HandleClear( | |||
} | |||
else | |||
{ | |||
if (split) { | |||
if (split || clearByTrimming) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder what if both are true
? I inspected calls to that function and didn't find place where it's the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think either that both happen to be true. AFAICS if split
is true, whether clearByTrimming
is true or not doesn't make a difference. If the former is false, though, we clear by trimming (as opposed to completely deleting) but the resulting smart clips on the right are moved back left.
Split-cut leaves clips in place, which isn't necessarily what clear-by-trimming wants.
This rectifies a small behaviour change from 3.3.3: With "Edit Clip Can Move" checked, pasting at the exact beginning of a clip used to move that clip right w/o merge.
Since the boundary-checking code was modified, `WithinPlayRegion` already includes the start sample.
d3f264d
to
b0df2c6
Compare
Resolves: #5523
Resolves: #5599
Recommended:
QA:
This PR intends to restore the exact same behaviour as that of 3.3.3 insofar as the "Always paste audio as new clips" option is disabled and no stretching is involved.
I put together this truth table:
There's a lot of redundance I didn't bother cleaning up, sorry about that.
Explanation of column names:
Besides that: