Does anyone know of an audio routing or switching abstraction/external, such that one of two or more incoming signals can be selected to be passed on to the next object, ensuring that the other signals are completely cut off?

I am creating an 2-effect module where the effect order can be switched round.

For example, the audio either routes through a delay then into a panner then to the output, or when switched, routes through the panner then into the delay then to output.

Thought I had the switching all sussed out. There's a switch ahead of the two effects which directs the incoming signal to one or other. This same switch is also used to direct the output of the delay either to the panner or the main out, depending on whether it went through the delay first or not. The same is done for the output from the panner.

The whole system works until I connect the output of one effect into the input of the other, when the signal disappears. It's probably some sort of feedback problem, but it shouldn't be because only one of the input signals should be on at any one time.

I've heard of spigot~ but not sure what library it's in as it doesn't work for me.

Could mux~ possibly handle this problem?

http://www.pdpatchrepo.info/hurleur/monoswitch.zip

The signals are sent constantly; they're just constantly sending 0 when they are "off". So there is a feedback loop. Feedback loops can be done using wireless connections (i.e. [send~]/[receive~], [delwrite~]/[delread~], etc.). But then you have the issue of a delay of the blocksize between the connections (see help browser -> PureData -> 3.audio.examples -> G04.control.blocksize).

Thanks, yes that works using send~/receive~. But like you say there is the issue of block size ~ it seems that send~/receive~ only works with the standard block size of 64... does this mean that the received signal is always one block of 64 behind the send, or just that the resolution is limited to 64 samples (ie. @ 44100Hz the minimum delay time is 1.45ms)?

Brett

It depends. In a feed-forward situation, you can force the execution order so that you write to the [send~] before the [receive~] reads from it. In that case, there is no block size delay. You do it by putting the [send~] and [receive~]s in different subpatches and connecting them. See G05.execution.order to see how to do it (that patch shows how to do it with delay lines, but it's the same way with [send~] and [receive~]).

In a feedback situation, you can't force the order like that. Instead, if you need the delay to be shorter than the global block size, you have to put the feedback loop in a subpatch with [block~ 1]. It's cpu intensive, though, so only do it if you have to.