On Sat, Apr 20, 2024 at 03:47:20PM +0200, Robin Gareus wrote: With the new logic deciding on forward / backward jumps, the low latency mode just came for free - all it takes is just changing the value of one variable. BTW, the 'correct' latency, the one that would perfectly align the pitch detection with the signal, would be 5/8, not 1/2 of the input size. But I kept 1/2 in order to match the latency of the original version. For low latency, I use 1/4, around 10 ms. The standard 'bugs' were not in the Retuner class, so they won't affect the plugin code. Re. microtuning individual notes: I don't think the retuning is ever accurate enough for this to be of any use. Or maybe I misunderstand what you refer to. What would be great (in particular for zita-at2) would be a mode were you can e.g. select a region in Ardour, have it analysed, present the result graphically so it can be edited, and finally apply the edited version to the region... It would require separating the pitch detection, the logic that decides on the amound of correction, and the actual processing of the signal as separately usable components. I'll keep this in mind when designing zita-at2. Ciao, -- FA

On Tue, Apr 23, 2024 at 09:24:20PM +0200, Robin Gareus wrote: It will be 10 ms when selecting low latency mode. That must be BS. A typical male voice frequency is 125 Hz, 8 ms. So when the algorithm has to skip a cycle, will the latency change to -6 ms ?? Did anyone ever verify this ? I did a few minutes ago, by observing in and out on a scope. Normaly latency for the x42-autotune seems to be around 20 ms. Selecting 'fast' doens't seem to make any difference. Using the thingy in the left upper corner, I get latencies up to more than half a second, even when this is set to a few ms. Sorry, but I've lost all confidence in whoever has been dabbling with something that he/she clearly doesn't understand. If this is the standard of quality of Linux audio, I'll just stop releasing anything. Ciao, -- FA

On Wed, Apr 24, 2024 at 10:02:01PM +0200, Robin Gareus wrote: 1024 samples at 96 kHz (the signal is upsampled) is 10.67 ms. And it will maintain that +/- half a cycle of the retuned frequency. The worst case would be at 75 Hz, +/- 6.7 ms. At higher pitch the variation will be less. The average value will always be 10.67 ms. The way 'fast mode' works in the x42 plugin could give you a momentary latency of 2 ms, but the average value will be quite a bit higher and depend on signal content. So that 2 ms is just snake oil. Using the same misleading definition of 'latency' I could claim whatever I like for zita-at1-0.8.1, even down to zero. Anyway, I'll make sure that no such false claims will be made of at2. Even if that means I just can't release it under a license that allows modifications. There's more than enough people who are prepared to accept a more restrictive license, and even pay for it. Ciao, -- FA

On Thu, Apr 25, 2024 at 12:52:07AM +0200, Robin Gareus wrote: And that should be the average value, not the minimum which can be achieved only during a small fraction of the time (or for unvoiced signals by forcing them to have a different delay than the average voiced ones). Indeed, but that is not what I refer to. Assume for a moment that you are retuning 'up'. That means that the input is consumed faster than the output sample rate. So at some point, since you can't read past the end of input, you will have to skip back by at least one cycle of the fundamental frequency, which means the latency will increase by the same time. Latency is in fact changing all the time while retuning, and the only meaningful value is the average one. For a constant retuning ratio, the latency as a function of time will be a rising or falling 'sawtooth'. The fundamental difference between at1-0.8.1 and previous versions is that it will try to remain as close as possible to a well-defined average delay, i.e. minimise the delay jitter. Of course. But that should be real value. Not some fake one dreamt up to look good. -- FA