Hi list,
I am getting error messages saying "block~: overlap not a power of 2". Perhaps someone could explain why 1.) overlap should be a power of 2 2.) at the same time, setting overlap to 1.5 (which, after all, is not a power of 2) seems to be ok
Thanks, Matthias
Matthias Blau wrote:
Hi list,
I am getting error messages saying "block~: overlap not a power of 2". Perhaps someone could explain why 1.) overlap should be a power of 2
pd processes signals not on a sample-per-sample basis but rather in blocks. these blocks have a default length of 64. the length of the blocks can be changed (as you well know), but only to other 2^n-values. why ? i think because it is easier to do (faster to code, simpler to optimize,...). an important factor for using only integer multiples of 64 for block-length is (imho) that the dsp-tick (once every 64 frames) can be used for all signal-blocks. (it gets a bit more complicated when you have blocks <64, but that is a different story)
now what has this to do with the overlap factor ? well, the overlapping blocks need a) also fit into the dsp-tick-scheme and b) overlapping should be done reasonably fast. no with block-sizes being 2^n and overlap-factors being 2^m, the offset between 2 blocks will always be integer 2^(n-m) [n>m]. if you would want an overlap-factor of 3, the offset between to blocks would be 64/3 which would involve some interpolation in order to get the samples "in-between".
2.) at the same time, setting overlap to 1.5 (which, after all, is not a power of 2) seems to be ok
it is not ok!
one might only think it is, because pd doesn't complain, but you should really look at the results. it's because pd will first cast the input to an integer (1.5 will become
- and afterwards it will check whether the value is 2^n. and 1=2^0
i agree that it should also bail out when getting non-integer values, in order to not confuse people too much.
mfg.asd.r IOhannes
Thanks Johannes,
now what has this to do with the overlap factor ? well, the overlapping blocks need a) also fit into the dsp-tick-scheme and b) overlapping should be done reasonably fast. no with block-sizes being 2^n and overlap-factors being 2^m, the offset between 2 blocks will always be integer 2^(n-m) [n>m]. if you would want an overlap-factor of 3, the offset between to blocks would be 64/3 which would involve some interpolation in order to get the samples "in-between".
perfectly clear, provided someone would, at the appropriate point in the pd manuals/documentation (in Miller's book, in the help file for block~/switch~), state that offset=blocksize/overlap (I asked about the definition of overlap in vain because I couldn't find exactly that information a while ago). This would be particularly useful as overlap is usually defined either as absolute value or percentage of overlapping samples (as the name would suggest) or as offset between subsequent blocks (again either as absolute or relative value).
it's because pd will first cast the input to an integer (1.5 will become
- and afterwards it will check whether the value is 2^n. and 1=2^0
that would be a valuable information in the help file for block~/switch~ as well.
i agree that it should also bail out when getting non-integer values, in order to not confuse people too much.
So do I.
Regards, Matthias
-
IOhannes m zmoelnig -
Matthias Blau