On 2015-09-02 06:10, Evan Buswell wrote:
I've noticed that sometimes input and output buffers will be identical,
btw, this is mentioned in the externals writing HOWTO [1].
e.g. logging the arguments from a lowpass filter, I get: *filter=0x261ab0, n=64, *y=0x32a360, *x=0x329fd0, *f=0x32a100, *Q=0x32a360 -- meaning that Q and y share the same buffer. This leads to weird results when history (i.e. x[i-1], x[i-2], etc.) is needed. My questions are: is this intentional?
yes.
why?
speed. cache usage. it avoids needless copying of samples in a realtime environment.
is this sharing somehow deterministic?
yes, if you take the context of the patch into account. check the code where the DSP-graph is built :-)
can it somehow be deterministically disabled with a flag somewhere?
no.
There are multiple workarounds, of course, but I figured I'd ask first.
you must write code that works if the input and output vectors are the same. this can mean that you need to write your input into a buffer first (which is basically what Pd would have to do if there was a flag to disable buffer sharing).
since it is already known in the DSP method whether the buffers will be shared, you can schedule different perform routines (e.g. for speed reasons) for buffer-sharing and non-buffer-sharing vectors.
but you still have to code the shared-buffers perform routine (so most of the time people don't write an extra perform routine for non-shared buffers).
fgamsdf IOhannes
[1[ http://pdstatic.iem.at/externals-HOWTO/pd-externals-HOWTOse5.html#x7-330005....