plem

Maybe I just didn't sleep long enough over this. But...

I did build some synth modules (osc, filter, etc.). Now I want to put all there inputs and there outputs in a matrix~ (and matrixctr) so I can change their order. I connected all the inputs. When I switch fi. input 0 to output 0 with a levelmeter connected there all is well. But when I connect the module output to the matrix~ input (fi. 8) the soundflow stops (feedback? But no connections in matrixctr and even after a clear-message in matrix~ which should kill all connections. So no feedback. BUT?

Would love your help on this. (It's a complicated patch so I will send no copies now. But if needed...)

Maybe I just didn't sleep long enough over this. But...
I did build some synth modules (osc, filter, etc.). Now I want to put all there inputs and there outputs in a matrix~ (and matrixctr) so I can change their order. I connected all the inputs. When I switch fi. input 0 to output 0 with a levelmeter connected there all is well. But when I connect the module output to the matrix~ input (fi. 8) the soundflow stops (feedback? But no connections in matrixctr and even after a clear-message in matrix~ which should kill all connections. So no feedback. BUT?
Would love your help on this. (It's a complicated patch so I will send no copies now. But if needed...)

matrix

It's a kind of safety-mechanism where the signal-network is auto-detected as being routed to itself within the patch by patchchords and the objects/signals effected are cancelled(that's just my explanation). To bypass this issue, use send~ and receive~ objects.

Unfortunately, if you use hundreds of send~ and receive~ objects, it will take up more CPU than routing directly, but hopefully you can find some sort of balance. (Another solution would be to figure out a way in which matrix~ cannot connect an output to the input of the same module at all.)

This patch explains your problem and a solution:

It's a kind of safety-mechanism where the signal-network is auto-detected as being routed to itself within the patch by patchchords and the objects/signals effected are cancelled(that's just my explanation). To bypass this issue, use send~ and receive~ objects.
Unfortunately, if you use hundreds of send~ and receive~ objects, it will take up more CPU than routing directly, but hopefully you can find some sort of balance. (Another solution would be to figure out a way in which matrix~ cannot connect an output to the input of the same module at all.)

Thanks for your clear remarks. The send/receive trick is very welcome. A more principal solution of preventing matrix~ of creating feedback-loops would be in the hands of the Cycling-guys, I guess.