> in your example with the effect outside your abstraction you can literally *see* the DSP loop, why are you surprised?
You have got to be kidding me!!! So are you saying.... If I have an audio abstraction FOO, with has 4 inlets~ and 4 outlets~. and I have another BAR, with 2 inlets~ and 2 outlets~, and I try to connect a pair of FOO's outlets~ to BAR's inlets~, and BAR's outlets to a pair of FOO's inlet's, that *PD throws a "DSP loop error" whether or not there* *is in fact an audio loop in the actual graph?*?? And there is not a way to override this behavior?? -- William Huston: [email protected] Binghamton NY *Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog <http://WilliamAHuston.blogspot.com> -- Facebook <http://facebook.com/billhuston> -- Twitter <http://twitter.com/WilliamAHuston>-- Youtube <https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1> * -- Podcast Blog <https://billhustonpodcast.blogspot.com/>* *Document collections*: VirtualPipelines <http://TinyURL.com/VirtualPipelines> -- BHDCSDimockArchive <http://bit.ly/BHDCSDimockArchive> *Please support my work! -- *TinyURL.com/DonateToBillHuston On Tue, Feb 25, 2020 at 6:01 PM Christof Ressi <[email protected]> wrote: > A DSP loop is when signal connections form a loop. Pd can't look into > objects so it just treats them as black boxes. It's as simple as that. > > After all, in your example with the effect outside your abstraction you > can literally *see* the DSP loop, why are you surprised? And in your other > example with the effect inside your abstraction you don't get a DSP loop > because, well, there's is no DSP loop. > > I see where you're coming from. In the analog world your two examples are > indeed equivalent, but in Pd they are *not*. > > Christof > On 25.02.2020 23:46, Christof Ressi wrote: > > especially because of additional potential delay of inlet~/outlet~. > > inlet~/outlet~ does *not* add a delay (unless when going to a larger > blocksize). > > 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! > > I think you misunderstood. With "former" I meant [r~]/[s~]. > [inlet~]/[outlet~] does not add a delay. > > Also, believe me, r~/s~ has nothing to do with it. > > Believe me, it certainly has. Can you finally share a minimal test patch, > please? I would like to see an actual patch where you get an unexpected DSP > loop error. > > Christof > On 25.02.2020 23:40, William Huston wrote: > > 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 >> > > _______________________________________________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
