test1 realizes a simple delay effect. test2 is identical, but the delay buffer is encapsulated in delayline~. test1 works fine, but with test2 a DSP loop is detected. I'm wondering why. Is it a bug or is it defined behavior? I'm using Purr Data 2.19.3 (Pd-0.48.0) and also tested it with Pure Data 0.52.1.

Thank you in advance!
André

test1.pd test2.pd delayline~.pd

When you want to create feedback, you need to use either a [s~ ]/[r~ ] or [throw~]/[catch~] pair, or write to a table with [tabsend~] and read with [tabreceive~]. Didn't check your patches, but DSP loops are detected when a signal chain returns to a previous point.

Think of it like this, in the following ASCII patch:

[osc~]
|
[*~ ]

[osc~] needs to make its computations before it sends its output to [*~ ]. If [*~ ] was to send its output back to [osc~]'s inlet, the latter would not be able to compute this signal, as it will be generated after [osc~]'s own output has been computed. Using a [s~ ]/[r~ ] pair, you can be sure that [*~ ] will send its output to [s~ ], which in turn will transfer it to [r~ ], without disturbing the signal chain order

Thanks for your post!

Okay, test2 works if I replace the direct feedback path with send~ and receive~ objects. I understood that test2 fails since there is a signal path from the output to the input of the same object, which is delayline~, Whereas with test1 the feedback path is connected from delread~ to delwrite~, i.e. there is no object with a path from its output to its input.

The feedback does not occur between [delwrite~] and [delread~] if not patched explicitly. [delread~] reads from the corresponding [delwrite~]. To create feedback, you'll still need to use [s~]/[r~] etc, to send the output of [delread~] back to the input of [delwrite~]
Mind though that it's best to put the writing and the reading parts of your delay in separate subpatches, where the one with [delwrite~] will have a dummy [outlet~], and the one with [delread~] will have a dummy [inlet~]. Then you must connect the two in the parent patch, to circumvent the issue of not being able to drop the delay time lower than one sample block. By making this connection you explicitly force Pd to first compute [delwrite~] and then [delread~], so delays up to a single sample are possible. This is somewhat related to the feedback issue you were having, and the way Pd treats signals.

@xaverius Were you able to implement that? Currently i am struggling to implement something similar for a waveguide simulation. Still getting the DSP loop error with everything I try.

@alexandros said:

To create feedback, you'll still need to use [s~]/[r~] etc, to send the output of [delread~] back to the input of [delwrite~]

I think that's not necessary, because there is no patch cable from delwrite~ to delread~.

I'm quite sure I've implemented a flanger in Pd by signal --> delwrite~, then (modulated delay-time) delread4~ --> [*~ something less than 1.0] --> the same delwrite~.

hjh

@ddw_music said:

@alexandros said:

To create feedback, you'll still need to use [s~]/[r~] etc, to send the output of [delread~] back to the input of [delwrite~]

I think that's not necessary, because there is no patch cable from delwrite~ to delread~.

It's not necessary, but if you want to not be constrained by sample blocks for the delay time, then [delwrite~] and [delread~] have to be placed in subpatches where the former will have a dummy outlet and the latter a dummy inlet, so these subpatches can be connected and the DSP order will be forced to first compute [delwrite~] and then [delread~]. It has been a subject of discussion many times, as to how to go below one sample block of delay time.

@alexandros said:

It's not necessary, but if you want to not be constrained by sample blocks for the delay time, then [delwrite~] and [delread~] have to be placed in subpatches where the former will have a dummy outlet and the latter a dummy inlet,

True, but if you're doing feedback, then there's no escape from a block's worth of delay.

If not doing feedback, then the dummy inlet/outlet won't trigger errors. If feedback is involved, this inherently adds a block of delay (which can be reduced, but not eliminated, by ~block-ing a subpatch).

hjh

@ddw_music said:

@alexandros said:

It's not necessary, but if you want to not be constrained by sample blocks for the delay time, then [delwrite~] and [delread~] have to be placed in subpatches where the former will have a dummy outlet and the latter a dummy inlet,

True, but if you're doing feedback, then there's no escape from a block's worth of delay.

If not doing feedback, then the dummy inlet/outlet won't trigger errors. If feedback is involved, this inherently adds a block of delay (which can be reduced, but not eliminated, by ~block-ing a subpatch).

hjh

That's also true. To include feedback and be able to go to delays down to one sample, these two subpatches have to be included in a parent subpatch, which contains a [block~ 1]. Also, instead of [s~]/[r~] pairs, one should use [tabsend~ tabname] and [tabreceive~ tabname] along with an [array define tabname 1].