Tim Blechmann wrote:
i am *very* sorry that i ever introduced this stupid [nop~] object that does delay the signal by one block. this should be considered a bug! probably i'll change the behaviour in future versions of zexy to a real [nop~] (which does exactly *nothing*)
i see, so the nop~ that is used in the limiter help-patch isn't really necessary?
no, it IS necessary, but this is even more a problem.
the [limiter~] does some interpolation of the signal to get the real maximum. eg, if you have a digital signal "... 0 0 0 0 0 0 1 1 0 0 0 ..." the digital maximum is one, while the maximum of the d/a-converted signal would be higher (somewhere between 1.0 and 2.0), due to convolution with a sinc(). now [limiter~] tries to get the "real" maximum (inbetween samples). due to the nature of signals, the [limiter~] object cannot look into the future and thus has to delay the signal a bit (9 samples or so) thus the signal that has to be limited should be delayed too. i (unfortunately) have used the [nop~] object for this (because it was at hand and there was no [z~] then) you might argue, that 64 samples is a bit to much (if the limiting-signal is delayed by 9 samples only) but this is about masquarading and psychoacoustics...
so probably i'll change the help-patch to *not* use [nop~] but [z~] to acchieve the delay.
mfg.a.sdr IOhannes