As the error says, you shouldn't create a direct feedback loop with signal cords.
I usually use [throw~] and [catch~] for send/receive busses via the rjlib [c_bus], [c_tobus], & [c_frombus] wrappers: https://github.com/rjdj/rjlib https://github.com/rjdj/rjlib
Additionally, I've made stereo versions ([c_bus2], [c_tobus2], [c_frombus2]) in my own rc-patches: https://github.com/danomatika/rc-patches https://github.com/danomatika/rc-patches
I suppose we are introducing (tiny) relays with every step, but in practice I have never perceived it. Then again, most of what I do does not relay on "sub-2ms" latency. For a large project at work, we have a signal path with 64 channels using throw~/catch~ like: input/soundfile channel -> spatialization -> virtual speaker -> output.
On Feb 25, 2020, at 9:50 AM, pd-list-request@lists.iem.at wrote:
Message: 2 Date: Tue, 25 Feb 2020 03:50:18 -0500 From: William Huston <williamahuston@gmail.com mailto:williamahuston@gmail.com> To: Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: [PD] Delay circuit feedback DSP error-- only when signal path leaves abstraction Message-ID: <CAAV8_8=Ui0oV-Hi8jBoxM4MDp_+u8atbZ+uQqNQh9R1BODzczQ@mail.gmail.com mailto:CAAV8_8=Ui0oV-Hi8jBoxM4MDp_+u8atbZ+uQqNQh9R1BODzczQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hi, I've built a classic stereo delay using [delwrite~] and [vd~], and L/R crossed feedback. This works!
Now, I want to insert an effect into the feedback path. (many possibilities here: add some bitcrush, so each repeat gradually becomes more distorted.... or a [hilbert~] type pitch shift, which might create something like Shepard tones, etc).
*This works when everything is within a single patch or abstraction. *
However, when I try to allow the effect to be external to the abstraction (like a SEND/RETURN insert on a mixer), when I try to complete the circuit, I get "DSP loop detected".
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
On Tue, Feb 25, 2020, 5:22 AM Dan Wilcox danomatika@gmail.com wrote:
As the error says, you shouldn't create a direct feedback loop with signal cords.
I usually use [throw~] and [catch~] for send/receive busses via the rjlib [c_bus], [c_tobus], & [c_frombus] wrappers: https://github.com/rjdj/rjlib
Additionally, I've made stereo versions ([c_bus2], [c_tobus2], [c_frombus2]) in my own rc-patches: https://github.com/danomatika/rc-patches
I suppose we are introducing (tiny) relays with every step, but in practice I have never perceived it. Then again, most of what I do does not relay on "sub-2ms" latency. For a large project at work, we have a signal path with 64 channels using throw~/catch~ like: input/soundfile channel -> spatialization -> virtual speaker -> output.
On Feb 25, 2020, at 9:50 AM, pd-list-request@lists.iem.at wrote:
Message: 2 Date: Tue, 25 Feb 2020 03:50:18 -0500 From: William Huston williamahuston@gmail.com To: Pd-List pd-list@lists.iem.at Subject: [PD] Delay circuit feedback DSP error-- only when signal path leaves abstraction Message-ID: CAAV8_8=Ui0oV-Hi8jBoxM4MDp_+u8atbZ+uQqNQh9R1BODzczQ@mail.gmail.com Content-Type: text/plain; charset="utf-8"
Hi, I've built a classic stereo delay using [delwrite~] and [vd~], and L/R crossed feedback. This works!
Now, I want to insert an effect into the feedback path. (many possibilities here: add some bitcrush, so each repeat gradually becomes more distorted.... or a [hilbert~] type pitch shift, which might create something like Shepard tones, etc).
*This works when everything is within a single patch or abstraction. *
However, when I try to allow the effect to be external to the abstraction (like a SEND/RETURN insert on a mixer), when I try to complete the circuit, I get "DSP loop detected".
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
@Dan
As far as I recall, going between abstraction to parent patch via inlet~/outlet~ introduces a block delay, hence no error
There's no delay (as long as the blocksizes match).
@William
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.
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
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 mailto: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 http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
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 mailto:info@christofressi.com> wrote:
@DanAs far as I recall, going between abstraction to parent patch via inlet~/outlet~ introduces a block delay, hence no errorDan, 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 errorThird 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 <mailto: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 <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 mailto:info@christofressi.com> wrote:
@DanAs far as I recall, going between abstraction to parent patch via inlet~/outlet~ introduces a block delay, hence no errorDan, 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 errorThird 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 <mailto: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 <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto: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
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
I think you got it now :-)
In Pd every object is a black box (= the concept of the "unit generator"), it doesn't care what's going on inside. 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
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: WilliamAHuston@gmail.com mailto: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 http://TinyURL.com/DonateToBillHuston
**
On Tue, Feb 25, 2020 at 6:01 PM Christof Ressi <info@christofressi.com mailto: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 <mailto:info@christofressi.com>> wrote: @DanAs far as I recall, going between abstraction to parent patch via inlet~/outlet~ introduces a block delay, hence no errorDan, 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 errorThird 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 <mailto: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 <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tue, Feb 25, 2020 at 6:43 PM Christof Ressi info@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: 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 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: 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 <info@christofressi.com mailto:info@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: WilliamAHuston@gmail.com mailto: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 http://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: WilliamAHuston@gmail.com <mailto: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 <http://TinyURL.com/DonateToBillHuston> ** On Tue, Feb 25, 2020 at 6:01 PM Christof Ressi <info@christofressi.com <mailto: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 <mailto:info@christofressi.com>> wrote: @DanAs far as I recall, going between abstraction to parent patch via inlet~/outlet~ introduces a block delay, hence no errorDan, 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 errorThird 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 <mailto: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 <http://danomatika.com> robotcowboy.com <http://robotcowboy.com> _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
That makes sense... Thank you Christof.
-- 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 7:04 PM Christof Ressi info@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 info@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: 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 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: 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
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
Em ter., 25 de fev. de 2020 às 20:55, William Huston < williamahuston@gmail.com> escreveu:
I hope someone is collecting all of these idiosyncrasies and publishes a document for advanced PD programmers.
Doesn't need to be for "advanced" users. I just updated my already existing tutorial example on DSP loop to explicitly also include this case. For reference: https://github.com/porres/Live-Electronics-Tutorial/blob/master/Examples/Vol...
Hi William,
On 25/02/2020 10:36, William Huston wrote:
*The point is the last two patches have (or should have) an identical graph! *
Pd works with nested graphs - each whole abstraction/subpatch is treated as one atomic unit from the outside. That's why in your original post your second diagram with the abstraction boundaries in blue is not so strange: the blue boxes are really black boxes so the DSP really does loop.
Claude
-
Alexandre Torres Porres -
Christof Ressi -
Claude Heiland-Allen -
Dan Wilcox -
William Huston