i was thinking about "recursive patching" lately, meaning to call an abstraction inside of an abstraction inside of an abstraction inside of an abstraction inside of an abstraction inside of an abstraction and so on.
It is clear to me, that this has to be done with dynamic patching in order to stop the process at some point. So the question is not how to implement this, but in what case something like this could be useful? Do you know of any "recursive" patches? The only thing i can think about are reverberators and i actually tried this using a feedback-delay line inside of a feedback-delay line inside of a feedback-delay line inside of a feedback-delay line inside of a feedback-delay line inside of a feedback-delay line feedback-delay line inside of a feedback-delay line inside of a feedback-delay line.. with rather unimpressive results.
Any ideas?

@solipp this abstraction from @weightless can be useful for iterative things: https://forum.pdpatchrepo.info/topic/10798/setting-expr-formula-dynamically/20 i am not sure if that is what you mean with recursive? you can create some melodies for example: https://forum.pdpatchrepo.info/topic/10888/fractals-with-expr/18 ( i like the fractalmelody patch from @mnb )

@solipp This is useful thinking for recursion...... Claude.Heiland.Allen.zip although old (2009).
It was included in extended, and needs at least Gem and Zexy to work, but the reasoning in the patches is valid even if you cannot make it work.
There are useful objects for restraining the recursive parameters and explanations as to why they are necessary and why they can be difficult to implement.
David.

@Jona @whale-av thanks for the examples, but they don't really capture what i had in mind.

Here is a patch to demonstrate, it does nothing but letting an audio signal through, but it does this with an abstraction inside of an abstraction inside of an abstraction inside of an abstraction inside of an abstraction... recursionrecursion.zip

[Edi: sorry, uploaded the wrong file, now it works]

@solipp Ahhh. [recursive~] was missing so I started again......stuffing.zip
A solution using [namecanvas] and a delay inside to ensure correct build when [recursive~] is stuffed.
Filling [pd stuffing] should not affect the "connect" order.
David.

@solipp I also experimented with this, it is an interesting approach! This works here without delays: recursive.zip (open main.pd).

@ingox I didn't check whether it needs a delay as it stands (I have done now.... and it doesn't).
It will depend what is put into the container patch afterwards. Sometimes delays are necessary, sometimes not, but there is little harm done I think, so I thought I would bung it in.
Lot's of dynamic patching is about not having to renumber connects as the patch is changed..... as you know.
[send~] and [receive~] creation order is another big one.... and [text] can get very upset.
This will become an interesting thread.
David.

Interesting thread, I'd never though about this, although It's not yet clear to me which applications this could be useful for?

@weightless Nor me as yet..... but it's a fun thing....
David.

well, i think it's kind of useful for reverberators. Here is a recursive feedback-delay: recursive_delay.zip