I have a working prototype that uses buttons to send arbitrary keystrokes to the host computer similar to what was mentioned in some other threads. I’m trying to refactor it to make adding new buttons a little more streamlined.
The basic idea is that my buttons send a value to my script widget, which then sends an OSC message to a custom module that processes them as keystrokes, which I have working. The problem, however, is that I want to be able to chain shortcuts, so a button can trigger other buttons to send their shortcuts as well. I’ve tried using the preArgs, but as soon as I add a preArg to my button, the script widget no longer receives any values. I’m not sure if this is a bug, or the intended behavior. If I use the button’s script property and send multiple arguments (i.e. send('/script', '1', '2', '3', '4'), the script widget receives all values as expected.
Hopefully that all makes sense. Thanks!
After trying some more testing, it looks like this might be me not completely understanding how the OSC protocol works (once again). I can see from the server debug that the OSC messages are getting sent from the button to the script (4 messages total - “on” out/in, “off” out/in), but the script widget’s script property only gets executed when the preArgs match for both widgets. Is that how the OSC protocol is supposed to work?
Looks like I can get around this behavior by setting the value property of the script to OSC{/script} - the script gets executed every time it receives a value. What’s confusing to me is that using the send() function from the button widget’s script property works every time as expected, including consecutive button presses in tap mode, whereas the OSC messages sent by the default button press do no.
If I use the method above, I need to be able to send consecutive presses of the same button to the script, so if I use the method above, it also looks like I’ll need to use set mode: push. Will just need to ignore the “off” value that gets sent.
as soon as I add a preArg to my button, the script widget no longer receives any values
If you are using osc messages to send the value to the script, then that's expected (General mechanics - Open Stage Control). It's not necessary to send an osc message for widgets to communicate, for instance you can use the set() function in the button's script property.
Why use a script widget anyway if you're going to process the values in the custom module ?
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!
There's another option to connect the buttons to the script widget : you can use the iinkId property, for example
- button's linkId:
>> arbitraryId (only send)
- script's linkId:
<< arbitraryId (only receive)
note: use the same arbitraryId to connect widgets
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
You can override the cloned widget's id in the props property:
{
"id": "different_id"
}
This is different than changing the clone widget's id property (the "clone widget" is a wrapper for the actual cloned widget) .
@smith.kyle it would be really great to see this if you would share it with the community?