[PD] Delay circuit feedback DSP error-- only when signal path leaves abstraction
Christof Ressi
info at christofressi.com
Wed Feb 26 01:04:11 CET 2020
> 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
> <mailto: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 <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 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
>>
> _______________________________________________
> 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/035dfe8c/attachment-0001.html>
More information about the Pd-list
mailing list