Initially I though:
Yes!
It’s a little awkward and for me would be impossible to figure out on my own. But would work.
But actually…
Current option:
Screw the tailcap back, find the button, click
Proposed change:
Find the button, click, screw the tailcap back
May have 1 grip change less in some cases. Not sure, I will practice the motions while I return from work but as of now it doesn’t seem substantially better.
Recently the concept of a configurable default mode has really grown up on me.
Some want lights to normally start with the last mode
Some want lights to normally start on moon
Some want lights to normally start with some intermediate mode (like 350 mA)
Some want them to normally start high
Being able to configure some default mode should work for all of them….and would work better in the case of turning the light on as the power is connected.
Thanks for your long post TK, it’s well worth reading.
Yes - In NarsilM, one full click (quick press&release) is ON and OFF - no delays. Again, calling a press&release a delayed on implies this operation is delayed -- it's not delayed, it's very quick in fact. I kind of tweaked out NarsilM for fast operation, some find that difficult, or difficult to learn but priority is always on quick responsiveness - I dont' like UI's forcing delays and try to avoid them. I don't care much for dbl clicks, triple clicks, etc. but we kind of have no choice there.
In NarsilM, a multi click sequence always acts on the first click (ON to last level -- priority given here), but 2nd, 3rd, etc. clicks are not acted on and the delay to action is minimized but configurable in a source code constant. I don't want someone doing a triple or 4 click operation and getting flashed with turbo on the dbl click.
Yes; I’m just not sure what to call each style. Perhaps press-on, release-on, and delayed-on? Normally I would describe it each time, but it seems to come up often enough that it’d be useful to have a name for things. I don’t really care what the name is though, as long as it’s reasonably easy to understand. Does this seem okay?
Press: Instant. Fastest possible response.
Release: Very quick. Wait until user releases button or holds long enough to be a “hold”.
Delayed: Unambigious. Avoids false starts in the wrong modes.
On
Off
NarsilM
Release-on
Release-off
Anduril
Press-on (moon), Release-on (mem)
Delayed-off
Mike C UI
Delayed-on
Delayed-off
I’m also not sure what to call the UI Mike C created. Does it have a name?
Why do you do this? Would you do this if firmware lockout is very easy and you knew that the driver has very little parasitic drain? I mean like taking over 1000 years to fully deplete a cell (if only considering actual current drain) ?
Physical lockout tends to be quicker to activate and deactivate.
Also it lets me work around what is a misfeature for me - mode memory.
If I had a light with no memory, good e-lockout ergonomics and OK drain I would probably prefer e-lockout.
With features like TK’s low momentary I would prefer it for sure.
As promised in another thread I’ll send you over some simple boot strapping stuff. I’ll make a zip file and PM you where to get it.
That’s a good suggestion, thanks. I do have a quick shortcut for a feature only available for my ramping UIs, I could use the same shortcut to make quick changes on “normal” UIs.
Personally I’ve focused on making it easy to adjust each brightness level while operating the light… No need to run any scripts, and no need to flash again if the spacing wasn’t right the first time.
OTSM simplifies things a lot. I don’t reboot on any short or long off press. I only reboot if off time is long enough to be considered a power off cycle (above 1 sec), or changes have been made to light configuration. My code for clicky switch actions is identical to my code for e-switch actions. It’s only the actual detection method of the presses that is different.
Currently I have a have a solution with E-switch that I like: Pressing and holding the switch on startup enables moon mode. If the light is locked it will turn off as soon as the switch is released. If it’s unlocked moon will stay on until switch input. So moon mode always works, regardless if light is locked or not. I haven’t found a satisfactory way to do this “moon while locked” with clicky switches. I haven’t yet implemented different lock levels either, but I’ll get around to that soon enough… I hope…
I did forget to mention the rather significant detail that I am using clock speed of 1 MHz. Fast PWM is pretty slow at 1 MHz. But I’m only using PWM on ~50mA, I don’t notice any flickering. Everything above ~50mA is constant current without PWM.
Correct. My E-switch multi-press detection is set to just under 1/3 of a second. My E-switch ramp down is double click and hold on that second click. I’d really hate it if the light did something between those two clicks. I did a trial with what you would call “delayed on” while keeping my “fully delayed off” but that was even worse, much better to have the same delay behavior for everything. I can live with a 1/3 second delay, I prefer that over having the light do things between clicks. Like my 3 press short cuts, I don’t want the light to do anything while I’m entering that 3 press shortcut, it would annoy the heck out of me.
I’ve now implemented the double tap. MascaratumB and chadvone gave me some valuable input for this, I’d never seen it before (locked in my own bubble). I now use it in two of the UIs, one of them is a new ramping UI I made specifically for this way of operating clicky switch lights. 200ms is actually the time I settled on after a fair bit of testing.
Yes, it’s OTSM makes this possible. With OTC it’s very difficult to get consistent results while detecting multiple off press durations.
Not really. I have 6 different UIs to choose from, and they all behave differently depending on which switch configuration is selected (off-switch, e-switch or dual switch). So using the name for the entire firmware doesn’t really work in this case. I don’t really have a name for the firmware either, rather low on imagination for that sort of stuff.
I think there are enough swords as it is. Besides, my firmware doesn’t need a name, it’s specific for my own drivers and won’t be adapted to any other drivers.
Progress is a little slow here as usual but lately I’ve got some stuff done and worked out some quirks so I should be able to get some of these drivers out the door soon. I have to take a break now though, heading out the door for another work trip, gone for almost two weeks.
David is right… Just ask how long he has been waiting on one of my drivers… I think as far back as the good old ATtiny85 days even
I’ve got a few more suggestions from this thread that I am going to implement when I get back from work travels, then I just want to start sending some. Changed working conditions unfortunately means less time for this stuff, but I’m hoping it won’t be much longer.
I hope you know I said that in the most lighthearted and not-pushy way possible. After all, this is a hobby for all of us, and you have a right to your own time. Not only that, but I’ve been busy lately myself and have gotten way behind on stuff, including some projects I’ve promised to do for other people quite a while back. So I really do understand completely. :person_facepalming:
I thought the standard terminology used by everyone is "click", being a full cycle of down/up, and then "press&hold". Reacting to the initial press, is of course, possible and a little quicker. A press without being a press&hold is unusual - not sure what manufacturer uses that, and how much faster a "down" is from "down/up"? I've played a lot of video games over the years, and sports with quick hand motions, so maybe I'm so quick and used to it I can't tell the difference?
I'd be more comfortable with: press, click, press&hold
I have a bit more work to do but should be able to announce giveaway winners shortly. I’m going through the posts with more detail, putting together a list of the remaining suggestions I’m going to implement.
While doing so I read a suggestion that I missed before:
I’ve never heard of this so I have to ask, why would you want this? If you have press & hold for brighter, and double press & hold for lower, why would one want this wave like behavior?
If you are on the back side of the wave where mode level is going down, the mode presses will be reversed. You’ll have to remember which side of the wave you where on. To me this would only make sense if you only have mode up function on your light, and no mode down. Or am I missing something?
]