Loop recording was not perfect in 8.5. In ASIO, there were gaps at the end of each loop. This problem was fixed in X1d but at that moment punch-in was broken, at least in loop recording. So my conclusion is punch-in with loop recording on the same interval is both useless and unnecessary.

Loop recording with Input Quantize enabled is broken anyway. Record the first pass and listen to it when it loops back(with record still on). You will hear it dropping notes.
 
http://www.screencast.com/t/wk0bcP4KcrC4
 
I sent in a bug report.

Adralicus
Loop recording with Input Quantize enabled is broken anyway.

Yes we know, but that's totally unrelated to this thread. 
 
As for the actual topic, I can't reproduce a problem (as usual - since none of the loop-drift scenarios seem to affect my DAW). I don't think it should matter, but I wonder in this case whether it might be due to not having latency compensation dialed in with the appropriate Manual Offset to compensate for unreported latency...?   Bzzzt! Wrong answer! See my post #16
 
And with reference to bvideo's post about looping and punching the same interval, I presume the reason for combining looping and punching is to be able to loop some bars in advance of the punch region to "get in the groove" ahead of the punch region on each pass. So the punch region is not the same as the looped region.

Brundlefly,
  No manual dial-in here. I agree with your reasoning; i.e. looping some bars outside of the punch-in interval for a wind-up would be useful, whereas simultaneous intervals are not necessary. If you have tested punch-in recording strictly inside a loop, i.e. not simultaneously with a loop, and found no gaps or timing problems with the recorded segments, that's a good enough result. How about with either or both of the punch-in endpoints lined up with a loop? By the way, what I found was not a timing drift, but errors in the length of punch-in recorded segments.

Brundlefly,
When looping AND punching in, you are NOT seeing problems with the 2nd thru whatever passes?
Here is how my "sync" is setup.

I have the same issues with my StudioCat DAW and my office setup.
 
T

Hmmm... did some re-testing, and I am able to reproduce it in X3c now, punching in two bars in the middle of a 4-bar loop. Each take is 172 samples later than the previous one - about 20 samples more than half my total latency.
 
Interestingly, if I enter that value as a Manual Offset, then all of the takes are 172 samples late, but the error is not cumulative. Oddly, though, I have to enter it as a negative offset (i.e. decompensation) rather than the positive value you would expect would be needed to compensate for latency.
 
Definitely an issue here, in any case. Apologies to the OP for not double-checking.

Brundlefly, did you really mean X1C? There was a change from X1c to X1d (deeringamp's signature Sonar version). (Edit: ok deeringamp updated his sig to X3C)

Just to clarify the "Loop & Punch" issue is consistent in all of the Sonar X series.
IT DON'T WORK!
Brundlefly,
I've never been "patient" enough to track down the error, "about 20 samples more than half my total latency" gives me a place to start; thanks for that!
Sounds like 20 is the "hidden" samples for your driver to me.
Thanks to all,
 
Tom

DeeringAmps
Sounds like 20 is the "hidden" samples for your driver to me.

Yes... sort of.
 
What SONAR reports for RTL is within 2 samples of what CEntrance reports for a digital loopback with no A/D/A conversion, whereas an analog round-trip is 40 samples longer. So 20 samples is approximately the one-way converter latency.
 
But it doesn't make sense that is would up in this case since SONAR doesn't know about the converter latency and I did the test with digital loopback. 
 
So I think there's something else going on, and it's just coincidence that it seems to match the unreported converter latency.
 

bvideo
Brundlefly, did you really mean X1C?

D'oh! Changed to X3c, and updated my sig, too.