[PD] Patchmatrix Execution Order Issues

Luke Iannini (pd) lukexipd at gmail.com
Thu Jan 18 01:24:42 CET 2007


I am aware of the stack overflow possibility, and I'll probably block
out routings that would cause that.

The intent is for the input to reach all outputs before any new input
is processed (i.e. before any new input changes the routing
configuration of the spigots).  I see my mistake more clearly now, but
the solution has not reached me yet.  I could buffer the inputs with
[f] or [fifo]s, but that seems like it will become untenable; I'll
keep trying.

The goal is a patchmatrix that can accept "looped back" inputs.
Perhaps this is not possible with the idiom I've built here.

The particular case that exposed this issue for me (so that perhaps
the practical application of this can be understood):
I have a sample-player with varispeed, triggered by a drum pad
(connected via the patchmatrix).  The drum pad also triggers (again,
via matrix) the next values of 3 arrays set up as an "analog
sequencers".  The output of the sequencers also comes into the
patchmatrix so that I can route it to say, the speed or start-point of
the sample-player.

I suppose I need my patchmatrix to be "polyphonic" if that makes any
sense... I'll try something like that next.

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!

On 1/17/07, Frank Barknecht <fbar at footils.org> wrote:
> Hallo,
> Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
>
> > This will of course all be clearer if you are viewing the patch.
> > Assuming you are now:  in column 1 of the patchmatrix on the upper
> > left, enable outputs 2(Y) and 3(Z) (such that the matrix looks like
> > this:
> > 0 0 0
> > 1 0 0
> > 1 0 0
> > ).
> >
> > Now, in the top right, send "10101" to input A (this is an arbitrary
> > value for demonstration).  Over on the right, you'll see that it
> > reaches output Z but not output Y.  This (as it is easier to determine
> > now - my actual configuration is a 9inx17out matrix that connects most
> > of my library of patches, hence the 16 hours of debugging) is because:
> > output Z feeds back to input C, thus retrieving column 3 of the
> > patchmatrix, which is set to send to no outlets at all (0 0 0).
> > Apparently, by the time "10101" reaches output Y's spigot, it has
> > already closed.
>
> Yes, that's not only apparently, that's the way it is patched ATM.
>
> But actually even worse things can happen: If you make your matrix
> like this:
>
>  0 0 0
>  1 0 1
>  1 0 1
>
> you will get a nasty stack overflow!!
>
> > If anyone is still following... how can I make this work?
>
> Could you specify a bit more how exactly your patcher should behave,
> because I still didn't quite figure this out.
>
> Ciao
> --
>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>




More information about the Pd-list mailing list