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

@nickporcaro Hi, this is something I thought up in response to your question, I haven't actually used it so I'm not sure if it works reliably, but at least it gives you an idea on a possible approach. This method basically uses abstractions and their arguments to create the filter themselves and their respective catch~/throw~ objects, then the order of execution is specified in a text. This way you can save/load different routings to .txt files. signal_order.zip
It's not exactly "on the fly", but I don't think there are many other ways that would scale up easily.
Hope it helps.

@weightless Very good. I think the audio list might be rebuilt as the [throw~] obcect receives its new destination. Your ears will tell you using [osc~ 20] for example instead of [noise~].
Of course the chain might be rebuilt between blocks in which case there should be no problem.
You might need to take down the audio for a block (1.45125 ms of course at a blocksize of 64).
David

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.

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

@nickporcaro As far as I understand it what @whale-av was saying is that you get a click when changing the order. This could be forced to happen between dsp cycles, I think. What do you mean by "depend on the order of catch~ and throw~"?

@nickporcaro Hi there,

You might want to take a look at William Brent's DRFX if you haven't already done so:
https://github.com/wbrent/DRFX

As far as I can tell, it uses dynamic patching to route signals through effects, perhaps in a similar way to what you're looking to do.

@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 -

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

• Nick

@nickporcaro Ah yes, of course. Each filter would have to have a unique name otherwise if you have, say, two [lop~ 400] you wouldn't know which is which. If this is a one-off sort of application with just simple filter objects in the chain, you could modify the patch (and the list in text) as to give unique names to double filters, something like [lop~ 400 1], [lop~ 400 2] etc. When you want to move them around you can just cut and paste the corresponding line in text and put it somewhere else (it doesn't matter if lop~ 1 comes after lop~ 2 as they would be the same).
If you are looking for a more universal method which includes more complicated stuff in the chain, you'd probably have to somehow check upon creation whether the object you are creating already exists. Perhaps DRFX can provide some helpful insights on how to do it, but I haven't checked it out yet.

@weightless @nickporcaro Well it all dépends upon what you mean by "on the fly".
If you mean "while audio is passing" and you want to do it without clicks or dropouts then my original thoughts (that I didn't post) would be to create an abstraction....
lop~
hip~
lop~
and provide an inlet that uses multiple [* ~] objects to insert the audio either before the first [lop~] and send out the output of the [hip~] OR insert the audio before the [hip~] and output the audio from the second [lop~]
Basically, "mix" your way around the abstraction "old style".
You could do it with just the one of each effect, but you need to get your order of switching correct for the [**~] objects.
David.

@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...

@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?

@nickporcaro If it helps, this is a version of [receive] which lets you switch the source using dynamic patching. dreceive.zip

For me the trickiest part is keeping track of duplicates in the chain. If you are willing to manually specify duplicates in the text (something like: 1-lop~ 400, hip~ 20, 2-lop~ 400 etc) then my patch could be made usable I think, otherwise if we are talking about a chain of hundreds of filters, making a duplicate checker would require some work.
How many filters are you looking at using?

@nickporcaro iemguts can be useful but is not necessary at all for dynamic patching.
Your original post can be done easily like this........dyn.pd
...... and to change for other modules all you would have to do is change the names noise~ hip~ and lop~ in the message to eg . osc~ 440, effect1 and effect2.... + any arguments you want to give them.
You would of course have created them as abstractions (objects) already, in a place that Pd can find them.
But that will cause audio clicks......... because audio objects are being deleted and disconnected etc.
And you will have problems if you want to use [inlet~] and [outlet~] so you will have to use [send~] and [receive~] to connect with the sub-patch......
David.