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

Wed Feb 26 01:18:58 CET 2020

That makes sense... Thank you 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 Tue, Feb 25, 2020 at 7:04 PM Christof Ressi <info at 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 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
>>
> _______________________________________________
> 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/c7bffbb4/attachment-0001.html>