That makes sense... Thank you Christof.
-- William Huston: williamahus...@gmail.com 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 7:04 PM Christof Ressi <i...@christofressi.com> wrote: > > Yes, but I figured that when a connection is made, PD rebuilds a *flattened > *graph, > > Pd *could* flatten the graph - but only if the subpatch is not reblocked, > upsampled or overlapped. For consistency and simplicity it makes more sense > to always treat subpatches as unit generators. > > Christof > On 26.02.2020 00:52, William Huston wrote: > > On Tue, Feb 25, 2020 at 6:43 PM Christof Ressi <i...@christofressi.com> > 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: williamahus...@gmail.com > 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: williamahus...@gmail.com >> 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 <i...@christofressi.com> >> 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 <i...@christofressi.com> >>> 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 <williamahus...@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 >>>> >>>> >>>> -------- >>>> 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 >>>> >>>> _______________________________________________ >>>> Pd-list@lists.iem.at 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 >>> >>> _______________________________________________ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >>> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list