On Tue, Feb 25, 2020 at 6:43 PM Christof Ressi <[email protected]> wrote:
> I think you got it now :-) > Well that is very disappointing. I hope someone is collecting all of these idiosyncrasies and publishes a document for advanced PD programmers. I'm about 5 years into PD, and this surprises me. > In Pd every object is a black box (= the concept of the "unit generator"), > it doesn't care what's going on inside. > Yes, but I figured that when a connection is made, PD rebuilds a *flattened *graph, where only basic computational elements (atoms, builtin operators, externals, etc) exist... and any concept of a subpatch or abstraction is lost. Anyway, the workaround is simple enough. Thanks! BH > DSP computation starts from the outside. An object can be computed when > all its input dependencies have been computed. This will never be the case > when one of its inlets is in some way connected to one of its outlets - for > reason which are hopefully obvious. > > The workaround is to use a pair of [s~]/[r~] or [throw~]/[catch~]. > > Christof > -- 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 26.02.2020 00:26, William Huston wrote: > > > 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 >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
