[PD] Delay circuit feedback DSP error-- only when signal path leaves abstraction

[William Huston]

> 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 at 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 at 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 at 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 at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>
> _______________________________________________Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200225/c598f720/attachment-0001.html>