Can anyone repro this behavior?

I think I've spotted a repeatable bug with recording in loop mode. Here's how to repro it on my machine:
 
1. open a new blank project.
2. Insert an audio track.
3. enable the audio metronome and set a 1 measure count-in
4. set a loop region and enable the loop. I use a two bar loop, but any size will work.
5. begin recording audio on the track you created. It doesn't appear to matter if you record more than one cycle of the loop region.
6. Stop recording and listen back.
 
On my system this always results in audio being about two beats late. The strange part is that the clip shows the correct time region, but the recording actually started during the count-in. For example, if I were to count beats into a mic (just saying "one, two, three" etc, one count per beat) starting on the first beat of the count-in and continuing for 2 bars (in 4/4), I would expect to record the numbers 5-12 and NOT record numbers 1-4 (they occur during the count-in), but that's not what's happening. What gets printed is numbers 3 through 10, i.e. the last two beats of the count-in are recorded and the recording ends two beats early.
 
If I'm recording without a loop or with no count-in it works fine.
 
Thanks,
Dean

Hi Craig,
Thanks for responding. I am using X3e build 352. Any chance you've had a moment to try this? I'm curious to see if it happens on anyone else's system or if it's unique to mine...
 
Dean

I've never experienced this because I don't use a count-in for a loop. I always set the now time somewhat before so that the song itself provides the count-in, and I can get "in the groove."

I just tried what I thought your steps were but couldn't get it to act up. Here are your steps, with more details on what I did. Steps 1- 3 were the same...I enabled the metronome for record only, if that makes any difference.

4. set a loop region and enable the loop. I use a two bar loop, but any size will work.
 
I set a two bar loop from measure 3 to measure 5.

5. begin recording audio on the track you created. It doesn't appear to matter if you record more than one cycle of the loop region.
 
I set the Now time to the beginning of the loop and started counting 1, 2, 3, 4 on the beat as soon as the countdown began. The now time didn't move during the countdown, then it moved and recording started.

6. Stop recording and listen back.
 
I stopped recording before the end of the loop, if that matters. When I played back, the clip started with 5, 6, 7, etc., as expected.
 
Then I thought maybe you meant that you had punch and looping enabled, so I tried that but still got the same results. Next, perhaps you had the loop starting at the beginning, so I tried that...but it still worked as expected.
 
I'm trying to figure out what's different about our two scenarios so I can reproduce it.

bapu
Time for a bug report.

 
This has been reported.  I know I reported this back in the X2 days, but I think it was user-error rather than software bugs.

brundlefly
Yeah, something's missing from the recipe or it's system-specific. I can't reproduce it, either, and I can't imagine this wouldn't have been reported before now if it were widely experienced.

Something is funky here, that's for sure. To compare X2 vs. X3, I just opened up a project in X2 with a count-in of 1, placed the NOW bar right on the loop point start, armed the audio track and hit the record button. The metronome counted off and then Sonar X2 started recording. Upon stop and inspection of the recorded audio, everything is OK and there is no delay. However, opening the same project in X3, and then performing the same test, results in the delay of audio (almost 3/4 of a bar). Now what the heck is going on here? I gotta remember what I changed in the preferences (or something) that corrects for this oddity. Hmm...
 
EDIT:  Turns out that I submitted a bug report CWBRN-18893 way back when that complained of a delay when reading an automation envelope if a metronome count-in is utilized. X2a supposedly fixed several metronome and count-in issues.

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

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.

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

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
 

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

I did some Googling of the forum because I remembered people reporting recordings starting one measure late. Most of them were about MIDI and were very old like SONAR 5-6, but there was at least one about audio in X1. Unfortunately, that one seemed to be affecting only a limited number of people and just petered out without any real resolution.
 
One thing you might try short of a complete uninstall/reinstall of SONAR is deleting/renaming your AUD.INI file and letting SONAR build a new one. You'll find it in C:\Users\<username>\AppData\Roaming\Cakewalk\SONAR X3 Producer
 
 

UPDATE: I was advised by Cakewalk to completely (and thoroughly) uninstall X3 and reinstall.  So I did, and things are not better; the recorded audio delay still existed.  So I uninstalled ALL versions of Sonar (X1, X2 and X3) and wiped the registry clean. as instructed by Cakewalk.
 
I just tested it now...and...
 
...the delay in recorded audio is still there!  Seriously...this is %$@#&@ ridiculous!!!
 

 
EDIT: If I change the metronome to MIDI notes instead of audio, the delay goes away. So what the heck does that mean?

2:43 AM, it appears you're overclocking your CPU. I'm not sure if that (or some setting related to it) could cause this, but I wouldn't rule it out given how unusual the problem is. How hard would it be for you to reconfigure for rated speed?
 
 

Yeah, that's the main thread I was referring to earlier. Did you ever try renaming your AUD.INI file or switching driver modes? You might also try enabling UseHardwareSamplePosition=1 in AUD.INI.