[PD] audio send recieve feedback quirk

[Frank Barknecht]

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__