That’s definitely one of the options I’m considering. It would then be possible to configure the simple UI, but only while the advanced UI is active. For example, it could keep the aux LED settings and maybe the ramp type and manual memory setting, but set a different floor and ceiling in simple mode. It could potentially also allow setting the simple-mode floor and ceiling, though I’m not sure how the UI for that would work.
That’s an interesting idea which hasn’t come up before.
It could perhaps do “low-floor high-floor” when manual memory is off, or “low-floor manual-mem” when manual memory is on?
It may end up with gaps between some of the functions which require more than a couple button presses. However, most of the parts which people get mixed up won’t be enabled in the simple UI so I suspect this type of issue may become less common.
It’s something which has come up a few times. Normally I’d suggest setting the ceiling to turbo, since that’s kind of the point of having an adjustable ceiling. But perhaps there needs to be more discussion about the various tradeoffs here, whether it’s worth having a separate ceiling and a shortcut from off to turbo, and what would have to be sacrificed to make that happen.
Like, there’s the question of what 3C should be. It could be a turbo shortcut. Or it could still be battcheck. Or I’ve been thinking about whether 3C should go to lockout, to make lockout more convenient to access.
There’s also a question of what 2H should be. It’s currently “go to ceiling and ramp down”, but maybe it doesn’t have to be. It’s nice for symmetry and consistency, but I never really use it and I’m not sure if anyone else does either. Perhaps it could be mapped to something else instead. There’s no shortage of other functions which could benefit from a shorter button mapping.
I’ve been thinking the battcheck function should exit after it finishes one readout, when the user is in simple mode, like the version check does. This may help people avoid getting stuck. Can’t do that with lockout mode though.
It depends on the light and the brightness level being used. The formula isn’t great at adjusting to the full variety of configurations where it runs. It could also really benefit from higher resolution in terms of time and brightness, to allow for smaller / smoother changes. If I figure out a good way to do it though, I’ll probably do it.
This has come up a few times, and I think it’d be a good idea to add it. There might not be room on tiny85-based lights though, so it could potentially be tiny1634 only or otherwise be enabled on a per-device basis.
The blink is only there on some lights, where it’s relevant. Mostly just on FET+1 designs. It’s not there on some other lights, and I’ve been wanting to remove it on more. However, it’ll still blink at the ceiling.
One thing worth mentioning though… With the blink gone, it’s much harder to hide imperfections in the joints between different ramp segments. If the slope changes, it’s much more noticeable. So it’s often not difficult to tell where the segments join, even without the blip… which is both a good and bad thing.