OK, this is about the 16th hour (2 nights now) I've spent attempting to debug this, so I'm capitulating and asking for help : ).
There was a discussion of a signal patchmatrix a while back. I'm attempting to make a message-based version of the same thing.
Attached is a version completely stripped of all but the essentials, to demonstrate the issue hopefully as clearly as possible: I'm using IEMMatrix to store the patchbay configuration. In the example, there are 3 inputs and 3 outputs. The "patmatel" object is simply to set matrix elements to 1 or 0.
When an input comes in a particular inlet, say inlet 1, column 1 is retrieved from the matrix. The contents of column 1 enable or disable the 3 outlets. E.g., if inlet 1 is meant to go to outlets Y and Z (but not X), column 1 would contain 0 1 1.
Next, inlet 1's actual value is sent to the 3 spigots, which either allow it through or block it.
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.
If anyone is still following... how can I make this work? I guess I need to delay the inputs from arriving until the outlets are finished transmitting, but I'm a bit lost as to how to do that elegantly.
P.S. An [mtx_spigot] object would be great for this type of thing : ). I have it on my list to attempt an abstraction of such an object. [mtx_mul~] works just like I'd want the message-based version to.
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__
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
Hallo, Luke Iannini (pd) hat gesagt: // Luke Iannini (pd) wrote:
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.
Hm, I'm still not clear about how the routing should look like. Maybe you can give a kind of more formal specification: Assuming you have a (m,n)-matrix with m rows and n columns. With m=4 and n=3 this will be printed through mtx_print as:
matrix: 0 0 0 0 0 0 0 0 0 0 0 0
A signal~ matrix [mtx_*~] will have m=4 outputs and n=3 inputs then, that could be selected with the above message matrix. Setting element (i,j) to 1 will open outlet~ i for inlet~ j then.
Back to the message patchbay: How should this behave, if you set element (i, j) to 1? Using the signal analogy I would assume, that all messages "sent to inlet j" (that is, [list prepend]'ed with j) should be "sent to outlet i" (that is: the first element of the new list, which was j, will be set to i so that you can [route] it), but from your patch it seems you want to achieve something different?
Anyways I attached a message-patchbay which works like I proposed to illustrate what I mean.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Luke Iannini (pd)