|
Avid Pro Audio CommunityHow to Join & Post • Community Terms of Use • Help Us Help YouKnowledge Base Search • Community Search • Learn & Support |
#41
|
|||
|
|||
Re: Manual Delay Comp Problem
Sorry, but this answer is wrong. Frankly, I expected more from digi.
How many times do we need to say - we are talking about INPUTS not INSERTS? Or have you found some way to record thru inserts? also, the buffer setting selections on my RME are in samples not milliseconds. Besides the fact that the HW Insert Comp rounds millisecs to 2 decimal points - introducing rounding errors. Sonar, Cubase, Nuendo all get this right. PT9 does not. Like it or not - its a bug - or at best a missing capability. I was looking forward to using PT but if this problem isn't corrected, the product is useless. And the level of denial around here is ridiculous. |
#42
|
|||
|
|||
Re: Manual Delay Comp Problem
vans316:
you have hit the nail on the head with what this topic is about. unfortunately, everyone keeps thinking the problem is insert compensation. The answer to your question, at the moment, is *no*, there is no way to have PT shift the overdub to align with the previous track. Despite the fact that other DAWs handle this correctly, so far all I've heard is "there is no bug" and then we're directed to the hw inserts page of the manual. |
#43
|
|||
|
|||
Re: Manual Delay Comp Problem
Quote:
OP was refer. to Recording Overdubs. NOT INSERTS... OP's topic IS very viable and SHOULD be fixed for third PTY interfaces. Why dont you just add a feature like the HW Delay so that a usr can manually enter a WISHED for value that EVERY overdub should be advanced in time.... This feature would be great for the many HD users using Apoge interfaces etc... And quite frankly, I dont see how this could be a huge issue. Especially since most other DAWs are already featuring this.
__________________
2016 MacBook Pro Retina | 16GB RAM | 1TB SSD | OS X Latest - PTHD 12 Latest | 4K LG Thunderbolt Display | Logic Pro 10 |
#44
|
||||
|
||||
Re: Manual Delay Comp Problem
Quote:
You don't have to say anything more than once - I get it. Sometimes, though, given the hundreds of DUC posts I'm not able to give every one of them the amount of attention it needs. The comments about someone being surprised that no one from Avid has chimed in is one of the reasons I wanted to at least put something in this thread, though I think, in hindsight, that it was premature. SteveBoker had it right regarding the H/W Insert Delay in this post: http://duc.avid.com/showpost.php?p=1711016&postcount=30 Now, unless I'm mistaken, that should work for you. Yes, I know you're NOT using inserts, but we're just doing this as a workaround. I should have been more clear on that. And, yes, the ability to manually compensate for delays has not been fully implemented yet, for various reasons. One thing I wanted to point out is that delays in interfaces should automatically be compensated for via the ASIO or Core Audio polling that occurs at driver level and the only manual compensation that should be needed is when you have an external device in your recording chain that's inducing additional delays. I did want to point something out, though - you say: Quote:
|
#45
|
||||
|
||||
Re: Manual Delay Comp Problem
Quote:
The only delays that should need to be compensated for are ones that have no way of reporting to Pro Tools directly - hardware inserts or devices in the recording chain. Most analog devices have zero delay and most external digital hardware devices have delays in the order of a few samples. We are aware of the usability problem that is caused by not having user-definable record delay compensation and will look at ways to possibly improve this in the future. HD/TDM with interfaces other than Digidesign/Avid is a slightly different story, since there's no 'open' protocol for devices to be able to report their delays, which is why all the compensation doesn't work properly with Apogee, Lynx, etc. Last edited by DigiTechSupt; 12-02-2010 at 06:23 PM. Reason: Reworded for clarity and proper phrasing. |
#46
|
|||
|
|||
Re: Manual Delay Comp Problem
Sorry if I was a bit gruff, DTS.
Yes, I'm using an RME HDSP 9652. And it reports latency and PT compensates for it correctly. If I loop the ADAT optic out to an ADAT input (no DA-AD) everything is perfect. The problem is, I have a Focusrite Pre-amps with internal A/D cards and they are connected to the RME via optic (ADAT) lines. The RME has no way of knowing the latency of the Focusrite pre-amps (ie their A/D converter buffers) so it only reports its own latency. But I can measure it using the loopback technique. That measurement is in samples - the size of the buffer causing the latency. It stays the same regardless of sample rate because it is a fixed-size hardware buffer. To be honest, there is also playback latency in my system, and from measuring the (DA->AD) ping loop we cannot tell if the buffers causing delay are in the 'out' or 'in' stage - but since we're interested in the *overall* roundtrip (reported latency + unreported) it doesn't matter. What we care about is being able to time align an overdub sample accurate. I'm not asking for PT to automagically figure out this value. I'm saying we need the ability to (optionally) enter some value in samples to represent this non-reported buffer. We figure out this value doing the loopback ping test through our DA-AD loop and measuring. Others who have done this are getting the same results as myself. Since I'm a computer programmer with some experience in digital audio, I'm guessing digi interfaces have similar 'hidden' buffers. In the case of the M and LE gear, my assumption is the drivers are accounting for the AD and DA latencies because its all "in the same box". In the case of HD systems, I would imagine this information is carried along the midi data between HD cards and front ends like the PRE. The simplest solution is an edit box on the I/O settings input tab allowing the entry (in samples) of additional latency during record. Any recorded tracks would be bumped ahead by that value (actually, drop the fist X samples). For extra credit, PT could disable this transparently when no tracks are playing back (straight record vs overdubbing) since alignment wouldn;t be necessary in this scenario. If you really wanted to nail the feature, an input similar to the HW Insert dialog (but in samples) would be really nice. That would allow you to set record latency on an input-by-input basis. Which would be really cool and very pro-tools-like -Dan |
#47
|
|||
|
|||
Re: Manual Delay Comp Problem
BTW - is any way to rename this thread "Recording Delay Comp Problem" ?
|
#48
|
|||
|
|||
Re: Manual Delay Comp Problem
great to hear
|
#49
|
|||
|
|||
Re: Manual Delay Comp Problem
Quote:
why not just have a field in which one could enter the delay he wishes for. A la the HW Delay page in the I/O Setup. That way the apogees would not need no protocol etc. The user could just enter any given MS value which the regions would be advanced by !
__________________
2016 MacBook Pro Retina | 16GB RAM | 1TB SSD | OS X Latest - PTHD 12 Latest | 4K LG Thunderbolt Display | Logic Pro 10 |
#50
|
|||
|
|||
Re: Manual Delay Comp Problem
I'm glad someone has understood what it is I'm talking about, (WinTaper, Recording overdub delay problem), I thought I was going mad with thinking about different scenarios that didn't exist! The fact is, that 70 samples or 1.6 ms is so small a delay that it doesnt really make a difference in the real world, but considering the investment leap from a 003 set up to HD, to get zero latency, then people will spend thousands to correct a small delay such as this. Having said that, even if I had HD, I would still have the same amount of control room to live room delay so either way, without sorting out a manual recording delay offset in samples there is no need for me to upgrade to HD for this purpose. What would be the point..... Samples would still be late on input.
By the way, I tested a staight audio loop from my outputs to inputs on the 003. Audio track out playing a click, to recored audio track in. No plug ins any where. Recorded audio landed 1 sample after the origional track. Is this correct. Or should it land spot on? Sorry if I'm taking this to the extreme!! Anyone else done this test? |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
HELP!! Bouncing-in-place by recording to new audio tracks - delay comp problem | johnnybigmoose | Pro Tools 9 | 9 | 12-31-2012 01:36 AM |
PT 10.0.0 HD Native Automation Problem with Delay Comp | Chris Trent | macOS | 5 | 01-07-2012 03:04 AM |
Delay Comp problems again, Delay comp is RED but way below limits. | soundeq | Pro Tools TDM Systems (Mac) | 13 | 11-29-2011 12:01 PM |
since cs3 intermittent UAD/Wrapped plugs delay comp problem | crizdee | Pro Tools TDM Systems (Mac) | 9 | 06-16-2009 09:12 AM |
Problem with Delay Comp. and not enough DSP/Time slots... | storm-01 | Pro Tools TDM Systems (Mac) | 0 | 08-16-2007 01:54 PM |