Ambiguous tilde object sort order == DSP loop?

Reply to Ambiguous tilde object sort order == DSP loop? on Mon, 10 Sep 2018 14:02:18 GMT

jameslo — Mon, 10 Sep 2018 14:02:18 GMT

In my test patch below, [doNothing~] simply connects the left inlet~ to the left outlet~ and the right inlet~ to the right outlet~. Pd declares that there is a DSP loop detected, but is there really? I think that it's just that the tilde object sort order is ambiguous.

Would it be naive of me to think that this should be allowed? Wouldn't it be useful to relax the sort order rule, for example, by only using the left-most audio connections to determine the sort order? If that was the case, then I could use a structure like this to implement an audio-rate shift register with cascaded [samphold~] objects (i.e. Blippoo Box "rungler"). As it stands, I have to use a delay line.

Reply to Ambiguous tilde object sort order == DSP loop? on Mon, 10 Sep 2018 14:31:23 GMT

LiamG — Mon, 10 Sep 2018 14:31:23 GMT

You're right, PD does a superficial check to see if there are any DSP loops. You can ask about it on the PD list if you want, but I doubt that they'll be that enthusiastic about changing it.

In the mean time, you can always use [send~] and [receive~] or [throw~] and [catch~] to create feedback. [throw~] might be better, as [send~] introduces a one-block delay.

Reply to Ambiguous tilde object sort order == DSP loop? on Mon, 10 Sep 2018 17:02:39 GMT

jameslo — Mon, 10 Sep 2018 17:02:39 GMT

{throw~] and [catch~] appear to introduce a one block delay too:

Reply to Ambiguous tilde object sort order == DSP loop? on Tue, 11 Sep 2018 05:56:57 GMT

LiamG — Tue, 11 Sep 2018 05:56:57 GMT

Interesting. I guess you can use [block~] to set a smaller block size if the delay becomes an issue for you.