More optimize

DETAILS.md

@@ -22,10 +22,10 @@ On every `loop()` call (~60 times per second):
 
 1. Check the button for events; switch show if needed (`load_show()`).
 2. Read the current step from `SHOW[].steps` in PROGMEM.
-3. Compute progress `t = elapsed / duration_ms`, clamped to 0.0–1.0.
-4. Blend `s_from_color` toward the target color by `t`.
+3. Compute progress `t` (0–255) as `elapsed * 255 / duration_ms`, clamped.
+4. Blend `s_from_color` toward the target color using FastLED's `blend()`.
 5. Push the blended color to the LEDs.
-6. If `t >= 1.0`, advance to the next step (loops at end of show).
+6. If `t == 255`, advance to the next step. For `SHOW_LOOP` shows this wraps; for `SHOW_SINGLE` shows this loads the next show.
 
 To **hold** a color, add two steps with the same color — the second transition is from the color to itself, which is invisible.
 
@@ -33,23 +33,26 @@ To **hold** a color, add two steps with the same color — the second transition
 
 The Arduino Uno has only 2KB of RAM. Storing all show data in normal arrays would exhaust it quickly. `PROGMEM` stores data in flash memory (32KB), which the Uno has much more of. Both the `Step` arrays and the `ShowDef` index (`SHOWS[]`) live in PROGMEM; the `read_step()` and `read_show_def()` helpers in `lightshow_format.h` extract values safely.
 
-Each `Step` is 5 bytes (3 bytes RGB + 2 bytes duration). A `ShowDef` is 4 bytes (2-byte pointer + 2-byte length). The sketch currently uses 21% of flash — there is room for many more shows.
+Each `Step` is 5 bytes (3 bytes RGB + 2 bytes duration). A `ShowDef` is 6 bytes (2-byte pointer + 2-byte length + 1-byte mode + 1 byte padding). The sketch currently uses roughly 25% of flash — there is room for many more shows.
 
 ---
 
 ## How the button works
 
-`button.h/.cpp` implements a state machine with software debouncing:
+Button handling uses the [OneButton](https://github.com/mathertel/OneButton) library. A `OneButton` instance is created in `cosplay_lights.ino` with callbacks attached in `setup()`:
 
-1. **Debounce** — the raw pin state must be stable for `DEBOUNCE_MS` (50ms) before the debounced state updates. This filters contact bounce.
+- **Single tap** → next show
+- **Double tap** → previous show
+- **Long press** → reset to show 0
 
-2. **Hold detection** — if the debounced state stays pressed for `HOLD_MS` (800ms), `BTN_HOLD` fires immediately (doesn't wait for release). Any pending tap count is discarded.
+The key timing values (configured via `setClickMs` and `setPressMs`):
 
-3. **Tap counting** — each clean release increments a tap counter and records the release time.
+| Setting | Value | Effect |
+|---------|-------|--------|
+| `setClickMs(400)` | 400ms | Single tap confirmed after 400ms of silence (to distinguish from a double tap) |
+| `setPressMs(800)` | 800ms | Hold duration before long press fires |
 
-4. **Tap resolution** — after `DOUBLE_TAP_MS` (400ms) of silence, the accumulated tap count is resolved: 1 tap → `BTN_TAP`, 2+ taps → `BTN_DOUBLE_TAP`. This introduces a 400ms delay on single taps (acceptable for show navigation).
-
-Timing constants are at the top of `button.cpp` and can be adjusted.
+The button is polled every `loop()` iteration (not just once per frame), so it responds immediately even during the 16ms LED update window. OneButton handles debouncing internally.
 
 ---
 
@@ -59,7 +62,7 @@ Timing constants are at the top of `button.cpp` and can be adjusted.
 
 The generation pipeline:
 1. Reads every `.txt` in `converter/shows/`.
-2. Converts `blue_pulse.txt` first (always index 0), then all others alphabetically.
+2. Converts `blue_breath.txt` first (always index 0), then all others alphabetically.
 3. Writes one `show_<name>.h` per file into `arduino/cosplay_lights/`.
 4. Regenerates `shows.h` with updated `#include` lines and `SHOWS[]` table.