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

Wed Feb 26 00:52:28 CET 2020

On Tue, Feb 25, 2020 at 6:43 PM Christof Ressi <info at 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 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 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 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
>>
> _______________________________________________
> 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/f495fb6c/attachment-0001.html>