[PD] Delay circuit feedback DSP error-- only when signal path leaves abstraction
Christof Ressi
info at christofressi.com
Wed Feb 26 00:42:44 CET 2020
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 at gmail.com <mailto: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
> <http://TinyURL.com/DonateToBillHuston>
>
> **
>
>
>
>
> On Tue, Feb 25, 2020 at 6:01 PM Christof Ressi <info at christofressi.com
> <mailto: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 <mailto: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
>>>>> <mailto: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 <http://danomatika.com>
>>>> robotcowboy.com <http://robotcowboy.com>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pd-list at lists.iem.at <mailto: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 <mailto: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 <mailto: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 <mailto: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/20200226/cfc31156/attachment-0001.html>
More information about the Pd-list
mailing list