Luke Iannini writes:
Sorry if I'm losing everyone : ), hopefully at least the idea of a Pd-Message-Patchmatrix makes sense to everyone and I'm just losing everyone with my implementation and explanation thereof!
I don't yet understand the details of what you propose, but I certainly see the value of your goal; it's something I've dreamed about, too -- dynamic patching. Best of luck to you, and I will follow your progress with interest.
Phil Stone UC Davis
Frank – sorry I didn't get a chance to respond earlier; I found a solution and have been coding that instead of reading the list in my free time : ).
First, your patch is reversed from what you explained, no? M inlets by N outlets? Anyhow, only a technicality.
My patch was indeed intended to do just what you described/coded, but again I think my "unique" implementation might have been confusing : ). I just used spigots instead of the [sel 1]/[route] idiom you used here.
Now, the issue I was having crops up when routing the result of a single inlet "matrixed" to multiple outlets back into an inlet. I think it occurs in your copy as well: the first outlet to recieve the input (let's say it was "10101" again) transmits it to the top of the chain, and before your list drip has completed, a new input/row is received that overrides the first (also replacing the contents of the list append at the bottom).
I have attached a modified copy of your patch demonstrating this. Most mods are in the lower left; use my element definitions to see the issue in action. If you disconnect the "loopback" sends (outputs Y&Z
inputs B&C in the lower left) it works fine, but when they are
connected only one output makes it out.
So! My solution was to make as many patchbays as there are inlets (all configured identically). They are put in a stack, and each new input is sent to an open patchbay. When an inlet is received by a patchbay, it is removed from the stack until it finishes outputting to all its outlets, at which point it adds itself back to the top of the stack.
My dreaded loopback test functions now : ). I think I am correct that the number of "matrix voices" needed for "worst case scenario" is the number of inlets, but I have not thought it through completely yet, perhaps it is the number of outlets after all. There are 9 in the attached patch only because that is the number of inlets in my actual setup.
Oh, and Frank, I learned everything I know about patching from your patches, so a huge thanks to you!! The actual version of this patchbay is fully Memento enabled (as you can perhaps see some evidence of in the patmatel abstraction) : )).
On 1/18/07, Phil Stone pkstone@ucdavis.edu wrote:
Luke Iannini writes:
Sorry if I'm losing everyone : ), hopefully at least the idea of a Pd-Message-Patchmatrix makes sense to everyone and I'm just losing everyone with my implementation and explanation thereof!
I don't yet understand the details of what you propose, but I certainly see the value of your goal; it's something I've dreamed about, too -- dynamic patching. Best of luck to you, and I will follow your progress with interest.
Phil Stone UC Davis
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
Now, the issue I was having crops up when routing the result of a single inlet "matrixed" to multiple outlets back into an inlet. I think it occurs in your copy as well: the first outlet to recieve the input (let's say it was "10101" again) transmits it to the top of the chain, and before your list drip has completed, a new input/row is received that overrides the first (also replacing the contents of the list append at the bottom).
I have attached a modified copy of your patch demonstrating this. Most mods are in the lower left; use my element definitions to see the issue in action. If you disconnect the "loopback" sends (outputs Y&Z
inputs B&C in the lower left) it works fine, but when they are
connected only one output makes it out.
Okay, this is indeed true and it has to do with Pd's "depth first" message passing: Pd tries to walk along a message path until this path ends. E.g. if you have a [t b b] then first everything connected to the right outlet will be worked out completely before the bang from the left outlet of the trigger will fire.
With your loopback setup, walking along will work fine for the outletY-route at first, but as soon as inletB fires, the counter after the matrix in [pd count] will be reset to start at 0 again and the [list] storing the 10101 will be overwritten by what's coming in through inletB (in this case, a 10101 will come in again, but that's just luck, it could be something different). So a lot of stuff will be invalidated by the looped back message.
The solution is to defer the looped back messages until every direct message has finished operations. You can do this easily with [pipe] objects between the [r outlet?] and [s inlet?] objects. [pipe] (and [del] will delay messages for one logical step even, if the delay time is 0. They kind of insert a temporary end point to the depth first message operations.
As a bonus I attached a little GUI abstraction to edit 0/1 matrices of arbitrary size. This might be useful for your patch. It expects Pd at least 0.40 to look nice. It also seems to trigger a bug in Pd and makes the red GOP rectangle appear on the parent somehow.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Luke Iannini (pd) -
Phil Stone