![]() ![]() You are inserting a SPAT send plugin in LAP mode on a strip after other plugins that may introduce latency. In the case of Pro Tools, the delay compensation happens down the line between these tracks and the final bus they feed. That being said, when you are extracting the audio from the SPAT plugin Local Audio Path (LAP), the delay compensation is not taken into consideration in regards to all the other objects you have in the session. Even if a DAW A sounds different than DAW B (and only under arbitrary "complex" conditions, at that), the difference is negligible, and completely subjective anyway.This follows a generic article on Delay and Compensation mechanism,Īs mentioned in different articles, when using audio devices to route to/from SPAT Revolution, Pro Tools is handling the needed delay compensation based on your routing / plugin usage. My point is, without the required data (among other things, the source code of every plugin and DAW involved) this exercise is pretty pointless, unless you simply happen to enjoy it. so-and-so has "golden ears"), but that's almost a different discussion entirely. There is also the appeal to authority (e.g. I'm not saying things like this can't be accounted for, but we definitely aren't accounting for them here. We are operating under the assumption of what we think is "supposed to" happen in a DAW, without actually having certainty of what actually is happening, and how. And it leaves a lot of room for cognitive bias to enter into the mix. This makes scientific rigor much more complicated in this context. We know what we put in and what we get out, and have to make assumptions and inferences based on that limited information. As end users, we don't actually know what's happening inside the black box. They are black boxes for all intents and purposes in the context of this thread.įurthermore, the same sort of thing applies to the actual DAWs themselves. Plugins contribute confounding variables that you cannot account for in these "null tests" without completely reverse-engineering the DSP (for starters). If you really want to find a problem with LogicPro then take a look at AdmiralBumbleBee's recent work, but FWIW, he also found problems with Cubase. If the incoming level is even slightly different it could cause the compressor to do different thingsĪnd on and on. I agree with you that compressors are responding to the input sound and operating different calculations based on the incoming volume. They are merely API interfaces that access the same underlying algorithms and DSP calculations.ĭifferent audio levels of course could render different results, that is a user error or decision, not the fault of the specific daw The difference between VST and AU also makes absolutely Zero point zero sonic difference. They are all sample accurate, un less there is a bug somewhere in some situation, then it should be reported and fixed by the vendor.Īll the major DAW's report themselves as providing sample accurate plugin rendering.the manner of PDC does not matter one bit. If any daw is doing anything other then sample accurate, it should not be used, period. different DAW's may or may not have different methods they use to achieve track synchronization, but the end result in each case should be absolute sample accurate results. That means all tracks playback exactly when they are supposed, accurate to the resolution of a sample. Some of those possibilities, I think are highly unlikely.įor example, delay compensation, why should it make any difference? All major DAW's allegedly perform sample accurate plugin delay compensation. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |