I, uh, kinda flash most of my builds with older firmware. Not sure what goes with what anymore. Sure, some new lights have Anduril 2 and I seldom buy a light that doesn’t have my favorite firmware. My newest version is from Dec 2018.
Maybe retaining the same functions as before, but 4H for the tint mode switching?
I like alternative C most
Edit: I am dumb and can’t read. C is perfectly what I imagined
I do use 4C from ON with my kr1 because most of the time it’s on a table and I want it ready to go, but when in use4C from ON is convenient.
Option D is a modified C that puts ramp shape at 5C, channel ramp at 4H, and retains momentary turbo at 3H :
-
3C tint toggle with an added all channels on (justification below)
-
3H: momentary turbo
-
4C: lockout
-
4H channel ramping
-
5C toggle ramp shape
-
5H sunset timer
-
6Cmomentary
4H: I figure that tint ramping is slow anyway so 4H is fine (especially since there’s the faster channel toggle already). 3H I miss momentary turbo a lot, especially since I use Anduril2 style turbo on my cct switching d4v2; ramp up then 2C sucks. 5C ramp shape toggle: I don’t need quick access to ramp shape toggling because, while I do use it (work/outdoors mode vs smooth indoors), I don’t go back and forth between them. 6C momentary I accidentally toggle momentary mode way more often than I actually use it (almost never).
3c with the added mid-ramp tint/all channels: I don’t really need the cct in between but I do like to go back to mid-cct (all on). Current workaround I have is to use manual memory set to mid tint (another is hybrid memory with a very short (1min) memory). I guess that would mean having some new menu option to activate the “all channels” toggle, to accomodate flood+throw togglers or other usecases.
Edit: sorry, I guess its arrogant of me to have added a D option, maybe it’s too much of a break from current anduril… I just felt like it does address my usecase very well. (Next I’d love to have faster control on the aux leds haha)
Why not use Anduril 1 style turbo instead? Or set the ceiling to full power?
This would be inconsistent, since momentary would be 5C from off, 6C from on, or 5C from strobe. They should all use the same mapping.
I’m also hoping to keep tint-related functions on the same base number, like 3C + 3H or 4C + 4H. Hopefully as low as possible though, since tint functions are the primary appeal of some lights, so those functions should be relatively easy to access.
There are simply too many functions to provide access to, and not enough convenient button mappings to fit them into. Multi-channel lights really should have a 2nd button, with all tint functions on the 2nd button, but what should be and what is are unfortunately different.
The implementation I’m considering would use 3C to change between tint algorithms, and 3H to adjust the tint parameter. The parameter is a 0 to 255 value which controls the tint blend, while the algorithm is … something new. Some example algorithms are:
- 2-channel blend with constant brightness (power stays steady while changing tint)
- 2-channel blend with additive brightness (gets brighter at middle tints, or maybe has total brightness doubled with overflow spilling to the other channel)
- 2 channels locked together (i.e. 50% blend which can reach full power on both channels)
- 1st channel only
- 2nd channel only
- 3rd channel only
- 3-channel circular blend (like rotating the hue on lights with R+G+B)
Then 3C would rotate through these modes… but lights would only have modes which make sense for that individual light. Like, the LT1S has warm, cool, and red. So its 3C would rotate between…
- 3C: 2-channel white blend
- 3C: red only
- 3H from red mode: 3-channel circular blend
But a light with flood and throw channels might have this instead…
- 3C: flood only
- 3C: throw only
- 3H: 2-channel blend with max “200%” power
… and a white + red + UV light might use this:
- 3C: white only
- 3C: red only
- 3C: UV only
- 3H: momentary turbo
The plan is to make it relatively easy to configure (at compile time) which modes each light has. If you want “warm only” + “cool only” + “both locked together”, you could make a build config for that.
OTOH, using manual memory with a short timer is a good option too.
… and on top of all this, there’s still SammysHP’s stepped tint ramp patch to merge. That by itself might resolve things for you, since you could configure it for just 3 steps (both ends and the middle).
I use anduril2 style turbo because… it’s what fit my tint ramping light better. It’s for indoors so ramp 2C as a shortcut for a reasonablely low ceil is best. My stepped ramping’s ceil is set higher in case I go outside.
That’s awesome! So, with a build config I could also add 3H for turbo! (As per your last example).
I’m OK with alternative B remapping ramp shape toggle yo 4H.
Did you think it possible to add a tint algorithm toggle and have multiple configs loaded up? For example, setting an rgb light to white only so it becomes a regular anduril light (hopefully used with tr he right rgb leds that give a clean white color together… Maybe not the best example either). Not really a request yet at this point, just curious.
I’ve only ever really locked accidentally via 4C from on. It’s on my TODO to reorder some UI stuff in my modded version.
I run modded firmware on my dual channel lights, my current shortcuts are 5C to go to turbo on the first channel and 5H for momentary turbo, then the same with 6C/H for the second. I then have 2C be turbo on current channel, and 3C 200% turbo. At the moment I still have 4C to lock in there, and momentary channel switch on 4H but it’s been on my todo list for a while to move the 5C/6C ones down and remove 4C to lock or move it to a higher combo, and move the momentary channel switch higher because I don’t use it as much as I initially guessed I might.
Current: 2C single channel turbo, 3C 200% turbo, 3H channel switch, 4C off/lock, 4H momentary opposite channel, 5C ch1 turbo, 5H momentary ch1 turbo, 6C/H same as 5 but with ch2.
Next modded build I do will probably be changed to: 2C single channel turbo, 3C 200% turbo, 3H channel switch, 4/5C/H channel turbo modes.
To make room, I moved ramp style selection to 9C because I almost never go to stepped, and momentary and sunset modes to 12C/H. The other thing I added for dual channel lights is I made 8H do the opposite channel switch behaviour - e.g. if I configure instant switching for 3H, then 8H will ramp.
Usually I lock with 4C from off, or a timeout set to something fairly high like 0an hour (usually to match my automatic memory timeout so if it’s locked and I didn’t lock it, I know it’s going to go back to manual memory).
More modularity is a great thing, it would be nice to be able to configure in a header file how many clicks you wanted for each feature (or if you even wanted it enabled or not) based on your preference, that’s a longterm goal of my mod as I’ve been incorporating some other code changes from github as well.
PS. Really appreciate how easily extensible and moddable you made anduril, especially the separation between the low level hardware interfacing and the higher level logic, really makes it easy to mod for someone like me who’s not good at bit twiddling.
Yes, that is exactly the sort of thing the multiple-tint-algorithms thing could do, and it was one of the use cases I had in mind. A light with RGB could use, for example, two “tint” modes:
- Circular hue mode. The “tint” variable determines the hue, saturation is always 100%, and value is the regular ramp brightness.
- “White” mode. The “tint” variable is ignored. Saturation is 0. Value still uses ramp brightness. Individual LED brightness is determined by some sort of formula, to get the result close to white… like “1.0 red + 0.7 green + 0.4 blue”, or whatever blend looks the most neutral.
Then use 3C to switch between these two modes, or 3H to switch to hue mode and rotate the hue.
However, a RGB light would probably also need other changes in order to work well. Like, a full set of RGB blinky modes. I did an entire separate interface for my RAGB lightsaber (red / amber / green / blue), where it has a dozen different animated color patterns…
Of course I tried 4 - click lock / unlock in the process of learning Andúril.
But in practical use only once when a customer gruffly demanded, “Gimme yur flashlight!” (to use). I simply told him, “ You don’t know how to use it.” He openly scoffed at me. I easily and quickly hit four clicks as I handed my Noctigon KR4 over to him. He tried to light what he wanted me to repair. Then, directly handed my KR4 back to me saying (about the flashlight), “Broken!” I quad-clicked the light down by my side and used ramping brightness as I shown what he unsuccessfully tried to illuminate.
Even for just that single incident, I was very glad I had electronic lock.
So far, it looks like about 17% of people use “4C from On” sometimes. Of those, it sounds like about half wouldn’t miss it if it was gone. But the remaining half is still enough that I think I should probably keep that button mapping.
Instead, I think I might map something to 4H, which was previously unused.
The tentative plan is:
- On multi-channel lights only (i.e. with multiple sets of main LEDs, like warm+cool tint ramp or white+red+UV): Use 3C to change channels, and move ramp shape controls to 4H.
- On other lights (i.e. most lights): Keep things as-is.
That mostly keeps things intact, while greatly improving access to the unique features available on some lights. But instead of 3C always toggling the ramp shape, on some lights it would switch between tint modes.
That means “3C from On” would join “3H from On” as a mapping which changes depending on the light. 3H is momentary turbo on single-channel lights, or tint ramping on multi-channel lights. Both mappings basically activate whatever is most relevant for the particular type of hardware being used… with 3C being a hardware-dependent mode switch of some sort, and 3H being a hardware-dependent time-based function which lasts until the button is released.
Seems fine - in general, if one button combo is going to change based on the light, then having both aspects of the same number of clicks change does make more sense than having two different numbers.
Wondering if lock from on would be better as optional, perhaps selectable from the 9H or 7H config menus, although the question is what would replace it for 4C if anything if disabled. In terms of 3C from on, I think tint algo change is probably going to be much more used than smooth/stepped ramp switch, so the latter can probably be safely moved to a higher number of clicks (I currently have it on 9C on my lights)
Perhaps this type of situation is relative. Someone buying their first may find these changes illustrious and dive right in. But for those having multiple lights dating back to the origins, changes of this magnitude are at the very least frustrating. How many generations of change can most people keep track of, and in how many lights?
I must just have too many.
Sure is interesting to put em all in lightning mode though. (Providing I can remember how)
I have 28 Anduril powered lights. Just took a video with all of them running simultaneously. From 800 lumens to 25,000.
How do I post a video here?
Now, to lock em all out again…
( my eyes hate me )
A photo…
Nice…
Yeah, having the interface change a bunch of times is really frustrating. So I’ve tried to keep that to a minimum.
In this case, for lights with only one set of primary LEDs, nothing is changing. That covers most of the lights out there.
It’s looking like the only interface change will be for lights with multiple sets of primary LEDs… like tint-ramping lanterns, adjustable flood/throw lights, RGB lights (aux LEDs don’t count), items which can switch between infrared / ultraviolet / white, etc.
I’m trying to make it easier to access all those channels, without having to go through an arcane menu. Like, at the moment, if someone wants to switch between “tint ramp” and “tint toggle”, they have to turn the light off, press 9H to enter a global menu, release at the first blink, click 0 or 1 time, wait, then turn the light back on… and then 3H can do the tint changes they wanted. And tint-toggle is on 3H, which feels weird since it’s not the type of action which needs a “hold”.
Instead of that, the plan is to make it so the user can just press 3C to toggle the tint, or 3H to ramp it. Much, much easier.
The downside is, for lights with tint features, it’ll become a bit harder to change the smooth/stepped shape for the brightness ramp. That’s 3C on most lights, but on multi-channel lights it’ll get moved back to … 4H maybe? I’m not super happy with that mapping, but it seems like the least-inconvenient option.
If not 4H, it could be 4C… but then the shortcut to lockout is gone. Could be 5C, but then the shortcut to momentary is gone. Could be 6C, but that’s long and eliminates the intentional gap between regular UI functions (5C and below) and config menus (7H and above).
The 2 least-disruptive options are 4H and 6C. They are the 2 shortest mappings which aren’t used yet. … which I suppose leads to a question that I should probably make a poll for. More on that in the next post.
Poll
On single-channel lights, the usual mapping is:
- 3C: toggle brightness ramp shape (smooth / stepped)
- 3H: momentary turbo
- 4C: lockout mode
- 4H: (unused)
But on multi-channel lights, the plan is:
- 3C: next channel mode (like “flood / throw / both”, or “white / red / UV”)
- 3H: ramp channels (like warm-to-cool tint ramp)
- 4C: lockout mode (?)
- 4H: ?
So how should the regular 3C/3H functions be remapped? Which seems best? Mark all options you’re okay with:
- remap shape (3C) only
- 4C: lockout mode
- 4H: ramp shape toggle
- remap both (3C+3H)
- 4C: lockout mode
- 4H: momentary turbo
- 6C: ramp shape toggle
- remap both, and remove lockout shortcut
- 4C: ramp shape toggle
- 4H: momentary turbo
0 voters
Personally, I like the last option best since I don’t use the “4C from On” shortcut to Lockout Mode. I also don’t really use momentary turbo, and had kinda forgotten it existed. But some people do use those, and I don’t want to clobber features people care about.
I voted for remap both and remove lockout, but actually I’d just place lockout at 6C because why not? Id rather do 6C than 1C, wait, 4C.
On my lights, I moved smooth/stepped ramp selection to 9C, as I barely ever use it. That might be good for the subject of another poll - 9H is probably too high for most people but I need room for other custom shortcuts as well, but I’ve been entertaining the idea of moving it entirely to the 9H menu, but even just moving that to something like 4C frees up space for features that will probably be used more often, but has the breaking-backwards-compatibility problem…
In general, if I was giving my opinion on the options posted, remap both and remove lockout shortcut would be what I would go for, and “remap shape only” second place.
At the risk of some people going “more options bad”, there’s always the possibility of having a 9H menu item that lets the user select from a few different combinations. That way, based on principle of least surprise, have an option (the default?) that replicates the old layout with the new functions on 4C/H as well.
Moving lock to a higher number is also fine.
The 9H menu is a last resort for things which can’t fit anywhere else… generally things the user configures once while reading the manual, and never touches again. If a function gets used more than, I dunno, once a year… it probably shouldn’t be in the global 9H menu. I’d like it to not exist, if possible… but sometimes it’s unavoidable.
The jump-start level works fine in 9H, since it only needs to be configured once, on only a specific subset of lights, by only a small portion of users who actually care, and it can’t be set at the factory. However, the ramp shape toggle is meant to be used by pretty much everyone on every light, every time the user goes outside or comes back in… and sometimes even more often than that. It gets used enough that some manufacturers have even insisted on enabling it in simple mode.
One thing I can say about moving it to 9H though… that would guarantee virtually nobody ever used it again.
Customizing it locally is totally fine though. Different people want different things, so I tried to make it relatively easy to change stuff, or to even make completely new interfaces. I just don’t plan to include that particular change in Anduril in the official repository.