Prevent a widget of type button to be "pressable"

Community Usage questions
1

Hi,

i want to make a button unpressable when a switch has defined value.
In the custom module of the oscoutfilter i catch this condition.
So far so good, but now i guess i have to set button property "ON" to 0 ?
tried it this way

....
receive('127.0.0.1','9000','/addy',{type:'on',value: 0});
....

and off course enabling when the condition of the switch is "good".

but no luck so far(bypass or interaction is no option, it should stay off aka "unlit"), i found no example here how to disable a button...

Thanks!

2

I wouldn’t use a custom module here (on a side note, sending {type:‘on’,value: 0} to a widget won’t change its òn property, you can only change the value this way. To affect properties you need to use osc listeners or the /EDIT command).

Using interaction is actually the most logical choice here, but if you want that state to be indicated visually you could add some css:

:host.no-interaction {
  filter: grayscale(1);
}

If you want to make sure the button’s value is set to 0 when the switch is set on a particular value, then use that switch’s script to do it.

Note: the interaction property is always ignored when the editor is enabled.

3

Thanks! I allready tried it with interaction, but i had the editor enabled :slight_smile:

#{@{id} == 'xx' ? "false" : "true"}

What i struggle now is the fact that i can't send and catch the preargs from the switch to the custom module.

Tried:

["XX","YY","ZZ"] // suspected args[0/1/2].value
XX YY ZZ //suspected args[0].value.substring(3,2)
{"off" : "00", "wah" : "01", "wahwah" : "02"} //something like args[0].value.off ???

What did i not understand here ?

Thank you!

4

quotes around true and false are not necessary. Also #{@{id} != 'xx'} would be enough.

Tried:
[“XX”,“YY”,“ZZ”] // suspected args[0/1/2].value
XX YY ZZ //suspected args[0].value.substring(3,2)
{“off” : “00”, “wah” : “01”, “wahwah” : “02”} //something like args[0].value.off ???

I don't understand what this code is and were you wrote it

5

{“off” : “00”, “wah” : “01”, “wahwah” : “02”} //something like args[0].value.off ???

In this case, the value sent by the switch would be either "00", "01" or "02". "off", "wah" and "wahwah" are only used as labels in the interface.

In the custom module, the args variable is always formatted as follows:

args = [
  {
    type: "OSC_TYPE_LETTER", // "f" for float, "i" for integer, "s" for string, etc
    value: VALUE
  },
  {
    /* etc */
  }
]

You can always retrieve the value with args[index].value

6

Thanks, i forgot to mention these are preargs not from the property values. (beside the selected value i need to pass more strings to send the correct sysex and control midi messages).
One “clumsy” try could be sending all needed information in the values property…

7

Once send, all arguments are seen as items in the args variable, no distinction.

8

Ok got it, thanks.
Now i am stuck at another point...

Is there a chance to alter a switch widgets "values" property to a specific value in a custom module?

I have an incoming sysex string and i need to set it in oscinfilter. (the hardware sends the correct value while loading).

{ "off" : "00",
"wah" : "01"
.....
}

When i got a hex "01" by sysex, the switch "wah" should be selected.
I can't rely on any other trigger, and receive just updates a value, but not the current "selected values object"...

9

I'm not sure to get it: sending a value to a switch widget does update its selected value, for instance receive('/switch_address', PREARGS?, "01") would select the value with label "wah".

10

Hmm, i allready tried that, does it matter if the switch is in a modal widget (seems so, if the switch is in the “root” of the tab it works)…
Is there a way to update this nested button via receive? Thanks…

11

It doesn't matter, I just tested it without issue. I can check your session file if you want.

12

Yes please have a look!

I took a detailed look at the console.log / debug output.
Noticed that i receive multiple incoming messages.

if a ‘00’ is received the interaction of “kempStompA” is greyed out correctly (and “off” correctly on "kempStompAFXSel). If something != ‘00’ is coming in the label of "kempStompAFXSel still says “off”, interaction is disabled (which is false too, but the color is different than before???).

The interesting part is line 67 in the custom module.

OpenStageControl4reaper_10.json (821.9 KB) openstagecontrol4reaper_v4.js (11.5 KB)

13

The widget “stompASel” has preArgs, you need to match those if you want the message to reach the widget. The problem is that you’re defining preArgs depending on the value, quite a mess to be honest ! :smiley:
I would recommend simplifying things on the interface side and keeping the complex routing logic in the custom module if want to avoid this kind of issue. However it is possible to declare another address for updating the widgets value by using the osc listener syntax in its value property, it allows ignoring the preArgs.

14

:slight_smile: yes it is quite a mess, i got rid of the preArgs, and did it in the custom module.

Working good so far(just the not matching preArgs messed it up).

What exactly would you simplify here (e.g. there are four stomps, which have the same values and css, easily retrieved with @{id.css}) ?

What is not ideal is the label of the modal.

JS {{
var values = @{stomp@{this.variables.stomp}Sel.values},
v = @{stomp@{this.variables.stomp}Sel};
return Object.keys(values.find(k => values[k] == v);
}}

When doing @{xxx.label} it resolves to the first label, not the actual choosen of the copy.
I think it is the order of resolving variables. (maybe use #{} instead of JS {{}} ?).

15

You have to override the cloned widget's id with the props property if you want to retrieve its properties and not the original widget's.