[PD] Patchmatrix Execution Order Issues

[Luke Iannini (pd)]

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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: message-patchbay-modified.pd
Type: application/octet-stream
Size: 4117 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070119/77bc9e46/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sft.patmatel.pd
Type: application/octet-stream
Size: 955 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070119/77bc9e46/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Polymatrix.pd
Type: application/octet-stream
Size: 10259 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070119/77bc9e46/attachment-0002.obj>