@nickporcaro
I just found a paper from IOhannes m zmölnig

https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf

And a github repo:

https://github.com/iem-projects/pd-iemguts

Perhaps it's possible to use iemguts to do dynamic patching. Has anybody tried this?

@weightless I just looked at DRFX - it's cool but what it seems to be doing is sending
sources to effects in parallel and throwing the output of each effect to dac~.

So we are not there yet.... looking...

@beep.beep Thanks beep.beep - that looks pretty interesting - I'll report back when I get a chance to look at it

• Nick

@weightless

What I mean is that I don't think we can necessarily depend on which order throw~
happens in the case that there are more than one throw~ in the patch.

Correct me if I'm wrong -

I agree the solution weightless proposed in signal_order.zip won't work because we can't depend on the order of catch~ and throw~ - so I think in the end my hack has to do it.
Thanks gain for looking-

• Nick

Thanks folks - I'll take a lot at your solutions.

I came up with a hack that works, but it is a hack.
What I did was create abstractions for each possible subpatch that I want reorder
then I copy whatever I want into the abstraction. Eg:

[adc~]
[fx_effect1]
[fx_effect2]
[dac~]

Then if I want lop~ to be fx_effect1 and hip~ to be fx_effect2,
I create fx_effect1.pd with the lop~ in it and fx_effect2.pd with hip~ in it.

Hey folks,

How would you reorder the signal order execution of the lop~ and hip~ in this trivial patch
using control signals?
So that this:

[noise~]
[hip~ 20]
[lop~ 400]
[dac~]

Becomes this:

[noise~]
[lop~ 400]
[hip~ 20]
[dac~]

[Yes, in this particular case it probably does not matter what the order is].

In general there could be many filters here, so I need a solution can can scale nicely.

• Nick