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

[Christof Ressi]

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 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/b68a9b23/attachment.html>