I’ve got some buttons on my MIDI controller setup to send a single CC value every time they’re pressed. That way I don’t have to discard unused ‘OFF’ or 0 values. So I make widgets to represent these buttons. However when scripting for these button widgets, I’m finding the “On WidgetValueChanged” function doesn’t fire properly, presumably because it doesn’t update on repeated sends of the same widget value, if I’m not mistaken. Is there another function that would update correctly in this circumstance?
Thanks,
-M.
Edit: Current working solution is just to set the widget 's value back to zero inside the “On WidgetValueChanged” function. Easy enough.
Continued Edit: Realizing this does however present the problem of the “On WidgetValueChanged” function double firing. Not an issue with my current implementation, but it’s sloppy and could be problematic later.
I’m assuming you are doing other things that require scripting to be used?
If so, you could not midi learn the widgets to the CC messages, but instead monitor the incoming midi messages via those GP script callbacks and then do whatever updates to widgets that way.
Hey rank,
Yeah, definitely could and have before. Just trying to observe what I assume to be the intended operating procedure.
Thanks for the response!
Hi @mechanica, if it works for you, you can set the widget properties to momentary to latching: one push ON, a second push OFF. If you absolutely want a momentary behavior, than scripting is mandatory. In the On WidgetValueChanged test the value for it to be 127 (or whatever your controller produces) and only do something then and also reset it to 0. Of course the On WidgetValueChanged will be fired twice, but this also happen with a two-states controller button. The only drawback here is that you will possibly not notice from the widget button behavior that you pushed the button as it will be very quickly be reset. You could elegantly solve this issue using a Gig script to transform your CC# value 127 to a CC# value 127 followed with a delayed CC# value 0. (If, I don’t remember, we can Inject MIDI messages later )
Would it be an option to configure your controller (which ever it may be - you didn’t tell us) so that the buttons behave as they do on most of the other controllers in the world?
Means: Pressed → Max. value / Released → Min. value
@David-san, momentary latching is very much the opposite of what I want. That results in an unnecessary binary, which is the thing I’m trying to avoid in the first place. The rest of what you mention is essentially what I’ve already done. It’s surely not a problem, I just don’t like the superfluous signal being sent. It strikes me as a bit messy.
@schamass Yes, certainly an option. But again, this creates the annoyance of an extra signal that I have to then discard/ignore. Not hard, but still.
All in all this really isn’t a big deal I guess. Just would be nice to be able to listen for repeated widget values. Requiring them to be unique is great as an optional constraint, but is a tad cumbersome as the default and only approach.
What do you mean by that? If you would have a two-states switch on your MIDI controller, it would also call the callback twice, so I don’t understand your concern.
I think @mechanica wants to send always for example CC14 value=127 and a widget is mapped to that CC.
Now everytime the Midi Controller sends CC14 127 the on WidgetValueChanged should react on that.
Which is not possible be cause it doesn’t produce a change to the Widget value. That’s why he sets the Widget value to zero again (which can also be done in a gig script) which causes of course a second call of the callback as it would be with a regular controller producing CC 0/127. Which explains that I don’t understand the concern of a second call of the WidgetValueChanged callback.
As I understand his controller only send CC ?/127 and with each sent message the widget should react.
And that is not possible out of the box.
The main question is: why is that needed?
)