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. You need to setup your hardware insert delays in the i/o setups page.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. In short, I can't get delay compensation to ever turn off (in regards to analog throughput) once it's been turned on. The only way to get it back to 91 is to either save the session with DC off, and re-open it, or change the H/W buffer to a different setting (also with D/C off). turn Delay Compensation back off, and the latency remains 219 samples. Switch on Delay Compensation, and the number changes to 219 samples. Throughput latency shows to be 91 samples. I send this to analog output 5 (DIGI 192), and re record it to track 2 using analog input 1. The session has 2 tracks, and no plugins. I was looking at throughput latency and found an interesting issue.Ĭompensate after record pass both OFF (for testing purposes)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |