router bug ?

monohusche's icon

Hi there,

for assigning different inputs (user actions) dynamically to outputs (system activities), I am using the standard [router] object.

Unfortunately, the whole thing kind of fails if the triggered activity tries to change the interconnections within the router object, eg. a certain user activity (button x pressed) changes the way future inputs are routed.

When using router for that, it leads to stack overflows as the control messages sent to the left outlet get routed through router as well.

The same thing implemented with [gate] works as expected.

Max Patch
Copy patch and select New From Clipboard in Max.

pls see the example patch and let me know where I am wrong.

ch's icon

Hi,

Max Patch
Copy patch and select New From Clipboard in Max.

it seems you've found a bug. the "control" is linked to the output. weird.

jvkr's icon

Not sure whether it's a bug. There's a number of objects that don't allow output to control input in the same scheduler thread, even when the input doesn't directly trigger output. I believe with (a number of) zl objects this is the same. Deferlow always comes to the rescue in such situations.

monohusche's icon

Hi jvkr,

is that documented somewhere, e.g. which objects etc. ?

cheers, nick

jvkr's icon

Not that I'm aware of. Normally these things are discovered en route.

_
johan