Loop & Punch problem SOLVED!

Do you record with the metronome on?

Turning on the metronome causes Sonar to line up the recorded audio correctly?
 
T

DeeringAmps
Turning on the metronome causes Sonar to line up the recorded audio correctly?
 
T

Yeah, same thing I am asking. Why?
 
I may have never noticed this, behavior,  because what I always do is leave the metronome on and mute it. But not for timing reasons! I leave it on because at some point in the project I will use it again and I find it easier to just unmute it.

Grem
 
 
Yeah, same thing I am asking. Why?
 

It has been discussed many times and it appears that the metronome affects loop recording. No one from Cakewalk has ever suggested a reason it is just an observed behavior.

Turning the Metronome "on" does NOT solve the problem on my system!
 
Simple loop back test.
A few measures of audio, sent out output 3 (doesn't matter) and brought back to input 5 (again doesn't matter).
When I "loop" the section, ALL recorded audio lines up perfectly (null test).
If I "loop & punch", the FIRST recorded audio is spot on; after that each section gets later and later.
The solution; loop, but do not punch in.
Then "trim" the recorded audio.
I'm storing each "take" as a new track, I'll try it with each new "pass" being a new "lane".
 
This should work, come on Cake!
 
T

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.

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.

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.

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

bvideo
Brundlefly, did you really mean X1C?

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

An experiment on X3c:
Did a punch-in/out record of two measures taken during a 4 measure record, no looping. The recorded clip was placed properly in the timeline, data lined up in sync.
Imported the file into which the punch-in was actually recorded into a separate track.
Lined it up sample-for-sample with the clip placed by the punch-in.
The recorded file has an extra 256 samples at the beginning and an extra 84 samples at the end.
 
Then when I did a 4-measure loop recording with a 2-measure punch-in/out, each successive take was placed 256 samples later than the previous. My ASIO buffer size is currently 128. Reported latency is 148 in, 236 out.
 
I was about to go on with experiments, but suddenly the loop & punch-in record started behaving weirdly: each take in the loop was made of a tiny 1024-sample clip followed by a clip that filled the rest of the punch area. I saved and restarted, and the problem persisted. I give up.

bvideo
I was about to go on with experiments, but suddenly the loop & punch-in record started behaving weirdly: each take in the loop was made of a tiny 1024-sample clip followed by a clip that filled the rest of the punch area. I saved and restarted, and the problem persisted. I give up.

That sounds like what happens when you comp record and stop the transport just after the the next iteration of the loop starts; all previous takes get split at the end of the snippet in the last take lane. All you have to do is delete that last partial take, and swipe through the last complete take with the comp tool to heal the splits in all the remaining takes.

Hi Craig and Brundlefly,
  Thanks to Brundlefly for the explanation to Craig; that's what I meant. The old loop recording bug and this punch-in/out problem have some evidence behind the scenes, and also a potential built-in workaround, which is the actual file where the audio was recorded. The clips placed on the timeline by the loop or punch record are really just different segments of that file, with the clip start and end edges locked so they can not be slip edited to reveal any other data in the file. Importing the file allows us to align, slice up, and set the clip boundaries correctly, if the data is all there. That was what I wanted to check next with multiple passes over a loop with an interior punch region.
  About the tiny clip, I get what you're saying. I did have recording set to comp, but every time that happened I had stopped the record after the punch-out point and before the end of the loop. In other words, I never stopped recording within the punch region. I think that means all the clips should have been intact.
  Bill B.
 
Aha! Set the record mode to sound on sound. Stopped recording after the fourth punchout and before the end of the loop and got a fifth take lane with just a tiny clip.  This one contains 768 samples after recording 4 full loops. That is the same number of samples by which the fourth take is delayed (3*256).

So DeeringAmps has created a new thread saying that this isn't fixed. Rather than split the discussion over two threads I'm responding here. Could anybody do a test case for this please if it still exists in X3D, here is an example of a test case (totally unrelated!!). We need exact steps to reproduce.... Let's just make this totally clear... Supply screenshots but only if necessary. Make sure you supply all steps starting with "Start Sonar X3d, create new project". Got to be extremely detailed... thanks...
 
TEST CASE EXAMPLE:
 
STEPS FIRST ISSUE

Turn on 3 USB MIDI devices (such as keyboards), each MIDI device has it's own channel (say 1 + 2 + 3).
Start Sonar X3D
Create new project
Insert 3 Dimension Pro softsynths.
Assign an exclusive sound for each softsynth.
Assign a single MIDI device to each softsynth track, making sure the MIDI input channel is specifically set correctly. i.e. If it's a Yamaha keyboard on channel 1, assign Yamaha Keyboard ->  MIDI ch.1.
Check to see if instruments play correctly.
Save the Project.
Close Sonar X3D application.
Turn off one MIDI device.
Start Sonar X3D
Open existing project.
Now play the MIDI controllers.


EXPECTED...

a) Some warning that MIDI devices have disappeared.
b) All three MIDI tracks have maintained their values, however the missing device is flagged up in some way.

ACTUAL...


The track with the missing MIDI device seems to have had the MIDI input changed to one of the other MIDI Input devices (which is weird).
Another MIDI Controller will have it's value changed for no reason whatsoever.
A third MIDI Controller will have the value persist.

Nevertheless if this is a bug I'm keen to reproduce. There's always a million ways to skin a cat I agree :)