Snap to grid fails on stretched audio

I take a 4-bar piece of audio that has been stretched to 86%, ensure Snap is set to 'To' and to 'Whole Note', drag-copy the audio to the right, and it aligns it to about 60% of the way through the 4th bar. Nothing I can do with Snap enabled will get it to line up with a measure. If I switch from whole notes down to something smaller, I can reduce the amount of error - eg. snap to 1/16 means I can get it to about 60% of the way through the 4th beat of a bar.
 
Here's the really weird thing: even manually editing the clip's Start time in the properties doesn't work. If I edit it to 8:01:000, it moves it to the wrong place and the resulting value is 7:04:082.  Nothing works.
 
But if I stretch the audio back to 100%, and then try moving it around with Snap to Grid on... it goes exactly where I'd expect.
 
Known bug? Is there a workaround? I need to be able to stretch audio and move it around for an entire song, so if this is totally broken I'll have to ditch Sonar for this track.
 
Using Sonar X3e build 352, 64bit.

The situation is exactly as you described it, but I think I have found the culprit.
 
When I perform the stretch operation, a tiny little flag marker appears some way in from the left; and it is this which gets snapped to the grid.
 
This appears to be a 'snap offset' in the properties - if I change that to zero, everything works from that point onwards.
 
No idea why the offset appears with a seemingly arbitrary number - that appears to be a bug.
 
So, hopefully I can proceed with my project now (apart from all the other bugs that are appearing by migrating from 8.5 to X3, mostly with take lanes getting very confused over how they are supposed to handle what used to be layers).
 

Kylotan
No idea why the offset appears with a seemingly arbitrary number - that appears to be a bug.

Probably some kind of 8.5/X3 translation, but there's also a keyboard shortcut for that function - don't recall what it is offhand. Maybe it gets triggered accidentally?
 
I always try to finish projects using the program with which they were started, but if that's not possible, then I cheat and export the raw audio and import that into the new version.

Kylotan
And exporting raw audio would just be a nightmare as I am trying to work with individual clips.

This is why the time-stamped Broadcast Wave format can be so helpful. Then all the clips show up where they're supposed to. 
 
Try this: In 8.5, export all the clips as individual Broadcast Wave files with names that indicate clearly the tracks to which they belong. I think you can also just "save as" the project and save each clip as an individual file. In X3, open the 8.5 project, then delete all the audio so you have the same "structure" you had before. Then, drag the clips into their respective tracks and they should line up where they were in 8.5.
 
This is from memory, but I'll check into it later as it would make a good general-purpose tip anyway for any kind of transfer, even from one DAW to another.
 
There's usually an easy way to do things with Sonar...the hard part is finding it 

Kylotan
Seriously, this would take hours. I have several hundred audio clips in any given project, plus MIDI clips, markers, and other events. Cakewalk just need to be getting their backwards compatibility working properly if they don't want to supply fixes for old versions. This isn't something I should have to work around.

I'm going to give it a try anyway. I have several really complex projects I can test...I'll see how long it takes to export from Sonar and import to Cubase. I think there are enough shortcut options, like batch saving or maybe even drag and drop directly from one project to another, that it would take a lot less than several hours. I also have some 8.5 projects but haven't experienced the issues you have, so that's probably not a good test...getting files into a different DAW altogether would be interesting.
 
Remember, the key is opening the old project and just deleting/importing the audio. If the markers and other accoutrements exist, and you don't delete the MIDI files or instruments, then it would be a pretty speedy process.
 
Agreed total backwards compatibility would be great, but there are several key functionality differences. The X-series is essentially a new DAW.

Kylotan
Ok, I have a test case for you that shows it's not a compatibility issue, just a bug.
 
1) Create new project with Normal template.
2) Add an audio track.
3) Record 4 bars of audio, or just over that amount.
4) Slip-edit the start and finish so that only 2 bars remain.
5) Ctrl-drag the end so that the clip now takes up 1 bar, showing '50%' at the top.
6) Note that the clip now has a snap offset - in this test, it appears to be almost exactly half-way through the clip for me.

Wow, thank you! Being reproducible is the holy grail of bug fixes. I would have never found that. 
 
After some preliminary tests, it seems to happen only if you slip-edit the beginning and therefore move the clip off the Now time before stretching, which is another clue given that Snap Offset normally is related to the Now time. I'll pass the info along to the bakers.
 
 
 

Workaround: 'Apply Trimming' to slip-edited clips before stretching them.

Kylotan
The situation is exactly as you described it, but I think I have found the culprit.
 
When I perform the stretch operation, a tiny little flag marker appears some way in from the left; and it is this which gets snapped to the grid.
 
This appears to be a 'snap offset' in the properties - if I change that to zero, everything works from that point onwards.
 
No idea why the offset appears with a seemingly arbitrary number - that appears to be a bug.
 
So, hopefully I can proceed with my project now (apart from all the other bugs that are appearing by migrating from 8.5 to X3, mostly with take lanes getting very confused over how they are supposed to handle what used to be layers).
 

AHA!!!! I'm going to have to give that a try because I had to completely abandon Sonar for the MASSIVE time stretching adventure I've been on (which is thankfully/hopefully coming to an end today).
 
So yes... I noticed Ctrl stretching was not obeying Snap and yes I saw the grey Offset flags (but didn't know what they were). If changing a setting fixes it that would be AWESOME.
 
However it still doesn't help me with the type of bulk work I've been doing (multi track sessions) because even if the clip stretching obeys Snap it does not obey "Clip Groups" (as in grouped clips of a multi track session will not stretch simultaneously and instead need to be stretched one at a time).
 
So the combination of having to manually and visually line up my transients to the desired measure/beat marker without Snap and then having to REPEAT that process for EVERY clip (which requires VERY high Zoom resolution to avoid "phasing" across the tracks/clips) was of course VERY cumbersome.
 
If Snap worked then it becomes WAY easier but still a pain because each clip would still need to be Snap Stretched one at a time.
 
If there is a solution to that Grouped clip stretching problem I would LOVE to hear it (and I posted a thread about it some months back once I discovered this).
 
In the meantime I've taught myself how to make this all happen in Reaper (which was a massive undertaking itself). Multi track stretching works SOOOOOOO much better/faster in Reaper but of course once it's done I scramble back with the files to Sonar because to me it's just a better creative tool for me.
 
If they fixed these time stretching issues I would be ECSTATIC but they seem to be focusing on other stuff so I can only hope some love will be given to clip stretching in the future.
 
The other problem is that even using brute force to make this type of stretching happen with Sonar (I did a couple songs before giving up) it causes some crazy instability and eventually project corruption. The method I figured out works flawlessly for a while (although time consuming) but as the project plods on things get quirkier and quirkier until it's impossible to continue.
 
Not a rant or whinge. Mostly just posting this so people don't have to suffer through the growing pains I did and to maybe get the attention of the Baker's/community so this gets sorted at some point.
 
Personally I'm finding shuffling back and forth between Reaper and Sonar quite useful and interesting. The two programs compliment each other quite well IMO.
 
Cheers.

Kylotan
I'm not sure it qualifies as a workaround given that it's destructive to the original clip. But it might be enough for some.

All workarounds involve compromises; take it or leave it. If you just want to "git 'er done" and move on, this is an option.
 
You can copy the original clip to a muted lane if you're concerned about reversibility; I would recommend that in any case when making multiple splits, moves and stretches. At some point all those individual edits are going to become effectively irreversible anyway.