@Dan
As far as I recall, going between abstraction to parent patch via inlet~/outlet~ introduces a block delay, hence no errorThere's no delay (as long as the blocksizes match).
@William
Second abstraction contains an effect in the feedback path. (in my simple example, it's just a null wire: In-L passes to Out-L, etc). Again this works, no DSP error.But you're using [r~] and [s~] which is not the same as direct signal connections. The former can act like a short delay line. Please read "3.audio.examples/G05.execution.order".
Christof
As far as I recall, going between abstraction to parent patch via inlet~/outlet~ introduces a block delay, hence no error
Third patch is like the second, only the effect has been moved out of the abstraction, and into the parent patch. ONLY HERE do I get the DSP loop error.Signal loop in a single patch without abstractions = error. Pd has no way to read and write to the same signal buffer in the patch at the same time *without* some tiny delay.
The point is the last two patches have (or should have) an identical graph!
At the lower level, they don't. What happens if you put part of the path inside a subpath which uses inlet~/outlet~?
On Feb 25, 2020, at 11:36 AM, William Huston <williamahuston@gmail.com> wrote:
First abstraction, simple stereo delay: 2 delay lines, variable feedback L->R, R->L.This works, no DSP loop error.
Second abstraction contains an effect in the feedback path. (in my simple example, it's just a null wire: In-L passes to Out-L, etc). Again this works, no DSP error.
Third patch is like the second, only the effect has been moved out of the abstraction, and into the parent patch. ONLY HERE do I get the DSP loop error.
The point is the last two patches have (or should have) an identical graph!
It really seems like a bug to me.
I'll upload a test patch a little later.
Thanks,BH
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list