Same problem for me with 2.0.
Manually moving start times will NOT work. It only seems to work if you move your clip to the very beginning of the the song, but manual timing edits made later and later in the song will be further and further behind Sonar's timing. So this appears to be a TEMPO sync problem rather than something caused by jumping the now time and such.

A Mickey Mouse work-around for me was to break the track into 4 bar clips then move each clip (one at a time) to a separate track and to the beginning of the song. The timing displacement is still there but not noticeable so early in the song.
 
Why is everyone have this problem now all of a sudden?

Thanks I guess that's good news.

That is good news then (you seem pretty certain).
Have they set a release time for x3e?
 

JoeHimself
Same problem for me with 2.0.
Manually moving start times will NOT work. It only seems to work if you move your clip to the very beginning of the the song, but manual timing edits made later and later in the song will be further and further behind Sonar's timing. So this appears to be a TEMPO sync problem rather than something caused by jumping the now time and such.

A Mickey Mouse work-around for me was to break the track into 4 bar clips then move each clip (one at a time) to a separate track and to the beginning of the song. The timing displacement is still there but not noticeable so early in the song.
 
Why is everyone have this problem now all of a sudden?

It is caused by a rounding error in an algorithm, where one tempo is getting rounded, as stated earlier in this thread.  That's why it drifts off more and more as the project progresses.
 
I was surprised when I first started this thread that no one else had noticed it, but then it was quite a while before I did.  I think there are a few reasons why this was so.
 
Thanks to Phil and Dan at Cakewalk for their patience as I pestered them about it.
 
Cakewalk's customer service is great.  It is part of the reason why I constantly recommend Sonar to people.