Perhaps you can give me some insight on how pure data calculates, i am kinda lost in debugging this issue.

I want to do a waveguide simulation,In short the signal goes in, gets delayed, reflected on the and with some dampening and gets delayed again with some dampening. In the end you got 2 inlets and 2 outlets (front and back of the pipe). When you connect two waveguides together the reflection feed into each other.

I searched the forum about DSP Loop error and other people trying to implement a Waveguide, but I still can't solve it. I read about how pd does 64 sample blocks and you need to set them to one, which i did. And that i need to add a throw/catch or similar (i tried multiple) to force instant calculatins, but i dont really understand why or how (beside adding block~ 1) the implemetation works. Especially where do i need to do the 1-sample delays to force the calculation.

Prior using pd I implemented my idea using python (but its to slow) and luckily i found pure data which is a godsend so far! Strange that iam doing music for over a decade and never heard of it... Because of the Python implemetation I understand it in a technical standpoint, but not how i can do it in pd and why I allways get a DSP Loop error.

Thats my current setup. The red Arrows show the incoming and outgoing signal in the end.

I tried all three.

Can you help me?
Cheers and Thanks
Polle

there is the dsp-loop:

Also be aware that the patch is calculated in blocks
and if you detatch the feedback-loop with s~ r~ or similar,
one-block-delay is introduced in the feedback.
64 samples, - as long as you do not put these abstractions in a reblocked subpatch: [block~ 1] in [pd subpatch]

offtopic but all those 1-sample delays in the abstraction (one of many ways to do this in Vanilla would be [rzero_rev~] ) are not required I guess.

@lacuna

you mean something like this?

so the loop needs to be "broken" outside of a subpatch?

@polle Have a look at the doc folder in your Pd folder.
doc/3/audio.examples/G05.execution.order.pd ...... has information about how to use delays.
Also there was a very recent thread about the feedback problem....... https://forum.pdpatchrepo.info/topic/14471/dsp-loop-with-buffer-abstraction

And more...... because it can get complicated if using interpolation..... and the [send~] [receive~] 64 sample fixed block limit is gone in the latest Pd........ https://forum.pdpatchrepo.info/topic/14549/feedback
David.

@lacuna
if i understand correcly, the solution I just posted with the send /receive will be calculated in blocks so it also needs to be put in another subpatch with a block~ 1?

@lacuna said:

offtopic but all those 1-sample delays in the abstraction (one of many ways to do this in Vanilla would be [rzero_rev~] ) are not required I guess.

that could make sense now!

@polle yes

also see the help file of s~ r~

the former way has been, and still useful:

[block~ 1]
[array define fb 1]

[tabsend~ fb]

[tabreceive~ fb]

not sure if [block~ 1] [throw~ feedback] [catch~ feedback] can go down to 1 sample delay, but I think so

On naming:
[pd nameofsubpatch] is a subpatch
and your [bbt-waveguide] is an abstraction

thanks for explaining the differences between subpatch and abstraction, which does make sense now!
The waveguide is running, thanks for your help!