I have a “Squelch” momentary button that works great as a “trigger” with an “onClick” connection, but I do not see a way to do this for an AudioProcessorParameter. I would imagine triggered audio parameters (that automatically “re-arm” after use), would be used for various things. I see that JUCE has Button::setToggleable(true/false), but I find no corresponding property for the TextButtonItem, as I expected to find. Is there a reason for this, or is it just not implemented yet?
It is indeed something I didn’t see the use case so far. The question came up before, but in that case it was more like a drum pad, which I then implemented. For a drum pad a gui button would have been the wrong choice, because it is not properly timestamped for musical purposes.
The JUCE buttons have indeed that setClickingTogglesState() switch, and PGM sets this automatically once you connect a parameter:
https://github.com/ffAudio/foleys_gui_magic/blob/main/General/foleys_MagicJUCEFactories.cpp#L300
The sloppy answer would be you can add your own Button by adding a modified copy of the TextButtonItem. But I understand it would be nice to be able to just configure it. We just need to make sure, those who rely on the current behaviour don’t suffer too much.
Can you tell me a bit more of your use case? Does the re-arm happen once you release the button? Or when the transport stops? It feels weird to me for an AudioProcessorParameter to be controlled that way, but maybe I am just not creative enough to see it.
I can see arguments either way. The way I bumped into the question was when I tried to make an AudioProcessorParameter version of my Squelch button, and found I could not do it without tolerating a toggling TextButton.
More generally, I had implemented a lot of enables and other things as PGM properties, and then I remembered that my plugin had to be able to run headless. So, I changed all the properties to parameters. That went fine until I hit Squelch. Of course, I can use MIDI All Notes Off to trigger a Squelch, but I would prefer to follow the principle that every MIDI control has an associated GUI element, and every GUI element drives an AudioProcessorParameter. Maybe I’m being too theoretical here.
An argument against momentary button support is that it has no persistent state, so there’s no need to ever save it in a preset — it would always be saved as zero. On the other hand, my analog-modular instincts say that I should be able to generate reset strobes, stepper signals, clock triggers, and the like, as signals, even though they would never be saved in their active state. If we did in circuits, why not plugins?
In making button controllers for things like sustain pedals, my common practice nowadays is “lockable momentary” form. That is, they are momentary buttons that can easily be locked on, such as with a double-tap or second-tap (single-tap to unlock). Thus, both momentary and toggle functionality in the same button. It’s like being able to get caps-lock by tapping twice on the shift key of your computer keyboard. So, in addition to a momentary/toggle property in the TextButtonItem, I would ideally also like a “lock momentary with double-tap” property.