search

starryalley / Anduril2

my Anduril2 fork that provides much more features
GNU General Public License v3.0
47 stars 3 forks source link

IDEA: make tint ramp speed configurable #15

Open webshadow opened 1 year ago

webshadow commented 1 year ago

It would be great to have the equivalent to brightness ramping config.

starryalley commented 1 year ago

It's a good one. I kind of feel that tint ramping speed is a bit too slow for me so I switched to stepped tint ramping (by SammysHP) for all my tint ramping lights (5 or 7 steps). I'll see what I can do when I'm free.

ToyKeeper commented 1 year ago

For what it's worth, I added stepped tint ramping in my multi-channel branch, which should get merged into trunk shortly after I finish updating all the build targets to use the new channel system.

The new code also makes tint ramping in general somewhat less necessary. Like, if someone wants to use a specific middle tint but also use the endpoints, in the old version, they have to ramp back and forth, and the middle tint can be hard to hit exactly. In newer versions, they could instead just use 3 channel modes -- channel 1 only, channel 2 only, and an adjustable blend. Then they only have to hit the desired middle tint once.

The user can also activate manual memory (optionally with a timer), which saves and restores the current brightness, channel, and the extra parameter for each channel. So after getting the tint just right, save it, and then it's easy to go back to.

But I don't have any features to specifically slow down tint ramping. I feel like it's already too slow on most lights. However, on lights where one channel mostly overpowers the other, the usable middle range can be pretty small.

SiteRelEnby commented 1 year ago

Yeah, seems like the sort of thing where to have a perfectly consistent experience you'd need to optimise the config per-driver and per-LED-set, probably also ties into the ramping code which is one of the parts I've not done a really deep dive into yet.

ToyKeeper commented 1 year ago

you'd need to optimise the config per-driver and per-LED-set

Exactly. It uses a linear blend by default, but some lights need very non-linear curves in order to look "linear". And this is very hardware-dependent.

The firmware, however, is generally a single .hex file for a whole bunch of different hardware variations... especially when Hank is involved. I can't make custom calibrated builds for every hardware config he offers, and even if I did, he probably wouldn't use them... because it would be a huge mess.

So there isn't much I can do that I'm not already doing -- try to make things as non-hardware-dependent as possible, include enough options to cover almost any hardware config, and make the source relatively easy for people to customize and reflash.

The new channel system is, I hope, easier for people to tune to fit specific hardware needs. That's kind of the point of it. Someone could, for example, copy the calc_2ch_blend() function and make the copy use a non-linear curve... and change one line in each of the set_level_white_blend() and gradual_tick_white_blend() functions, to make it use the new non-linear calculator. (using the LT1S Pro as an example... details may be different for other lights)