Hallo, padawan12 hat gesagt: // padawan12 wrote:
I found this behaviour slightly surprising, but on reflection it makes sense. Pd doesn't seem to check deeply into subpatches when looking for DSP feedback loops.
I started making a simple waveguide synth and decided, for a change, to work on the feedback mechanism inside another subpatch. I kept getting DSP loop error even though the signal path contains a [s~] and unique matching [r~]. Making the feedback loop require a [send~] and [receive~] in the outermost block seems to defeat the use of smaller blocksizes in subpatches.
I'm away from Pd so I cannot check your patch, but your description sounds like you're getting your execution order wrong by trying to force a certain order through subpatches although you have a feedback-delay ("recirculating delay")
You need to be aware that subpatches are evaluated in the order, the signal cords specify.
[pd sig1~] || || [pd sig2~]
Everything in [pd sig1~] will be calculated before everything in sig2~. But if you have a *feedback'd* delwrite~ in sig1~, fed from a delread~ in sig2~, then you'll get a dsp loop, because while it's okay to have the delwrite~ before the delread~ in the DSP graph (and actually it's wanted normally), with feedback you also have a read (catch~ or receive~) before the write (throw~ or send~) and in combination this is not possible in Pd as in the end it would be the same as this loop:
[r~ a] [r~ b] | | [a~] [b~] | | [s~ b] [s~ a]
or [a~]X[b~]. Which should come first?
Also see these two book excerpts: http://www.crca.ucsd.edu/~msp/techniques/latest/book-html/node120.html http://www.crca.ucsd.edu/~msp/techniques/latest/book-html/node121.html
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__