|
Post by schmalzy on Apr 10, 2019 20:11:44 GMT -6
Just a quick heads-up: Reaper seems to have no problem adjusting to the IDC change. The readout in Reaper telling me what my current latency is reacts and changes as soon as I change the IDC. If Apollo Console isn't reporting, Reaper must be regularly polling the roundtrip latency or something. I do believe PT is the only DAW that doesn't react dynamically. The thing that annoys me most about Pro Tools: it's not hard to implement this sort of thing. When I was a first year computer science major I had to build a program that constantly polled for a change in the system. Hell, if StudioOne can do it (a DAW whose developers and parent company thought having two numbers consecutively in the name - "One" and a version number - was a good idea), ANYONE can do it!
|
|
|
Post by sirthought on Apr 11, 2019 15:14:41 GMT -6
I believe RTL Utility is available for Mac. I know it is for PC. Looks like it's Windows only according to the website. But I never even knew that existed, so interesting product option. Would be great if UA could offer something similar for Mac and Windows.
|
|
|
Post by peterhess on Apr 11, 2019 21:29:08 GMT -6
Very big thanks to all of you taking this head on and sharing for everyone. Bet I’m not the only one with nothing salient to add to the conversation but really reaping the benefits of your close attention.
|
|
|
Post by Drew @ UA on Apr 12, 2019 10:27:34 GMT -6
I believe RTL Utility is available for Mac. I know it is for PC. Looks like it's Windows only according to the website. But I never even knew that existed, so interesting product option. Would be great if UA could offer something similar for Mac and Windows. I have a BETA of a Mac version. I guess they never finished it. Loopback tests are simple enough to do. RTL Utility automates this process for buffers and generates reports. UA is a small company (many don't realize how small) and doing something like this would take a programmer away from something else FYI.
|
|
|
Post by sirthought on Apr 12, 2019 13:16:54 GMT -6
Maybe it would take a developer away, but since this topic seems to come again with all sorts of platforms and with different DAWS it seems it would help UA put the questions to an end somewhat. That seems worth it to help your customers know what they are dealing with in their production environment.
|
|
|
Post by Johnkenn on Apr 12, 2019 17:12:35 GMT -6
Or make your own DAW
|
|
|
Post by mulmany on Apr 12, 2019 18:07:33 GMT -6
Or make your own DAW RGO DAW! Then you could get that new 4Runner! I'll take one as payment for the idea!
|
|
|
Post by damoongo on Apr 13, 2019 1:48:27 GMT -6
UA is a small company (many don't realize how small) and doing something like this would take a programmer away from something else FYI. Ok, but I’m not really buying this. The income from plugins must be staggering! (Even more so if it’s such a small company.) I understand that it might be costly to license the trademarks and names of gear from the manufacturers who actually designed and built and serviced and supported the hardware that made them legendary. But I’m sure you could find the resources to invest in a simple tool like RTL checking if you really wanted to. Of all the companies to claim lack of resources, I would not expect UA. But I’m not sure offering such a tool would be a wise move. It opens up the tiniest bit of “doubt” in the user’s mind for what is otherwise an “it just works” system. And it appears that this latency reporting issue is Avid’s mistake anyway. And like you said, loopback tests are simple to do. I think it was great to see you take it seriously and get to the bottom of it and share your findings here on this forum. Perhaps now that there’s a template, your team should quickly run those same tests on each new major DAW update to double check for problems and post any “known issues” with the others on the UA site. I really appreciated that you kept us in the loop here.
|
|
|
Post by christopher on Apr 13, 2019 2:11:23 GMT -6
Looks like it's Windows only according to the website. But I never even knew that existed, so interesting product option. Would be great if UA could offer something similar for Mac and Windows. I have a BETA of a Mac version. I guess they never finished it. Loopback tests are simple enough to do. RTL Utility automates this process for buffers and generates reports. UA is a small company (many don't realize how small) and doing something like this would take a programmer away from something else FYI. What software is more important than software issue causing a musician to play out of time? E: not picking on UA exclusively here, incredibly amazing musicians who self record over the past 15 years bought cheap native PT setups and suffered these misalignment issues. I can’t help but think the grid music is the consequence of nobody thinking they can nail a take anymore.
|
|
|
Post by drumrec on Apr 13, 2019 3:22:35 GMT -6
Perhaps now that there’s a template, your team should quickly run those same tests on each new major DAW update to double check for problems and post any “known issues” with the others on the UA site. It is such a vital function that fails the whole concept if it does not work properly. +10 on your post. Thanks for heads up here at RGO Drew @ UA appreciated KR /Hansson
|
|
|
Post by Drew @ UA on Apr 13, 2019 8:44:59 GMT -6
We test these DAWs: help.uaudio.com/hc/en-us/articles/206501723-DAW-Compatibility-This issue is a PT specific bug that Avid will need to fix. Hopefully they'll do so quickly. Again, the RTL Utility just automates a very simple loopback test at various buffers. Thanks for the feedback and support, it's appreciated.
|
|
|
Post by christopher on Apr 13, 2019 12:48:43 GMT -6
It is nice that UA does look into and address the issues. Its more than some other brands will do.
I guess that’s why I switched to reaper. At first it was just to track, but then I started doing some mixing, eventually I stopped opening PT. I was soo upset at Avid, because it’s obvious they either: purposely wanted people to fail, or the software was so badly written they didn’t know how to fix it.
So when clients would ask, I tell them I use an advanced form of of protools called Reaper. At this point protools is just a generic term for DAW. No questions are asked after that.
|
|
|
Post by Johnkenn on Apr 13, 2019 13:11:43 GMT -6
Yeah, I've pretty much just decided to commit to Cubase when recording my own stuff.
|
|
|
Post by indiehouse on Apr 13, 2019 15:28:35 GMT -6
Yeah, I've pretty much just decided to commit to Cubase when recording my own stuff. Hey, I kinda fell out of the loop on this, sorry. So this is confirmed then that when tracking with PT, new tracks are not recorded in time? Is this only on Apollo interfaces? Or does it include other third party interfaces?
|
|
|
Post by Johnkenn on Apr 13, 2019 21:08:56 GMT -6
Yeah, I've pretty much just decided to commit to Cubase when recording my own stuff. Hey, I kinda fell out of the loop on this, sorry. So this is confirmed then that when tracking with PT, new tracks are not recorded in time? Is this only on Apollo interfaces? Or does it include other third party interfaces? Well, yes. When the “Ignore Errors” thingy is checked, it (Pro Tools) can (and does) record late. During this little odyssey, I also realized that there’s also converter latency...and although this is pretty tiny, it could be a real pain with drums and overdubs at different times. To top it off, PT doesn’t have a setting where you can adjust for converter latency. I measured mine with a loop back test, and entered the difference in a setting within Cubase to compensate for input latency.
|
|
|
Post by mulmany on Apr 14, 2019 7:23:25 GMT -6
I double checked my settings last night since I finished upgrading my Mac. The un compensated record offset is 42 samples or 0.44 msec. This was at 96k using a Motu 16a over thunderbolt.
|
|
|
Post by indiehouse on Apr 14, 2019 8:38:30 GMT -6
I double checked my settings last night since I finished upgrading my Mac. The un compensated record offset is 42 samples or 0.44 msec. This was at 96k using a Motu 16a over thunderbolt. This is my exact setup on my current project @ 96k. Forgive my ignorance, but should I be concerned about a 42 sample offset when tracking? Also, what about HW inserts? I know PT has ADC, but the converter latency would still be present, correct? Will 42 samples cause phasing issues?
|
|
|
Post by ragan on Apr 14, 2019 8:55:57 GMT -6
I double checked my settings last night since I finished upgrading my Mac. The un compensated record offset is 42 samples or 0.44 msec. This was at 96k using a Motu 16a over thunderbolt. This is my exact setup on my current project @ 96k. Forgive my ignorance, but should I be concerned about a 42 sample offset when tracking? Also, what about HW inserts? I know PT has ADC, but the converter latency would still be present, correct? Will 42 samples cause phasing issues? If you’re on PT Native, you have to manually enter delay figures for HW inserts. PT doesn’t do it automatically. It’s also buffer size dependent.
|
|
|
Post by Johnkenn on Apr 14, 2019 9:06:01 GMT -6
If you record everything and everything is that amount late, it’s not a big deal...add in the issue with Apollo IDC and Ignore Errors it made it worse. If you’re tracking overdubs from a different place it could be weird.
I use a lot of virtual instruments, so when the beats are right on and everything else is off it becomes an issue for me.
|
|
|
Post by indiehouse on Apr 14, 2019 10:54:43 GMT -6
This is my exact setup on my current project @ 96k. Forgive my ignorance, but should I be concerned about a 42 sample offset when tracking? Also, what about HW inserts? I know PT has ADC, but the converter latency would still be present, correct? Will 42 samples cause phasing issues? If you’re on PT Native, you have to manually enter delay figures for HW inserts. PT doesn’t do it automatically. It’s also buffer size dependent. Really? I could have sworn I measured that once and it was correct. Hmmm..gonna have to take another look. I hate dealing with this stuff. It sucks time away from being creative. Measuring delay compensations is definitely not right brain stuff.
|
|
|
Post by ragan on Apr 14, 2019 11:15:26 GMT -6
If you’re on PT Native, you have to manually enter delay figures for HW inserts. PT doesn’t do it automatically. It’s also buffer size dependent. Really? I could have sworn I measured that once and it was correct. Hmmm..gonna have to take another look. I hate dealing with this stuff. It sucks time away from being creative. Measuring delay compensations is definitely not right brain stuff. Duplicate a track and put a HW insert on the dup and you’ll hear how off it is. It is indeed a hassle.
|
|
|
Post by kcatthedog on Apr 14, 2019 11:35:54 GMT -6
One of the many things I prefer about logic: it’s utility I/o plug in with built in rtl ping.
|
|
|
Post by mulmany on Apr 14, 2019 15:56:58 GMT -6
I double checked my settings last night since I finished upgrading my Mac. The un compensated record offset is 42 samples or 0.44 msec. This was at 96k using a Motu 16a over thunderbolt. This is my exact setup on my current project @ 96k. Forgive my ignorance, but should I be concerned about a 42 sample offset when tracking? Also, what about HW inserts? I know PT has ADC, but the converter latency would still be present, correct? Will 42 samples cause phasing issues? Buffer size does not effect the HW insert delay comp, only Sample rate does. In the I/o setup enter .44 msec for each insert. If I remember correctly, you are using a two interfaces avb'ed together. You will need to do a separate comp for the 2nd unit.
|
|
|
Post by ragan on Apr 14, 2019 16:07:51 GMT -6
This is my exact setup on my current project @ 96k. Forgive my ignorance, but should I be concerned about a 42 sample offset when tracking? Also, what about HW inserts? I know PT has ADC, but the converter latency would still be present, correct? Will 42 samples cause phasing issues? Buffer size does not effect the HW insert delay comp, only Sample rate does. In the I/o setup enter .44 msec for each insert. If I remember correctly, you are using a two interfaces avb'ed together. You will need to do a separate comp for the 2nd unit. Buffer size does affect the HW insert delay over here. When I run a loopback test and calculate a figure, if I have to toggle the buffer (which happens often for me with PT) the delay compensation is no longer phase coherent (I run parallel HW drum bus). If I switch it back to the buffer at which I calculated the delay, it's back to coherent.
|
|
|
Post by mulmany on Apr 14, 2019 16:11:09 GMT -6
Buffer size does not effect the HW insert delay comp, only Sample rate does. In the I/o setup enter .44 msec for each insert. If I remember correctly, you are using a two interfaces avb'ed together. You will need to do a separate comp for the 2nd unit. Buffer size does affect the HW insert delay over here. When I run a loopback test and calculate a figure, if I have to toggle the buffer (which happens often for me with PT) the delay compensation is no longer phase coherent (I run parallel HW drum bus). If I switch it back to the buffer at which I calculated the delay, it's back to coherent. Something sounds off about that... 64 - 1024 buffer mine stays at .44 msec.
|
|