• SONAR
  • Kingston: Is ctrl+slip-edit bug fixed?
2015/11/29 15:23:07
jpetersen
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.
 
2015/11/29 19:16:26
icontakt
Just tried it. It not only changed the Snap Offset value but also introduced a gray unwanted vertical line in the second clip.
2015/11/29 19:53:07
jpetersen
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.
2015/11/30 14:54:07
stevec
Interesting...  I use Ctrl+Slip Edit fairly often but haven't run into this.    Does it only happen after splitting an existing clip and using one half?    If so, I'd bounce that clip first. 
 
2015/11/30 16:54:13
jpetersen
@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.
2015/12/01 12:51:45
stevec
Oh, I believe it happens the way you've described.    And I think you're probably correct in that the adjustment is based on the original wave file and not the portion displayed by the split clip.   That's why I thought bouncing first might work because it's now a new wave file whose extents are represented by the (new) clip. 
 
I don't think I've ever needed to make adjustments to the original pre-split data once ctrl+slip editing an (what I'd consider) independent clip so never really thought about like that.   Either way though, this sounds like a good one for the Problem Report forum!
2015/12/01 17:29:34
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.
2015/12/02 01:22:00
stlstudio
I just did the test and can confirm what you are experiencing. Hmmm.
2015/12/02 06:03:48
neirbod
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?
2015/12/02 07:25:52
jpetersen
Yes, I reported it recently under [CWBRN-40003]
But it goes way back to Sonar 8.5 and possibly earlier.
 
Occasionally people report flaky grid snap behavior.
This could be the cause of at least some of these reports.
12
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account