Okay, but there's still something missing from the "how to repro" recipe, or Brundlefly and I would have been able to reproduce it.

Changed the count-in from 8 measures to 0 and loop recorded 4 takes. All four lined up as they should. Heh?  I never had to sacrifice my count-in ability before????
 
But then I remembered an issued from way back in like Sonar 6 I believe. There was this what seemed like an awesome capability introduced to be able to arm a track during playback/record. One time I tried it cause during a session we had a really great vibe on a particular take and I wanted to open up an extra ambient mic in my drum room. Seemed like it was a great opportunity. Needless to say doing so shifted all other tracks in the session. BOOO!  So I never used it again.
 
Anyway, because I took that trip down memory lane; it reminded me that setting is somewhere probably. Preferences/Project/Record. Uncheck the "Allow Arm Changes During Playback/Record" box. I did so and changed the count-in back to 8 measures. Hey, I have a long hallway to run down to get to my son's room to track these vocals.. I need some good lead time. I've tested this and all takes lined up beautifully.
 
Don't know what good use that setting has but I have no use for it in my world. Hope this helps others.
 

Hm..so this is interesting and may narrow down the behavior. My default project has an audio track at track 1 that functions as a loopback. It has input monitoring turned on, so when I've replicated the symptoms it has always been with another track present with a different input and input monitoring turned on. If I turn off input monitoring on that other track the behavior goes away.
 
So the real recipe seems to look like this:
 
1. Open a new blank project.
2. Enable audio metronome and set a count-in of 1 measure.
3. add an audio track and set its input to some input on your device.
4. enable input monitoring on that track.
5. add a second audio track and set it's input to an input on a different stereo pair than the one you chose in step 2. So if you used input 1 above, use something other than 1 or 2. Record Arm this track. Input monitoring on this track doesn't appear to matter.
6. Set a loop region at measures 3-4
7. Place the now time at measure 2
8. begin recording.
 
For me this always results in the audio being delayed and part of the count-in being recorded. If I remove the first track, remove the the loop region, turn off count-in, or turn off input monitoring on the track I'm not recording on, it works without a problem.
 
For the folks for whom this was working would you mind testing with the new steps? For the folks who could repro it, do you have some other track with input monitor enabled?
 
Thanks for the help folks. I appreciate it.
 
Dean
 
EDIT - Just read Sphere720's post about "Allow Arm Changes During Playback/Record". That option is not checked for me.

The new recipe you gave is more like my custom Normal template (I used a copy of the X3 default Normal template the first time), and it doesn't exhibit any issues, either. But I've previously reported various issues around arming on the fly, MIDI automation, tempo changes and metronome count-in in different versions. But none of them ever yielded quite the problem described in the OP, and the description seemed to suggest it could happen with a barbones project started from the Normal template.
 
Is the anything else in the project that's not part of the Normal template?
 
Also, am I reading correctly that you run three different audio interfaces? Are you using WDM driver mode, then? If so, this could easily be an issue with driver/clock/timing master setting issues. WDM drivers seem to be more prone to this kind if problem. When you mentioned using different audio inputs, are they on the same interface?
 
 

Hi Brundlefly
Thanks for the help. The only things in the project other than the two audio tracks are a master bus that goes to a hardware out and a metronome bus that also goes to a hardware out. I'll try removing the buses as well when I get back to it tomorrow. Other than that, when I replicated it most recently I opened Sonar, closed down my "normal" template and hit "File, new" and then selected "blank project" just to make sure that it wasn't a problem with my template. I then created a Master and metronome bus, assigned them to outputs and added tracks as my recipe shows. Both tracks were routed to the Master bus.
 
re: Audio interfaces, I just have one, the RME MADI fx card. It connects via MADI to the Orion and the Aurora which function as standalone converters. Neither has a connection to the PC other than via MADI to the RME. For my recipe I was using inputs 1 and 3, but I replicated it with all kinds of combinations...my "normal" template was using inputs 5 and 105 when I originally repro'd the problem, and input 105 isn't even connected to a converter...
 
Thanks again,
Dean

sphere720
Uncheck the "Allow Arm Changes During Playback/Record" box. I did so and changed the count-in back to 8 measures. Hey, I have a long hallway to run down to get to my son's room to track these vocals.. I need some good lead time. I've tested this and all takes lined up beautifully.
 
Don't know what good use that setting has but I have no use for it in my world. Hope this helps others.

I absolutely love this setting! I find it very useful.  I do 110% of my song writing/creation on the fly, so Sonar is usually playing all the time.  With this setting checked, each track's record button is able to be turned on while in playback as opposed to having to hit stop, then arm, then press record.  Overall, I can simply arm/disarm at will, then click the main record button. I find that it keeps me in the groove and allows for more creative possibilities.
 
OK, so here's the breakdown for me.  Something definitely amiss:
 
100% natural, home-grown from real X3 dirt, organic X3 blank template used in X3:
"Arm-changes" preference CHECKED, Looping turned ON = delay in recorded audio
"Arm-changes" preference UNCHECKED, Looping turned ON = NO delay in recorded audio
"Arm-changes" preference CHECKED, Looping turned OFF = NO delay in recorded audio
"Arm-changes" preference UNCHECKED, Looping turned OFF = NO delay in recorded audio
 
Artificially flavored, X2 blank template (or X2 project) used as hybrid (but non-GMO) in X3:
"Arm-changes" preference CHECKED, Looping turned ON = delay in recorded audio
"Arm-changes" preference UNCHECKED, Looping turned ON = delay in recorded audio
"Arm-changes" preference CHECKED, Looping turned OFF = NO delay in recorded audio
"Arm-changes" preference UNCHECKED, Looping turned OFF = NO delay in recorded audio
 
Overall, this sucks. It's definitely a bug, IMO; a bug with looping and project/file origination. Bug report time! Why does it properly work in X2 and it's back to being messed up in X3. Did Cakewalk forget to put the bugfix back in X3a/b/c/d/e? I am very happy I paid $99 for an old bug. Wonderful.
 
EDIT: Problem report CWBRN-25502 just submitted.

Hi 2:43AM
Thanks for helping out on this and submitting the bug report. I'm trying to nail down these symptoms as much as I can for when I submit a bug report, so I did a bit more experimenting. Here's what I get.
 
New blank project (not from a template at all). No buses, 2 audio tracks (track numbers 1 and 2). Track 1 has input 1 assigned, track 2 has input 5. Loop region at measures 3-4, playhead at 2. Track 2 is record armed. Audio metronome on, count-in of 1 measure. 
 
1. recording with Allow Arm Changes During Playback off and no input monitoring - works fine. No recording during count-in, no delay.
2. recording with Allow Arm Changes During Playback on and no input monitoring - records the entire count-in period. All four beats. Audio during the actual recording period is delayed or cut off.
3. recording with Allow Arm Changes During Playback off and input monitoring track 1 - records the last two beats of the count-in period.  Audio during the actual recording period is delayed or cut off.
4. recording with Allow Arm Changes During Playback on and input monitoring turned on for track 1 - records the entire count-in period. All four beats. Audio during the actual recording period is delayed or cut off. 
 
If I turn off the count in or de-activate the loop it works fine.
 
2:43AM - When you record arm a track other than the one you're recording on and set it's input to some input other than the one you're recording on (on a different stereo pair) do you get the same results I get?
 
Thanks again,
Dean
 

I strongly suspect his is hardware/driver-specific. I think the fact that the thread has no new contributors is evidence of that.
 
I still can't reproduce any kind of a record-timing issue with any combination of looping, count-in, Allow Arm Changes and input monitoring when starting recording with Now at 1:01:000 and looping the first 2-4 measures.
 
The only case in which I've seen anything like this is when starting recording with a track armed, disarming it on-the-fly during the count-in, and then re-arming on the fly and recording later in the project. Obviously this is a very unusual scenario, and in that case the recorded audio ended up shifted earlier not later IIRC.

Hi Brundlefly,
I think the theory that this is hardware/driver specific is certainly possible.
 
2:43AM - are you using RME gear?
 
Dean

Razorwit
2:43AM - are you using RME gear?

I am not using any RME gear. I have a Focusrite Firewire interface.
 
My bug report came back from Cakewalk. I need to call them. "The problem you are experiencing is most likely a system specific problem or a configuration issue that we believe can be resolved with assistance from Cakewalk Technical Support."
 
If I get a chance to today, I will try to give them a call.