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

[Christof Ressi]

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200225/68e734cc/attachment.html>