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: WilliamAHuston@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 info@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 info@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 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
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
_______________________________________________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