Help! Problem with recording on time

[robertg]

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 !

 

I'm kind of more impressed with the fact that I arrived at ~40 tick offset by pure guesswork and my ear, then I decided to double the roundtrip figure to reach 37.4. It really was an accident that it came so close to the actual correct value because I never went to research ticks vs. samples. Thanks for the info!

 

Maybe it's not that impressive, I guess it's not too hard to figure out how early or late a sound is with enough experience.

 

My friend who owns a Studio Konnekt just told me what his roundtrip latency is, and it's not very much different from my setup. I think the goal now is to find a PCI-E interface.. or maybe I would not gain too much by the effort.. I seem to recall my old PCI m-audio card on the PC to be much less latent.

[ski]

Gowon, be all impressed with yourself LOL! See, back in the day we used to use an astrolabe and a transit to figure out the delay LOL! Those were the days when taking a dual major in music and surveying would pay off

 

Last word... I'd wholeheartedly endorse some kind of PCI-e based audio system for stability. That's not to say that some FW-based interfaces aren't just as good. I think you just got "lucky" in that respect

 

Cheer

[triplets]

With my Motu Ultralite I get 2.7 ms roundtrip latency at 44.1k with 32 buffer.

Motu has one of the best firewire drivers out there.

[robertg]

Gowon, be all impressed with yourself LOL! See, back in the day we used to use an astrolabe and a transit to figure out the delay LOL! Those were the days when taking a dual major in music and surveying would pay off

 

Last word... I'd wholeheartedly endorse some kind of PCI-e based audio system for stability. That's not to say that some FW-based interfaces aren't just as good. I think you just got "lucky" in that respect

 

Cheer

 

Thanks. The only thing I wanted to add is, wouldn't it be nice if Logic was aware of the audio round trip delay and automatically delayed midi parts.. I know why this isn't practical because not all midi parts are subjected to the delay (like plugin instruments). However since I use multi-instruments in the environment maybe there should be a delay parameter there for those, or at least a way to hack something together.

 

The external instrument plugin might already delay the parts, however I can't use that because it doesn't compensate properly with UAD plugins. The only way I've found to monitor UAD live is bringing audio in with AUX tracks in the playback/audition phase.

[ski]

Ready for more more?

 

It's not possible to calculate the latency of a MIDI device because the communication of MIDI messages from MIDI source to MIDI destination is asynchronous. So even in the best of situations there is always going to be an average of a 1 millisecond tolerance in the timing, so called "MIDI jitter".

 

And since MIDI is communicated serially, your latency calculation would have to be based on either single notes, or, the first-transmitted note of a chord. But now let's make matters worse... If you're sending MIDI data on multiple channels at once -- you're playing several sounds simultaneously from a multi-timbral synth... I'll stop here to make a correction: it's not possible to play several sounds simultaneously from a multi-timbral MIDI device! If you had a 16-part multi-timbral synth and sent a two note chord on each channel, the timing between the sound of the first and last notes received would be around 32 milliseconds (1 ms per note). So sure, I understand, you want to calculate latency to compensate for timing discrepancies. But in this case, which channel would you use as the benchmark? Well, you don't even really have a choice, because users have no control or means to prioritize which channels' data are prioritized when being transmitted to a multi-timbral synth.

 

If MIDI messages were transmitted with a protocol that included a clock (like word clock), then it would be possible (theoretically) to do a ping test to obtain an accurate latency calculation. But there are additional wild cards: the response time of MIDI devices to producing a sound upon receiving a complete note message is highly variable!

 

Sigh...

[robertg]

Ready for more more?

 

It's not possible to calculate the latency of a MIDI device because the communication of MIDI messages from MIDI source to MIDI destination is asynchronous. So even in the best of situations there is always going to be an average of a 1 millisecond tolerance in the timing, so called "MIDI jitter".

 

And since MIDI is communicated serially, your latency calculation would have to be based on either single notes, or, the first-transmitted note of a chord. But now let's make matters worse... If you're sending MIDI data on multiple channels at once -- you're playing several sounds simultaneously from a multi-timbral synth... I'll stop here to make a correction: it's not possible to play several sounds simultaneously from a multi-timbral MIDI device! If you had a 16-part multi-timbral synth and sent a two note chord on each channel, the timing between the sound of the first and last notes received would be around 32 milliseconds (1 ms per note). So sure, I understand, you want to calculate latency to compensate for timing discrepancies. But in this case, which channel would you use as the benchmark? Well, you don't even really have a choice, because users have no control or means to prioritize which channels' data are prioritized when being transmitted to a multi-timbral synth.

 

If MIDI messages were transmitted with a protocol that included a clock (like word clock), then it would be possible (theoretically) to do a ping test to obtain an accurate latency calculation. But there are additional wild cards: the response time of MIDI devices to producing a sound upon receiving a complete note message is highly variable!

 

Sigh...

 

Sometimes, I really wish that I had the opportunity to get my start in a completely analog studio. Sure you might have to patch cables around among other inconveniences, but I would trade all of that, give up every plugin to have everything spot-on and instant with no latency. Just wasn't possible with what all that stuff costs

 

Still though, I'd gladly accept an "automatic" 18.7ms midi latency compensation based on audio trip delay that may be 1 or 2 ms off rather than none at all..

[robertg]

Also, I still don't understand why audio timing is always correct after it's recorded? Seems logic is taking the delay into account at that stage, just not during playback.

[ski]

I've been wondering about this myself, and if I have time later I'll post with some thoughts.

[ChrisNinety]

I thought replying to this thread would be better than starting a new one, but please let me know if it would be better if I did start a new thread.

 

Due to problems I'm having with my Onxy 1620i (described in another thread), I rented a Focusrite Scarlett 18i6. During my initial setup, I found that the ping test with the IO plug-in *sometimes* returns different values for the same settings. Most of the time at 44.1 and 128 sample buffer, it measures -17, but sometimes after changing buffer settings and sample rates, it will measure between -8 and -10 at 44./1 / 128 samples. The Mackie that I'm unhappy with right now measures a consistent -47 at 44.1 and 128 samples.

 

I guess it's a ~9 sample difference and probably won't cause a real issue, but, does anyone else see this kind of inconsistent latency with their USB 2.0 interfaces? I was thinking of moving over to USB 2.0 after the problem I've had with the Firewire Mackie, but now I'm wondering if I'm trading one rabbit hole problem (pitch issues due to sample rate inaccuracy) for another (poor timing due to inconsistent latency). I wonder if it's just a symptom of low cost interfaces...maybe they all have their little Achille's heels?

[rureadingmyusername]

I just created an account specifically to thank redlogic and ski. This has been driving me crazy and the ping solution was extremely helpful. Many thanks!