Matrix usage of switch

Hi,

in a matrix i have two types of adress i send out, depending on a menu widget selection.
The type of the matrix is set to button.

1.) props.mode = "push", when pushing a button in the matrix, the message is sent out twice
how can i avoid this (props.off = null did not work, because it has to be address for each )?
2.) in the matrix props i have

labels = OSC {xxxx,'',true}

when changing the category with the menu widget the props(jjs script) is running for every element in the matrix (because of @{menu.values} syntax ).

-> the menu is changing the matrix twice when switch from one category to the other (value of @{menu.values} seems to trigger that )
-> should i avoid @{xxx.yy} here to get rid of this problems ?

Thanks

  1. "tap" mode prevents sending a message on release
  2. from Properties reference - Open Stage Control

Advanced syntax blocks (@{}, OSC{}, JS{{}} and #{}) are resolved at the matrix' scope (ie @{this.variables} returns the matrix' variables property, not its parent's)

If you want to have scoped advanced syntaxes you'll need to use a matrix of clone widgets instead (see clones_and_variables.json example from this thread.

EDIT: after reading point 2 again, I think I missed the issue.

Just to clarify, @{menu.values} is not related to the menu's actual value.

the props(jjs script) is running for every element in the matrix

Yes, that's how this property works, it's evaluated for each child (with a different different value for $ in JS blocks)

Thanks,

at the end of PROPS i decide if i send out a program change or a an addy (for sending a control change later in the custom module).
can i avoid sending out the unwanted sendings?
(when changing the matrix every child is parsed, i think this is sending out a lot of values -> i maybe use an osc listener to abort the sendings)

Widgets don't send any value when they are modified (unless their value property is updated as a result of a user interaction).

at the end of PROPS i decide if i send out a program change or a an addy

Why not decide that in the custom module directly ?