If I’m to follow the code for Fundamental/Mutes.cpp at v1 · VCVRack/Fundamental · GitHub, which is a very similar use case, it looks like I’ll need to track the state and handle the saving and loading myself. No big deal.
I also used a wrapper for SvgSwitch for my standard lit pushbuttons.
So you don’t want to look at mine, but the same stuff from the count is good? What have I done to deserve this?
I’ll contact you directly.
Sure, here you go:
https://github.com/countmodula/VCVRackPlugins/blob/v2.0.0/src/components/CountModulaPushButtons.hpp
Note this uses a customised light as my buttons are rounded squares not circles so you may be able to simplify it a bit if you are using round push buttons.
I also use custom helper specifically for lit buttons to allow m to specify the correct light ID when adding the button in the widget.
1 Like
Good idea, I’ll make a LEDSwitch and LEDLightSwitch type that is not momentary. It will use up/down frames but behave like a SvgSwitch, such as BefacoSwitch.
3 Likes
ouch ! too late for me…
I have already about 2000~3000 LedLight switches …
4 Likes
Looks like you probably have this sorted but we do something similar on our ShapeMaster Run button if it’s of any help
1 Like
Thanks, I appreciate the input! 
I need a name for a boolean setting in SvgSwitch that makes it draw frames 0 and 1 for the mouse up and down states, rather than draw the frames corresponding to the switch value. “Latch” is the best idea I have, but it’s not a very obvious name.
Switch::momentary makes the switch behave like a momentary push button. When pressed the param value is set to max, and when released it is set to min. This causes frames 0 and 1 (assuming your switch has 2 frames) to be used when the mouse is pressed and released.
The SvgSwitch::latch setting will make the SvgSwitch directly draw frame 0 when the button is pressed and frame 1 when released, while using the normal (non-momentary) switch behavior of cycling param values upon each mouse press. Frame indexes will not be based on the param value, only the mouse press state.
What is a better name for latch? New component classes with names like BefacoLatch will be created that set this boolean to true.
Sorry, that’s a tough one. I’m not sure. Maybe “toggle”?
“Toggle” is too general because all two-state switches toggle between two values.
1 Like
Maybe “SoftLatch” to distinguish from something that latches physically rather than electronically?
push might work. Class names would be BefacoPushButton. The name “push” wouldn’t really mean anything, other than being a unique recognizable word to describe the switched button.
On second thought, “push” doesn’t really work because it doesn’t suggest that the button cycles through 2 or more states any more than “button” does. “Toggle” works better, although it’s too general.
My view is that the latch is actually physical. When clicking this type of component, the button physically “latches” into an ON state, and on a second click, unlatches. The key idea of a “latch” button is that it looks the same when latched/unlatched, but has a down/up state while clicking. So I think I’ll go with SvgSwitch::latch and BefacoLatch, etc. unless there’s another suggestion that works better.
1 Like
For inspiration, here’s the Android “togglebutton”
And if you implemented those as an SvgSwitch, the setting in question would be false, because you would use two frames, one for OFF and one for ON, not two frames for mouse pressed/released states.
Therefore, your article is evidence that “toggle” should not be the term to describe the setting in question.
Interesting question!
I think there’s a big problem with using “latch” for this (very useful) kind of button: a normal SvgSwitch (moving through param values, with correspondingly different displays) is already latching. The most common example of a latching switch in the sources I looked at was a light switch. From what I can tell, latching is typically used as a synonym for “alternate” or “maintained,” simply meaning the opposite of momentary.
The best real-world term I’ve found for the switch type I think you’re describing is “non-locking” (versus “locking” or “self-locking”). This seems to be more common outside the U.S., for some reason, but I think it consistently indicates whether a switch resets to its original state after being actuated.
So momentary switches are (almost?) always non-locking (otherwise they would be physically confusing), but some latching switches are non-locking and some latching switches are locking.
A latching, self-locking, two-state push-button switch would have an “out” frame and an “in” frame that corresponded to the two internal states–just like a light switch, but a button that’s locked in or out instead of a switch that’s locked up or down.
A latching, non-locking, two-state push-button switch would be like a cheap guitar pedal stomp switch; each press changes the internal state, but it returns to the same physical position no matter what the press is (because it doesn’t lock in the down state on every other press). And this would generalize perfectly to more than two states.
Put formally, I think we’re talking about this (with OFF and ON being the states and out and in being the frames):
-
OFF|out; click => ON|in; release => OFF|out(momentary, which implies two-state and non-locking) -
OFF|out; click => ON|in; release => ON|in; click => OFF|out; release => OFF|out(latching, two-state, locking) -
OFF|out; click => ON|in; release => ON|out; click => OFF|in; release => OFF|out(latching, two-state, non-locking)
edit: a more physical interaction pattern for the latching, two-state, locking switch would probably have the second click go to OFF|in, but I suspect that’s less typical in software.