tmoneygetpaid wrote:To establish that there are plugins that have 0-samples latency, I turn your attention to a document compiling the latency spec of various plugins. There are a number that have 0 samples latency.That just means that they do their processing in the same buffer. You still have the latency of the DAW's buffer size. Even if you could reduce that down to theoretical limit you can't calculate an output sample until you have the input sample. That's why you have at least a one sample delay, and more likely 32 or 64 or 128 samples.

tmoneygetpaid wrote: Also, being skeptical of people who have authority is a hallmark of my personality.I haven't seen FM steve arrest anybody...Lately...

tmoneygetpaid wrote:Steve wrote:Stinky Pete says the time constants of the electronic components and slew rates and what not of the analog components in the EQ and console mean that there is a non-zero delay in the analog version of this trick, as well.Right. I mean, I said it first but... as I mentioned, those time constants are on the order of a small phase shift, not an audible delay.Right but what are they? Like, are they on the order of 1/48000? I imagine they're shorter and that you are right, but am wondering if anyone knows the actual numbers to confirm.Apart from all that other stuff I was right about that you think I was wrong about, I can explain that there is a time constant for any network that can be calculated using the component values. I bet there is an online calculator to do it for you.Yep:https://www.digikey.com/en/resources/co ... e-constantSo every filter will have a slightly different phase shift depending on how it is constructed.

tmoneygetpaid wrote:Steve wrote:Stinky Pete says the time constants of the electronic components and slew rates and what not of the analog components in the EQ and console mean that there is a non-zero delay in the analog version of this trick, as well.Right. I mean, I said it first but... as I mentioned, those time constants are on the order of a small phase shift, not an audible delay.Right but what are they? Like, are they on the order of 1/48000? I imagine they're shorter and that you are right, but am wondering if anyone knows the actual numbers to confirm.Apart from all that other stuff I was right about that you think I was wrong about, I can explain that there is a time constant for any network that can be calculated using the component values. I bet there is an online calculator to do it for you.Yep:https://www.digikey.com/en/resources/co ... e-constantSo every filter will have a slightly different phase shift depending on how it is constructed.

steve wrote:projectMalamute wrote:People didn't seem to be picking up on it.Story of my fucking life. Say some simple thing and 28 jagoffs go in circles guessing you're full of shit until they step on the rake you were telling them about.I kid.Oh cmon.You stated a few misconceptions numerous times here as well with the same certainty, namely:*A plugin must necessarily cause latency such that a processed signal will be delayed relative to a "dry" signal*A signal sent to a DAW bus must necessarily be delayed relative to a "dry" / not-bussed signalAnd yet you keep doing this victory dance of correctness in all aspects of comprehension of DSP.Also, being skeptical of people who have authority is a hallmark of my personality. You must know this by now!Steve wrote:Stinky Pete says the time constants of the electronic components and slew rates and what not of the analog components in the EQ and console mean that there is a non-zero delay in the analog version of this trick, as well.Right. I mean, I said it first but... as I mentioned, those time constants are on the order of a small phase shift, not an audible delay.Right but what are they? Like, are they on the order of 1/48000? I imagine they're shorter and that you are right, but am wondering if anyone knows the actual numbers to confirm.

Right, but Steve held that instantiating a plugin would necessarily delay a plugin-processed track relative to the rest of the audio stream. A plugin with 0-samples of latency by definition means this is not the case. Two iterations of the same track, one with a 0-sample latency plugin and one without any plugin, would arrive at a shared destination with, well, 0 samples of latency between them. But yes, they would be delayed by the buffer size, at a minimum.

Right, but the system is more complex than just a single RC filter, isn't it?In addition to the components in the audio path, the console power supply isn't able to respond to current demands instantaneously, and all the active components have limitations (slew rates of op amps). Those are very short, the TL072s in the desks here are about 13V/microsecond, so they can swing from rail to rail in about 2 microseconds, and that's an extreme case. And as bishopdante pointed out there is propagation delay from wires. I imagine there are other factors that delay the audio through its path, as well.So I was asking if anyone measured the delay caused by feeding a signal onto itself. With the complexity of the system, it seems it would be *way* easier to measure than to calculate it. And if anyone has measured it, we could compare it to the ~2 microsecond delay of 1-sample that each feedback in the DAW would have. I restate that I would be surprised if the delays in the analog domain were even remotely comparable to those in the digital- I imagine the analog are much faster. On this point, I didn't hold that you were mistaken.However, on the other two I mentioned that you still insist you were correct about:A simple way to prove that delay compensation acts properly to delay an input signal relative to a bus signal to keep their "arrivals" at a shared destination exactly simultaneous would be to create a session that has a track with a signal generator on an insert, and main output the 2-mix bus; create a send from that audio track to a DAW bus, and create an aux with input set to this bus, and set this aux to output to the same 2-mix bus. If they are simultaneous, when you flip the phase on one, it will completely null the other. I've just done this and it nulls the output to 0 samples.This is the main way that folks do In-The-Box parallel processing, and if delay compensation didn't compensate properly, you wouldn't be able to do this without comb filtering.To establish that there are plugins that have 0-samples latency, I turn your attention to a document compiling the latency spec of various plugins. There are a number that have 0 samples latency.I acknowledge that I was mistaken that there is not an inherent delay in feeding a bus back on itself.

I'm going on about this because there's a semantic tic that keeps getting used as though it were a fact, and it's fun to beat dead horses. Live ones no, that's cruel.A process cannot actually have zero latency because an operation takes time. The speed of operations is determined by the clock of the CPU or whatever coprocessor governs that operation. The term of art "zero latency" means the processing time can be compensated for, usually within a buffer, not that it happened instantly by some magic that belies the existence of the fucking clock. A better term would be zero "effective latency."If it were possible to do processing with "zero latency," then reiterative feedback would happen instantaneously. Instead, the signal feeding back is delayed by the greater of the buffer or the latency of the process. If you use a bus to send to a processor, then route the output back to the same bus, the latency will reveal itself as a period (frequency) in the feedback generated.Why is there a buffer? Because doing math takes time, and how much time defines the latency of the processed audio. If the buffer is big enough then there will be enough time to do all the math and offset the audio so that it stays in sync, giving you zero "effective latency," which is not the same thing as the calculation taking "zero" time.I mean, please don't believe me. All of this is spelled out in the first post I made on this topic. I don't use computers for audio, but I know they can't do math by magic instantly. Just try it. If a thing truly has zero latency, you should be able to feed its output back into its input without any delay because zero plus zero is still zero.But what the fuck do I know. Careful, that's a rake.

I'm going on about this because there's a semantic tic that keeps getting used as though it were a fact, and it's fun to beat dead horses. Live ones no, that's cruel.A process cannot actually have zero latency because an operation takes time. The speed of operations is determined by the clock of the CPU or whatever coprocessor governs that operation. The term of art "zero latency" means the processing time can be compensated for, usually within a buffer, not that it happened instantly by some magic that belies the existence of the fucking clock. A better term would be zero "effective latency."If it were possible to do processing with "zero latency," then reiterative feedback would happen instantaneously. Instead, the signal feeding back is delayed by the greater of the buffer or the latency of the process. If you use a bus to send to a processor, then route the output back to the same bus, the latency will reveal itself as a period (frequency) in the feedback generated.Why is there a buffer? Because doing math takes time, and how much time defines the latency of the processed audio. If the buffer is big enough then there will be enough time to do all the math and offset the audio so that it stays in sync, giving you zero "effective latency," which is not the same thing as the calculation taking "zero" time.I mean, please don't believe me. All of this is spelled out in the first post I made on this topic. I don't use computers for audio, but I know they can't do math by magic instantly. Just try it. If a thing truly has zero latency, you should be able to feed its output back into its input without any delay because zero plus zero is still zero.But what the fuck do I know. Careful, that's a rake.

As I said, not a digital advocate per-se, I just know some bits.That was funny stuff...