[PD] pd internals / block delay

[IOhannes m zmoelnig]

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