|
Post by Johnkenn on Mar 9, 2019 18:01:56 GMT -6
Buffer size doesn't effect. Same Input delay. Turning off Insert Effects from "UAD REC" to "UAD MON" has no effect either.
|
|
|
Post by Johnkenn on Mar 9, 2019 18:07:30 GMT -6
It's a major issue. I'm sure it's most likely Avid's fault, but UA should be breaking down their doors to fix this.
|
|
|
Post by Johnkenn on Mar 9, 2019 18:29:50 GMT -6
|
|
|
Post by Johnkenn on Mar 9, 2019 18:31:31 GMT -6
So - if you're using Pro Tools and are recording multi-mic recordings and have to use IDC in Console, you're probably going to have to scoot the file back in PTs a certain number of samples.
|
|
|
Post by bigbone on Mar 9, 2019 18:48:56 GMT -6
That isn't a good news .lot's of PT-UAD user who tracks multi mic set-up.!!!
|
|
|
Post by Johnkenn on Mar 9, 2019 19:02:10 GMT -6
Wow - I'm not trying to cause a problem or a panic here, but what a pain in the ass. It's not going to be a big deal for me because I rarely record more than stereo in...but this is a pretty big deal for multitrackers that use Pro Tools.
|
|
|
Post by Johnkenn on Mar 9, 2019 19:02:47 GMT -6
Maybe I'm screwing something up...
|
|
|
Post by drumrec on Mar 10, 2019 3:21:21 GMT -6
Thanks for taking the time to check out the problem @johnkenn Would be good if someone from the UA could sort out the problem.Please, can somone from UA shime in here Drew @ UAThanks /H
|
|
|
Post by Johnkenn on Mar 10, 2019 9:27:39 GMT -6
OK - just added an 1176 and Pultec to the channel, recorded with LONG on and it's the exact same 30 samples delayed. So they are delayed by a set amount for short, medium and long. Couldn't you just pull all the drum tracks (or whatever you're recording with IDC on) 30 samples to the left and be fine? Kind of a PITA, though. There's no need for that. There's a record offset in every DAW I've used. My Burl takes 36 samples longer than the RME ADA....so, I keep it at 36 sample offset. It's different on the little Tascam USB thing I use on the Macbook--but, point is, there's always a way to code a manual offset. I measure it at the only sample rate I'm going to care about....and have it on a post it on those ADCs. And dragging as fix is bad because the timestamp on the recording is wrong. so, if you accidentally move it--or want that in another app to work with....the timestamp is wrong. So, unless you're planning on always remember that take needs to come back 30 samples...anyway--if you'll set the record offset in the DAW engine itself, it will account for that in the timestamp. For a single mic, I would leave this OFF. There's no advantage in having it on. The reason you turn it on is because 30 samples or handfuls of samples time difference in the mics on a drum kit is audible. When you leave it off and record a drum kit--those mics will all be delayed by different amounts...thus sound be f'd up....and maybe more importantly will change as you change UA plug ins. Their setting for a second compensation engine is so that it can send those all (apparently 30 samples) late but relatively the same time so YOU CAN set the 30 sample offset in your DAW and everything's tight as tits. I would think if you tag Drew he could probably provide the basic values to plug in if it's not just in the manual. It's in the VST Engine settings in Cubase...in the Audio Setup of Mixbus....I don't remember if it's in the global or project audio settings in LPX, but it's there....and you need to know how to use it. I would think they would want their users properly using these features rather than getting all worked up because they don't understand how/why features are there. Thanks, popmann What’s the best way to measure this stuff? I guess I’m just now realizing there are delays caused by conversion...really never occurred to me. Are we talking such small amounts that it is unnoticeable or could this really add up in sessions and cause phasing issues? Add on top of that if Pro Tools and UAD IDC aren’t compensating correctly it would add even more delay. I guess what I’m asking is this - is 30 samples something that should cause a three page thread?
|
|
|
Post by damoongo on Mar 10, 2019 10:16:43 GMT -6
I guess what I’m asking is this - is 30 samples something that should cause a three page thread? In a word: Yes. (if this is indeed happening.) 30 samples is over half a millisecond when working at 48khz. You very likely wouldn’t notice this on an individual element. But you certainly would notice it if multiple micing a single source and one of the inputs was 30 samples delayed.
|
|
|
Post by Johnkenn on Mar 10, 2019 10:59:38 GMT -6
It’s definitely happening as evidenced by the video.
|
|
|
Post by indiehouse on Mar 10, 2019 11:05:07 GMT -6
It’s definitely happening as evidenced by the video. Has this always been a thing with the Apollo? Or just on the new MKIII?
|
|
|
Post by Johnkenn on Mar 10, 2019 11:37:46 GMT -6
Always
|
|
|
Post by Johnkenn on Mar 10, 2019 11:39:23 GMT -6
Well, maybe this version of the driver is buggy...can’t confirm it except on PT 2018.12 and the latest UAD Driver. Maybe someone else can do the same test?
|
|
|
Post by Johnkenn on Mar 10, 2019 11:42:03 GMT -6
Also - I think people have been saying “it’s really not zero latency” for years...but I honestly just didn’t understand. I thought they were talking about playback. But if you think about it, whenever you add a plug on anything, there’s going to be latency. Of course, UAD IDC is supposed to correct this, but it doesn’t seem to be working in PTs.
|
|
|
Post by Martin John Butler on Mar 10, 2019 12:02:51 GMT -6
Does it work in Logic?
|
|
|
Post by dankin on Mar 10, 2019 12:10:08 GMT -6
This is all interesting for sure. I'll try some test on my setup. I've had a few times when I felt like the playback was late when using more than 1 plugin in the Apollo. I generally keep my Apollo set to short, as I don't normally stack many plugins with it, I mainly use the API eq's for drums, in the same way I used my real ones. But I've occasionally needed to set it to medium. I know you can set a record offset manually in PT, but unless somethings changed, that offset is also tied to the buffer PT is set at. I've encountered this with VI's in PT in the past, where you would record it to a audio track (this was before commit) and something that was 100% quantized would be late on the grid. The amount it was late changed based on the buffer setting. In this case it seems something is broken between the Apollo driver and PT, but maybe not. It may just be PT and 3rd party interfaces not communicating properly. I personally have a bit of a love/hate thing with the Apollo and PT. This is probably more PT fault than the Apollo, but I've yet to fall in love with the workflow. I think it works better for simple setups, with one person at a time overdubbing. In the context of a band playing, I find it to be cumbersome.
|
|
|
Post by popmann on Mar 10, 2019 13:14:57 GMT -6
I refuse to believe PrTools doesn't have a manual record offset....which would mean you measure the latency once....and you plug that in whenever you want to turn on UA's compensation engine that protools isn't working with....
It's how you handle ANY third party ADA compensation....you're telling me that you've looked at it's not there? Or you don't understand the significance of it?
You measure it--say it's 30 samples you need to "slide things back"....and you plug in -30samples into the manual record offset. It will place everything thirty samples earlier. There's a bigger significance that it just being easier (but it's that too)--when yo used that your recorded timestamps are RIGHT....if you just slide stuff back on playback, the timestamp is wrong. There are ways to correct for that TOO....but, wouldn't it make more sense to just tell PT to have the manual offset and call it a day? Sure--it's super slick that UA dynamically changes reported latency in their driver....and it would be cool if they worked with Avid, but Apple/Apogee/UA are kind of the competition for Avid....so, is that likely? I dunno--put pressure on them and see, I guess. But, in the mean time--use the manual offset--problem solved.
|
|
|
Post by dankin on Mar 10, 2019 13:29:12 GMT -6
|
|
|
Post by Johnkenn on Mar 10, 2019 14:10:05 GMT -6
I refuse to believe PrTools doesn't have a manual record offset....which would mean you measure the latency once....and you plug that in whenever you want to turn on UA's compensation engine that protools isn't working with.... It's how you handle ANY third party ADA compensation....you're telling me that you've looked at it's not there? Or you don't understand the significance of it? You measure it--say it's 30 samples you need to "slide things back"....and you plug in -30samples into the manual record offset. It will place everything thirty samples earlier. There's a bigger significance that it just being easier (but it's that too)--when yo used that your recorded timestamps are RIGHT....if you just slide stuff back on playback, the timestamp is wrong. There are ways to correct for that TOO....but, wouldn't it make more sense to just tell PT to have the manual offset and call it a day? Sure--it's super slick that UA dynamically changes reported latency in their driver....and it would be cool if they worked with Avid, but Apple/Apogee/UA are kind of the competition for Avid....so, is that likely? I dunno--put pressure on them and see, I guess. But, in the mean time--use the manual offset--problem solved. So the Burl has a 36 sample latency from just conversion...how do you properly measure a converter’s latency?
|
|
|
Post by popmann on Mar 10, 2019 14:46:52 GMT -6
The same thing you're doing. Analog loop out and back in--measure the difference. Plug that difference in--loopback again, and it should line up.
The 36 samples is versus the RME. It's not 36 longer than everything. You have to run the loopback. The Burl is 14 samples on the Tascam USB thing--as example. And that's all linked to sample rate. So, probably the 36 at 88.2 is 72 at 44.1....you know?
edit: use something percussive...click track if there's one in the project is ideal...and if you have a spare IO in your system, you can just leave that cable plugged in...the REAL test of how good the compensation engine is working is to have a mixer full of all kinds of latent plug ins (like anything UA will do) on busses....tracks...master...you know--a nearly finished mix--TAKE THAT and test the loop. My experience says Cubase will be right on...ProTools Native, Reaper, and Logic will be "in the ballpark". It's been a long time since I tested ProTools and Reaper, though-to be fair to them.
|
|
|
Post by popmann on Mar 10, 2019 14:52:32 GMT -6
And no--I see the earlier question....30 samples won't likely cause a three page thread or effect the groove. UA's compensation is likely larger than that and/or Avid THINKS it is....it WILL cause mic to mic issues in Console (and thus also the recordings) itself. I do a LOT of stuff I just call good hygiene. I don't know that I care about the 36 samples....but, I believe in stuff being right. I'm not sure how much difference I hear I na lot of things that I'm simply told by people who know more than me about X are true. Unless it's a big hassle, I just do what I'm supposed to do....the 36 samples makes it sample accurate and there's never a reason for anyone to question the timing of that engine....you know? I don't mess with stuff after recording unless-well, unless I DO....but....I mean, I don't believe things like the timeline of a multitrack is like horseshoes. Plenty of time to monkey with it later if you WANT to....
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 10, 2019 15:26:07 GMT -6
Hey John,
first post here, so HI first of all!
I had a similar problem on my machine with PT and an Apollo Twin Duo. Depending on the sample rate I would get a delay in the recording like you are experiencing. After months of trouble shooting this error could be reproduced by Avid as being an odd bug in combination with my MacBookPro from 2014. Until now Avid wasn’t able to get rid of the bug. But since a couple of months a workaround works for me: Try disengaging the „Ignore Errors“ preference. Not sure this works for you, but worth a try. I know how frustrating these kind of odd bugs are.
Hang in there!
|
|
|
Post by Johnkenn on Mar 10, 2019 16:35:44 GMT -6
Hey John, first post here, so HI first of all! I had a similar problem on my machine with PT and an Apollo Twin Duo. Depending on the sample rate I would get a delay in the recording like you are experiencing. After months of trouble shooting this error could be reproduced by Avid as being an odd bug in combination with my MacBookPro from 2014. Until now Avid wasn’t able to get rid of the bug. But since a couple of months a workaround works for me: Try disengaging the „Ignore Errors“ preference. Not sure this works for you, but worth a try. I know how frustrating these kind of odd bugs are. Hang in there! Fantastic! Thanks so much I’ll try it.
|
|
|
Post by Johnkenn on Mar 11, 2019 11:11:23 GMT -6
Apparently, I didn't have ignore errors checked. But I guess Pro Tools has never compensated converter delay for third party interfaces. Add on top of that it's not working correctly with UAD IDC. I've seen complaints about this, but honestly didn't really get it. There is no way to set an input offset for all audio in Pro Tools. Looks like I'll be heading to Cubase. www.gearslutz.com/board/avid-pro-tools/1146397-protools-11-12-printing-latency.html
|
|