I have a system set up where any number of sound sources can be routed into a few different buses, i.e. throw~ 0-bus, throw~ 1-bus, throw~ 2-bus, throw~ 3-bus.

I also have an effects chain that can pull audio from any of the buses (except for the master bus, which could cause serious feedback loop problems) and then output to any bus.

Because send~ is one-to-many and throw~ is many-to-one, and I want many-to-many, I have a subpatch that does this for each bus N:

[catch~ N-bus]
|
[send~ N-bus-s]

So, that way, I can have anything write to any bus as well as read from any bus.

The 3-bus acts as the master bus - anything thrown to it will be output via a subpatch that contains a [r~ 3-bus-s] connected to a [dac~].

There's a problem: If i have sound source S connected to the master bus, and if I then have the effects chain receiving a signal from bus B, and then have source S throw to bus B while remaining connected to the master bus as well, I get a comb filter, where the signal going from S through an empty effects chain to the master bus is added 64 samples later to the signal going straight from S to the master bus.

I want a solution that retains all the flexibility in routing of signals. Am I asking the impossible? I think the [throw~ 3-bus] from the end of the effects chain is the problem, because it then has to go through the [catch~ 3-bus]-[send~ 3-bus-s] before it is finally picked up by the [r~ 3-bus-s]-[dac~].

I guess I could just try to an add an artificial latency to the master bus... I thought I tried that, though, and it didn't work.

Thanks a million!

Do throw~ and catch~ pairs introduce a block-length delay, while send~ and receive~ pairs don't? Or does it depend on where in the flow they are? I did try and add an extra s~ and r~ in the flow for the signal on the master bus...

hmm, i'm not sure.

i guess not, but you could always just try and see

Didn't work. Maybe I should just scrap and redo all the routing stuff. In an older patch/instrument, the inputs were hard-wired and the outputs were selectable, and I had no problem like this.

Big mess. I redid the routing to be like it was in my previous patch that worked without a hitch, but now I have this huge mess on my hands where it seems that the comb filter-like behavior is arbitrary. Sometimes it happens with certain sources routed through certain filter chains, and with others it's no problem at all. I'm using the exact same abstraction to handle the routing for each source's output.

Now I'm thinking that something screwy is happening because of the order in which I created the throw/catch objects. Does anybody know how to trace this down?

Does anyone know how to trace down this seemingly arbitrary problem? Does it have to do with the order in which I created different throw~s and catch~es?

Okay. I've gotten it narrowed down a little bit. Now, the effects chains that are in abstractions rather than subpatches DO introduce the delay, but I still have one that is a subpatch, and it DOES NOT introduce the delay. I have this more consistent behavior when I, at a suggestion of a friend who uses Max, went in to my sound source abstractions and cut and pasted everything to new files to sort of "refresh" everything.

This all leads me to believe there's something screwy going on with the order in which objects are created when the patch is loaded.

Anyone have any thoughts?

Thanks!
Jake

Yes that's it. Search the list archives for Franks explanation of creation order pitfalls.

I am not finding it. Can you point me to a specific post? User name Frank appears to have no posts.

http://puredata.hurleur.com/profil-36-frank

Okay, found it on the mailing list archives, not the forum. http://lists.puredata.info/pipermail/pd-list/2007-02/046838.html for those who can't find it.

That's great - it totally does solve the problem. However, you need to have lots of ugly cables, and I'm trying to have my interface for this program as neat as possible. Is there some way to avoid seeing all the cables, short of putting my whole patch into one huge subpatch?