Paul Winkler wrote: Right, i have to admit it does :) That's why the plugin has to have latency. Yes you can. No, you can't actually, but you can eliminate the problem so you don't have to solve it. There is a ringbuffer, with a length chosen so it is capable of containing a whole half-cycle even at low frequencies (40 Hz is the limit in my implementation, which means varying number of samples at varying samplerates). Incoming audio is streamed into the ringbuffer (which actually works like a FIFO), and the half-cycles are being scanned starting from the other end of the buffer (that is, where output falls out). Now let's say the buffer is just full of audio. The host calls run(), and the plugin starts scanning backwards (from the oldest sample, that is, the one just about to fall out of the FIFO, towards the newest one), and marks zero-crosses and scales the marked individual zero-crosses. It keeps track of the half-cycle boundaries, and when it reaches (or more likely, overgoes) the N samples the plugin was asked to process in this run() call, it pushes out the N samples, but that of course will be in no relation with the half-cycle boundaries. Some piece of the last half-cycle will remain, and at the next run(), the plugin will continue the zero-cross scan from that point, not from the buffer boundary. But it counts the N samples needed to be pushed out from the buffer boundary, of course. I'm afraid i can't explain it very clearly, but i hope you get the feeling. Tom ps. stay tuned, more plugins are about to arrive... expect them in a week or two. :)