On Tue, Feb 25, 2020 at 6:14 AM Christof Ressi <[email protected]> wrote:
> @Dan > > As far as I recall, going between abstraction to parent patch via > inlet~/outlet~ introduces a block delay, hence no error > > Dan, correction-- that is the exact circumstance where I *am* getting the error. So now I think you are beginning to see why I think it's unexpected, especially because of additional potential delay of inlet~/outlet~. Dan also wrote: > As the error says, you shouldn't create a direct feedback loop with signal cords. Let me try to explain again: *I have taken a WORKING CIRCUIT--* (a simple stereo delay circuit, with cris-cross L/R feedback implemented with [delwrite~] + [vd~]) *-- which DOES NOT produce a "DSP Loop Error", * *pulled a Null (straight-wire) Filter * *(which had been installed in the feedback path)* *and moved it externally to the abstraction* *(up to the parent patch), via outlet~/inlet~,* *which, if anything ADDS additional block delays, * *yet this produces "DSP Loop Error". * *Clearly (the way I see it) * *the logic behind detecting "DSP Loop Error" condition* *has a bug.* *I believe this is a false error,* *because as I have stated--* *the circuit HAD been working!* *All I did was add the potential for additional* *blocks of delay on the feedback path. * 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, Yes! Exactly! Added delay should REDUCE the chance of a "DSP Loop Detected"! Also, believe me, r~/s~ has nothing to do with it. My original patch was extremely ugly, due to criss-crossed feedback. I only implemented with r~/s~ to clean up the patch to share. Thanks everyone! BH Christof > On 25.02.2020 11:42, Dan Wilcox wrote: > > 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 <[email protected]> > 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 > > > -------- > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com > robotcowboy.com > > > > > _______________________________________________pd-l...@lists.iem.at mailing > list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
