Thanks, and sorry for taking so long to respond - my time to play around with things has been limited lately, and I’ve been trying every different possible solution I can think of. I had seen the stuff on the general mechanics page, but had thought sending an OSC message might override the widgets updating each other. Thanks for clarifying
I’m using both a script widget and a custom module because my goal is to be able to chain key commands together (i.e. pressing command A triggers command B to also run). I found it difficult getting the properties I wanted access to from a custom module by itself, so I’m running everything through the script widget to get those props easier and delegating the keypresses themselves to the custom module.
I’ve developed 2 solutions that work, but I’m not sure which solution is better:
- The first uses just OSC messages (setting the address of a button to my script), working around the issues I referenced above
- The second uses
set() like you mentioned to set the value of the script widget to the same as the button being pressed. This makes the logic easier to handle, but makes the button setup a little more complex for adding new buttons.
My goal with this is to make it so that others could build off of my session json file and add their own arbitrary commands…but hopefully with as limited interaction as possible on their part and not really needing to understand how it’s all connected up. Neither solution above is as “elegant” as I was hoping to achieve…I tried using the 2nd method (
set()) and cloning a “template” button with everything wired up, but then the
id param received by the script widget is always the master widget’s ID, and not the clone’s. Not sure if that is the expected behavior or not for a clone? I expected the script to receive the id of the actual widget being pressed, not the master id.
Once I can get things a little more clean I’ll get it uploaded for others to try out!