hi all! long time lurker/reader, first time poster. thanks for sharing all your knowledge, it has been invaluable to my education in PD!

I'm building a sort of modular synth in PD and have arrived at an issue: feedback. I've search this (and other) forums and found that feedback is possible if one uses send and receive objects, and indeed this works... sometimes.

Each of my modules exists as it's own PD file - I think that's called an abstraction. I have them set to "graph on parent" so there is a little GUI/module front panel that can be manipulated. When I instantiate a module, such as an oscillator, it works great but if I route the output back into the input (through a *~ object or something) I get the "DSP loop" error. I have a block~ object in the abstraction set to 64 (block~ 64) per some instructions i found in this forum.

However,** if I am "inside" the abstraction** (if I open the abstraction file) I can successfully connect the output of the oscillator (from a r~ object) back into itself (into a s~ object).** The patch feeds back** and it sounds awesome!

I don't understand why this feedback works inside the abstraction but not when I'm "zoomed out" (I'm not sure what the terminology is). I suspect I'm missing some key piece of understanding.

If anybody has any ideas, I'd be grateful! Once my little modular system is a little less buggy I'll share the whole thing on github and here.

Here is the oscillator abstraction:
vco.pd

It's a loop error because each DSP object in Pd passes samples in blocks (or vectors) from one to the other. By default the block size is 64 samples. But whatever the block size is, Pd has to process one object at a time, passing the blocks from one to the other. When you directly connect them via patch cords, it isn't necessarily clear to Pd which one should be processed first. The order is important to get the behavior that is expected. So whichever one Pd chooses could lead to different results.

The preferred way to do feedback is to go the cordless route, such as using [send~]/[receive~] or using the delay objects. Pd understands this better because it knows to read from [send~]'s (or [delread~]/[vd~] if using delay objects) block first, pass it through whatever patched objects that process it, then write to [receive~] (or [delwrite~]) before going through the next dsp loop. Keep in mind, however, that using this route the feedback will be delayed by at minimum the size of the block. So in your abstraction the feedback is delayed by 64 samples. If that's fine, then go for that. If not, lower the block size using [block~ 1]. But only do that if you really need it, because lowering the block size can significantly increase the computation load.

Take a look at G01 - G05 in the audio examples in the help browser for more clarification on this.

thanks for the explanation! that mostly makes sense, I'll check out those audio examples.

I'm using send~ and receive~ in the abstraction, and I thought that even if the abstraction were instantiated into a different PD patch, the send~ and receive~ objects would still do their thing. It seems like having them inside an abstraction is what is making the feedback not work, and that's the part I don't understand. In my mind everything should function exactly the same whether it's inside an abstraction or not.

Some pictures to illustrate:
Inside the VCO abstraction the input and output goes through s~ and r~ objects

..and if I use s~ and r~ objects outside the abstraction it works:

But since there are already s~ and r~ objects inside the abstraction, I would think this would work.. but it doesn't.

I'm sorry if I'm just fundamentally misunderstanding this! Thanks for your help!

@chrisbeckstrom If you use $0 as part of a send or receive (or any other) object the $0 becomes a number above 1000 which is unique to that patch and any sub-patches it contains. If you put $0 in an abstraction..... well....... that is another patch so the value of $0 will be different, so the objects cannot talk. Use $0 to keep messages private within a patch....... don't use it if you want to send a message "globally" across your patches.
David.