shmuelyosef

swamptooth
this seems to be a looping artifact  in sonar.  
the basic way that i tested the idea was setting up a project with the 122 and 140 bpms and pulling in a loop, 
dragging it to bar 95 and bouncing.  
if you take a look in the media browser, you can click on a loop and see its number of samples, which changes on load and tempo and sample rate and then whether you loop or unloop it.  
i think that there is an inherent difference between the way reason, cubase and studio one handle "loops" - they basically make repeated copies of the data, which is a bit different from sonar's method.  
what i think is happening is as was suggested above - the clock ticks are dropping 7 samples - because if you look at the clip in m:b:t time reference it shows a length of 375:959.  
if it was dropping 7 samples per bar i think it would be an issue.
i'm having flashbacks of looking at this about 3 years ago...

When you do a Groove Clip in Cakewalk and extend it to multiple copies, do they actually re-sample with interpolation for each subsequent copy, in order to maintain a constant clock rate?
Or does Cakewalk merely treat the bpm input value as a suggestion and then adjust so that each measure has an exact number of samples without jitter of the position of the first sample? 
How, exactly, do cubase and studio handle this? Do they just accept the jitter from measure to measure, and eat the phase issues that are introduced?

I think what's happening in cake is rounding error.  to start with a simple test using the op's settings, take an audio clip and cut it at measure 2 then bounce the first measure of the clip and delete the remnants of the original at measure 2.  click the 1 bar clip and check number of samples in the clip inspector and it should be 86755 - one sample too long.  now, loop that clip and the samples drop to 86754 which is dead on.  change the clip inspector's time format to m:b:t and drag the loop measure by measure. the time should read "beat:959" at measure 2 until you hit measure 12 or so where it resets to "44:000".  so this to me looks like a rounding issue at some level.   
studio one and cubase use several very different time stretch algorithms which can be changed based on need and implementation, so it's a little difficult to compare esp as far as jitter goes - which with these 1/44100th of a second oddities can be a bear to nail.

I emailed cakewalk to see if i could get a definitive answer, but it seems like they probably aren't going to bother. Thanks everyone for the input though! As I and few others have said, this isn't really a practical issue, so for now I'll just ignore the discrepancies I'm getting.