Help! Problem with recording on time

[redlogic]

Here

[gucciescalade]

OK.

When i click ping it does nothing

 

Another thing is since i don't record audio with the digital or analog inputs, i record with a mic and xlr cable, wont the recording delay be different? Or will this test have the correct delay for my mic plug in also?

[ERO]

(Deleted)

[redlogic]

I just wanted to mention something.

 

It's a good idea to check the recording delay every time you update your audio interface drivers.

 

I've gone from Fireface 400 driver version 2.59 through 2.75 and the recording delay has consistently been +2 samples late.

 

RME just came out with the "new & improved" version 2.83 with overall reduced latency.

 

Great, I thought!

So I installed it and checked the recording delay.

Now it's +34 samples late.

How's that for progress

 

Anyway, the moral of the story is:

 

Check your recording delay when you update your audio interface drivers.

They just might have a few unspoken "improvements".

[ski]

I'm glad you mentioned this, redlogic. "+1" to the idea of regularly re-checking the recording delay figure, especially after updates of driver software.

 

And FWIW, after reviewing this thread, I think it' worth mentioning here in the latter part of 2010 that the loopback test I wrote up was written back in the Logic 7 days, before there was a ping feature in Logic. Pinging certainly does seem easier in terms of discovering the proper setting for recording delay, though doing an actual loopback test is more educational and informative, IMO.

[redlogic]

And FWIW, after reviewing this thread, I think it' worth mentioning here in the latter part of 2010 that the loopback test I wrote up was written back in the Logic 7 days, before there was a ping feature in Logic. Pinging certainly does seem easier in terms of discovering the proper setting for recording delay, though doing an actual loopback test is more educational and informative, IMO.

 

True.

I always check both ways.

 

 

I 'aint gonna trust no fancy pants Star Trek "ping" thingy. 8)

 

 

 

Has anyone seen my crossbow?

I'm hungry!

[ski]

Crossbow? What's that? All we know around here are rocks and sharp sticks.

[redlogic]

I had to do something.

I was spending the better part of a day chasing rabbits and squirrels on foot.

[ski]

I spent all of last week sharpening a stick so I could have a toothpick to get a squirrel bone out of my teeth.

[redlogic]

Wow!!!...you still have teeth?

[ski]

Wow!!!...you still have teeth?

 

After eating your squirrel stew? No...

[jwhitesides]

In trying this method in Logic 9.1.4 in OS X 10.6.8 I'm finding that when I hit the Ping button, it only outputs through 4 and does not output from the audio strip or the stereo 1-2 output.

 

I've tried several times to do this and every time I get only an output on channel 4, but nothing on the audio strip or anywhere else.

 

Is anyone else experiencing this problem where Ping isn't Pinging as described in this method?

 

In using the old fashion Ski method, I've determined that my delay should be 45 samples. But the Ping registers 0. I know that's not right.

[robertg]

Well, this was interesting. I use different audio interfaces for input vs. output. A mackie onyx 1220i mixer due to the large number of inputs for the cost, and a TC desktop konnekt audio interface for the output (and its large backlit volume knob)

 

both are connected via firewire.

 

In this configuration, I get about +767 latency offset, and the best part is that it's a different value every time I hit the ping button.

 

Before I ran the test, I always had to delay midi parts from my synths about -37ms. I'd like to improve that considerably. I wonder what I should do?

 

Using just the TC as my in/out, I get about +68 samples offset. But I need at least 12 analog inputs and don't want to spend $1400+ for a MOTU 24io. Any suggestions, maybe something is broken?

 

EDIT: I rebooted and tried again, it's down to +350, but still jumps around up to +500 every time I hit the button. Still shitty. I'll try again without the cheap firewire hub in play.

[ski]

In using the old fashion Ski method, I've determined that my delay should be 45 samples. But the Ping registers 0. I know that's not right.

 

There shouldn't be a discrepancy, but then again, unless you follow my method exactly (starting with an entirely blank song and laying up just an audio track to make the test), it's possible that you might get different results using ping. I'm going to suggest that the old fashioned method can be counted on to provide a real world, accurate result.

[superiorinferior]

Record in Low Latency mode

[ski]

Record in Low Latency mode

 

That's not the issue. We're talking about a recording delay, not trying to overcome latency from plugins.

[robertg]

Does the recording delay setting affect input playback on an aux channel or just recording?

 

What's really curious about this is that my recordings are spot-on with the recording delay set to 0 samples. it's only when playing back the unrecorded midi (audio input on an aux) that I have to adjust delay to -37.

 

If I accidentally record without setting the delay back to 0, all is fine if I adjust the recorded part to +37.

[ski]

The recording delay setting ONLY affects the playback position of audio recorded from live inputs, OR, in some cases, audio recorded digitally (internal loopback recording).

 

Changing the recording delay setting after making a recording has no effect whatsoever on the later playback & timing of that recording.

[robertg]

The recording delay setting ONLY affects the playback position of audio recorded from live inputs, OR, in some cases, audio recorded digitally (internal loopback recording).

 

Changing the recording delay setting after making a recording has no effect whatsoever on the later playback & timing of that recording.

 

Just audio -recorded from- the live inputs, or playback as well? I already know that moving the slider doesn't affect what's recorded, but changing the delay setting for the region does.. that's what I've been doing.

[ski]

The recording delay parameter and the delay parameter you mentioned are unrelated.

 

To clarify (for the sake of the thread), here's an example of using both of these delay parameters:

 

We're in the studio and recording a live drummer, "Manny the Machine". His playing is sooooo tight with the click that his parts sound quantized! While we're recording we're monitoring the click and his live drums, and it's all sounding tight as a gnat's ass. But because of the latency inherent in the audio system, when we play back his track it sounds late against the beat. Manny gets very upset at this because he prides himself on his timing.

 

Oh, and of course, that take he just recorded? That was his best work. Ever.

 

So now everyone in the studio is on edge now because Manny, out of frustration and anger, is lighting fire to some guitars and gobos in the studio while the boys on the other side of the glass frantically try to figure out what's going on. Then some know-it-all pizza delivery boy named David Nahmani walks in with a large anchovy, extra cheese pie and overhears what's going on. He clears his throat and asks in a haughty and outrageous French accent if anyone's bothered to calibrate Logic's recording delay parameter. The engineer sports an surprised and embarrassed look on his face and answers, "no". So they do the calibration as posted here on Logic Pro Help by another know-it-all named Ski, and they find that the delay inherent in the audio driver is 50 samples. The engineer then sets the recording delay parameter to -50 and gets Manny to calm down enough to do another take. In the control room, they're monitoring the click and Manny's drumming as they did before, to hear how tight it sounds. And it's tight! Then they play back this latest take and sure enough, it sounds exactly the same on playback. Problem solved!

 

So everything's great until the producer finally shows up at the session and his opinion is that the drums need to sound a little bit more laid back against the rest of the track. It's too late to get Manny back into the studio, cuz he left for the local watering hole two hours ago and is already on his 4th round. To give the producer what he wants, the engineer sets the region's realtime delay parameter -- as found in the Inspector -- to a small, positive value, making the drums sound a little bit late against the click. That seems to do the job until the producer changes his mind. Now he wants to hear the drums play a little ahead of the beat. So now the engineer changes the region's delay parameter to a negative amount and now the drums are rushing against the track.

 

Hope that explains things a lil' bit.

 

[robertg]

The recording delay parameter and the delay parameter you mentioned are unrelated.

 

To clarify (for the sake of the thread), here's an example of using both of these delay parameters:

 

We're in the studio and recording a live drummer, "Manny the Machine". His playing is sooooo tight with the click that his parts sound quantized! While we're recording we're monitoring the click and his live drums, and it's all sounding tight as a gnat's ass. But because of the latency inherent in the audio system, when we play back his track it sounds late against the beat. Manny gets very upset at this because he prides himself on his timing.

 

Oh, and of course, that take he just recorded? That was his best work. Ever.

 

So now everyone in the studio is on edge now because Manny, out of frustration and anger, is lighting fire to some guitars and gobos in the studio while the boys on the other side of the glass frantically try to figure out what's going on. Then some know-it-all pizza delivery boy named David Nahmani walks in with a large anchovy, extra cheese pie and overhears what's going on. He clears his throat and asks in a haughty and outrageous French accent if anyone's bothered to calibrate Logic's recording delay parameter. The engineer sports an surprised and embarrassed look on his face and answers, "no". So they do the calibration as posted here on Logic Pro Help by another know-it-all named Ski, and they find that the delay inherent in the audio driver is 50 samples. The engineer then sets the recording delay parameter to -50 and gets Manny to calm down enough to do another take. In the control room, they're monitoring the click and Manny's drumming as they did before, to hear how tight it sounds. And it's tight! Then they play back this latest take and sure enough, it sounds exactly the same on playback. Problem solved!

 

So everything's great until the producer finally shows up at the session and his opinion is that the drums need to sound a little bit more laid back against the rest of the track. It's too late to get Manny back into the studio, cuz he left for the local watering hole two hours ago and is already on his 4th round. To give the producer what he wants, the engineer sets the region's realtime delay parameter -- as found in the Inspector -- to a small, positive value, making the drums sound a little bit late against the click. That seems to do the job until the producer changes his mind. Now he wants to hear the drums play a little ahead of the beat. So now the engineer changes the region's delay parameter to a negative amount and now the drums are rushing against the track.

 

Hope that explains things a lil' bit.

 

 

Great story I already understand all that, but with all due respect that wasn't really my question...

 

I don't do any live recording in the sense of recording human performances, only recording synths that have midi tracked. I'm curious if adjusting the recording delay is going to solve my problem of having to delay my regions -37 ms every time (while auditioning only).

 

Just to clarify: If the recording delay is set to 0, and I record an audio part triggered by a midi region, the rendered audio is spot-on, no region delay is needed. The only time it's "off" is during playback.

 

I suppose some testing will ultimately give me the answer, however my other conundrum is that using the loopback/ping test gives me a different offset every time I push the ping button, so I can't just pick a value and set the recording delay. Something is screwy.. I'm looking into the possibility of dumping both audio interfaces in favor of a single, nice one, like RME or TC studio konnekt, but was just wondering if anyone had some insight... I appreciate your time!

[ski]

I think you're confusing the terminology. Or the terminology is confusing.

 

Recording = external signal being recorded as audio. Guitar, external MIDI synth, any signal that's being generated external to Logic and which has to be digitized by your interface (A to D conversion). The recording delay has a bearing on the placement of that recording.

 

Bouncing = "rendering" a virtual track where the sound comes from within Logic or another sound source generated from within the computer itself. Recording delay has no bearing on this.

[robertg]

I think you're confusing the terminology. Or the terminology is confusing.

 

Recording = external signal being recorded as audio. Guitar, external MIDI synth, any signal that's being generated external to Logic and which has to be digitized by your interface (A to D conversion). The recording delay has a bearing on the placement of that recording.

 

Bouncing = "rendering" a virtual track where the sound comes from within Logic or another sound source generated from within the computer itself. Recording delay has no bearing on this.

 

It's not confusing.. that was just a bit of a slip up, I used the word rendering instead of recording..

 

Perhaps I am asking the wrong question. I'm looking for a way to reduce roundtrip latency and I thought adjust recording delay might help. I don't think it's possible without lowering the buffer size (I am at 256, any less = cracks on complicated projects)... or changing my audio interface. Logic says the resulting roundtrip latency is 18.7ms.. I have to double that in the region delay to get everything to line up because I use two separate interfaces.

 

What I don't understand, is why no alignment is necessary after recording the midi. Maybe logic is aware of the latency and is accounting for it automatically?

[ski]

Let's clarify even more... You're talking about recording the audio generated from external MIDI synths and not plugins, correct?

[robertg]

Let's clarify even more... You're talking about recording the audio generated from external MIDI synths and not plugins, correct?

 

Right, no plugins at all..

[ski]

Right. That's what I thought.

 

So at the risk of stating the obvious, recording audio from (external) synths is no different from recording any other external audio signal. Therefore, the recording delay is going to be of concern to you and needs to be calibrated. But of course, that's "if that's even possible" considering the variations you reported.

 

The fact that you're running two different audio devices is going to compound your problems when trying to figure all of this out. For starters, and indeed, the Onyx's drivers will introduce the recording delay that needs to be compensated for. But doing a ping test when both the Onyx and the TC are involved, AND, if indeed one of their drivers doesn't generate a consistent amount of latency, you're kinda sunk.

 

Going to suggest that you take the TC out of the loop entirely and try a ping test (and, optionally, an audio loopback test per my instructions here) with just the Onyx. See if you can get consistent results over the course of several tests. If you can't get consistent results then you know that the Onyx's drivers are flaky and can't really be used reliably to record anything unless you don't mind a randomly variable amount of slop in the timing of your parts.

 

If the Onyx proves to be stable, however, then you know the culprit is with the TC. Regardless, however, IMO your setup is too complicated for your own good (), although your reasons for configuring it that way in the first place is understandable.

[robertg]

Right. That's what I thought.

 

So at the risk of stating the obvious, recording audio from (external) synths is no different from recording any other external audio signal. Therefore, the recording delay is going to be of concern to you and needs to be calibrated. But of course, that's "if that's even possible" considering the variations you reported.

 

The fact that you're running two different audio devices is going to compound your problems when trying to figure all of this out. For starters, and indeed, the Onyx's drivers will introduce the recording delay that needs to be compensated for. But doing a ping test when both the Onyx and the TC are involved, AND, if indeed one of their drivers doesn't generate a consistent amount of latency, you're kinda sunk.

 

Going to suggest that you take the TC out of the loop entirely and try a ping test (and, optionally, an audio loopback test per my instructions here) with just the Onyx. See if you can get consistent results over the course of several tests. If you can't get consistent results then you know that the Onyx's drivers are flaky and can't really be used reliably to record anything unless you don't mind a randomly variable amount of slop in the timing of your parts.

 

If the Onyx proves to be stable, however, then you know the culprit is with the TC. Regardless, however, IMO your setup is too complicated for your own good (), although your reasons for configuring it that way in the first place is understandable.

 

Yes, I agree with your conclusions. At first it was to save some money and an analog mixer seemed to be the only way to get 12 channels in, every other audio interface at that price point stopped at 8.. the Studio Konnekt 48's have dropped somewhat in cost, though. I'll definitely do the tests with just the Onyx and will probably put it on ebay soon.

 

I'm still not sure why I don't need to adjust anything after it's recorded. But during the audition phase, the gap is definitely wide enough to be heard at roughly 1/96th note which is way, way more than the 1-60 samples people are talking about in this thread....

 

By the way the Onyx has no drivers, it just uses core audio.

[ski]

It's been quite a while since I've been involved in a conversation about an interface that uses CoreAudio's built-in FW audio drivers. But the very thing that got me interested in this subject many years ago was a post on another forum where people were complaining left and right about the flakiness of Apple's native CoreAudio FW drivers; they were exhibiting exactly the kind of variable latency that you're describing.

 

Now, to what you're saying about recording the audio from MIDI synths and having to adjust the timing... You wrote:

 

What's really curious about this is that my recordings are spot-on with the recording delay set to 0 samples. it's only when playing back the unrecorded midi (audio input on an aux) that I have to adjust delay to -37.

 

If I accidentally record without setting the delay back to 0, all is fine if I adjust the recorded part to +37.

 

Of the values of -37 and +37 you wrote about, what values are we talking about? 37 samples or 37 ticks or 37 milliseconds? And where are you making these adjustments?

[robertg]

It's been quite a while since I've been involved in a conversation about an interface that uses CoreAudio's built-in FW audio drivers. But the very thing that got me interested in this subject many years ago was a post on another forum where people were complaining left and right about the flakiness of Apple's native CoreAudio FW drivers; they were exhibiting exactly the kind of variable latency that you're describing.

 

Now, to what you're saying about recording the audio from MIDI synths and having to adjust the timing... You wrote:

 

What's really curious about this is that my recordings are spot-on with the recording delay set to 0 samples. it's only when playing back the unrecorded midi (audio input on an aux) that I have to adjust delay to -37.

 

If I accidentally record without setting the delay back to 0, all is fine if I adjust the recorded part to +37.

 

Of the values of -37 and +37 you wrote about, what values are we talking about? 37 samples or 37 ticks or 37 milliseconds? And where are you making these adjustments?

 

It's ticks.. I thought it was ms before but went and made sure, seems easy to confuse the two since logic does not tell you which mode is selected.. 37 ticks = 19.2 ms which is very close to the 19.8 logic reports as the roundtrip latency.

 

Whenever I record or create a midi region, I change it to -37 in the inspector in order to cause the audio to be played early.

 

If I forget to set it back to 0 before recording to audio, then I have to offset the resulting audio region +37 to keep alignment.

 

Interesting about the OS X firewire driver, I thought I was being so clever buying this analog mixer, seems it's looking more and more like I need to upgrade.

 

I'd like to get away from firewire and go to PCI-E to reduce the latency even more, if possible. Interfaces w/ 12 ports that are under $2000 don't seem to be very common.

[ski]

It's ticks.. I thought it was ms before but went and made sure, seems easy to confuse the two since logic does not tell you which mode is selected.. 37 ticks = 19.2 ms which is very close to the 19.8 logic reports as the roundtrip latency.

 

Ready for more?

 

The value in milliseconds of a single tick varies with the tempo. Logic has a MIDI resolution of 960 ticks per quarter note. At 120 BPM, one tick lasts .521 milliseconds. At 60 BPM, one tick has a duration of twice that -- 1.04 milliseconds. So unless you're always recording music at the same tempo (unlikely, I'm assuming), and you want to use a region-based delay offset (which is what you're using) that approximates the amount of timing offset you're incurring, you can't go by tick values UNLESS you display ticks as milliseconds. This can be changed in the Arrange page "View" menu. Still, depending on the tempo you're working at, the chances of finding a value that's close to the value of your offset will occur only by random chance.

 

And if you're working with a tempo map of any kind, the tick value will change dynamically with each tempo change.

 

Meanwhile... the recording delay value is expressed in samples.

 

So it's for these reasons that I'm confused about your numbers, and... dare I say it... I think you should be too !