Kingston: Is ctrl+slip-edit bug fixed?

Could someone please try this in Kingston? I have slow, unreliable internet.
It is easier with snap-to-grid turned off.
 
1) Record a few seconds of silence
2) Split the recorded clip in two parts with Alt and mouseclick, and then select the second clip.
3) In the track inspector, click on "Clip" and see that Snap Offset is "0"
4) Now press Ctrl, move the mouse to the right edge of the second clip (edge goes yellow) and drag it to make it a bit smaller.
It is important to do this with Ctrl pressed. This shortens the clip without cropping the end.
 
Did the Snap Offset value change? It should still be "0".
 
Thanks.
 

Thanks very much for taking the trouble.
 
That's the one bug I really need fixed because this type of slip
editing is part of my daily work routine - I shoehorn live-played
performances to fit the timing grid.
 
I registered the bug some months ago and hope it will be addressed
in a future version soon.

@stevec - Try it, the test is done quickly.
Yes, it only applies to the second and subsequent clips so splitting is mandatory.
 
It seems to be happening because the code is calculating the start from the underlying audio file instead of calculating from the position of the start of the clip itself. I base this assumption on the fact that Ctrl+Slip Editing the first clip works as expected. And normal slip-edit does not have this problem.
 
Bouncing is destructive, meaning going back later to make adjustments is impossible.

Looks like it can be reproduced with any clip where the start has been slip-edited; it doesn't have to have been split first.
 
I wonder if it's related to the bug I posted here: http://forum.cakewalk.com/Slip-edit-moving-things-wrongly-m3230458.aspx
 
That was a copied clip rather than a split one, but the underlying principle seems similar in that Snap Offset is changing when we wouldn't expect or want it to.

Good catch. I am surprised I have not run into this issue myself.  As someone else asked already - did you (OP) send in a bug report?

Kylotan
Looks like it can be reproduced with any clip where the start has been slip-edited; it doesn't have to have been split first.
 
I wonder if it's related to the bug I posted here: http://forum.cakewalk.com/Slip-edit-moving-things-wrongly-m3230458.aspx
 
That was a copied clip rather than a split one, but the underlying principle seems similar in that Snap Offset is changing when we wouldn't expect or want it to.

Ah, yes, you are right. It just needs a condition where the start of the clip does not coincide with the start of the audio file. Almost certainly same bug.

Hi there:)
 
I don't think it's a bug, cause the anchor point should not be 0 after slip editing, it should have the number of samples from the beginning of the first clip.
If you cut the clip and do permanent cutting, then after slip editing the offset stays of course at "0".
This is correct, and if you zoom in, you can see the clip isn't moving so all is OK!
 
IMHO the offset of the 2nd clip should not be "0" after cutting, but after permanent cutting, or am I false??
 
Bassman.
 

Ups sorry! I wrote "Offset", but I meant the anchor Point!!
 
Again:
 
1 Clip : Start at maybe bar 4.1.0 End 6.1.0
Anchor Point: 0
 
You cut it at 5.1.0
Anchor from both clips are: 0
 
When you Slip Edit Clip 2, it is a different clip in connection to clip 1, so the anchor point is now at 5.1.0, maybe 60 000, (don't know), at the beginning of clip 2!
 
If you now do permanent cutting, the anchor point becomes 0 again, cause now they are 2 different clips.
 
Perhaps my english is not good enough to declare, what I mean or maybe I'm totally wrong and it is a bug:)
 
Greets;)
Bassman.