IOhannes m zmoelnig wrote:

/*j wrote:

...

hello IOhannes, Tim and Thomas,

...

there is no such flag in pd, you have to take care of not overwriting the input signal yourself.

i thought so, how do you all live with this? buffering the vectors seems like a terrible waste of cycles...

but why? if you have this flag, someone (the application) has to take care of not reusing the signal-vectors. this involves copying the data to somewhere else.

CAVEAT: I've never written a DSP external nor looked in-depth at Pd's source, so this may be nonsense:

But, I don't think copying is necessary at all, if you provide two pointers, one for input(s) and one for output(s), which may or may not be the same (flag is not set) or will not be the same (flag is set). It is up to Pd's DSP scheduler to see which signal buffers are in use and/or must not be aliased.

The first case ("in use" testing) must surely exist, otherwise Pd would have to allocate a buffer for every signal patch-cord, which would be a bit silly with respect to memory cache efficiency and also involve lots of copying of data.

The second case ("aliasing" testing) could exist, the most general interface would have a matrix M of bits of size NumberOfInputs * NumberOfOutputs, where M(Input_I, Output_J) indicates whether Input_I and Output_J must be in different buffers. I don't know whether there is an efficient algorithm for using this data representation to choose which memory buffers to use for each DSP object's inputs and outputs, but I imagine it wouldn't need to run too often.

END CAVEAT.

if there is no such flag and you want to acoid reusing the signal-vectors, you have to copy the data to somewhere else.

True.

so the "terrible waste of cycles" will always happen, the decision to make is whether max/msp does it automatically or whether the pd-developer has to do it by hand.

Better IMHO to avoid the need for copying in the first place.

grÌße.brtg.as IOhannes

Happy Wednesday,

Claude