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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list