Eric Newman
Description:
Introduce a family of UI actions to dynamically modify widget appearance and labels at runtime—e.g., set text, background/foreground color, icon, opacity, visibility, and style “class”—based on actions, conditions, or feedback.
Problem:
Performers often send program changes/CCs or trigger actions where the UI does not reflect the true state afterward. Grids that fire patches can’t highlight which patch is active, and buttons that send CC toggles provide no “on/off” confirmation. Large widgets (e.g., stepdials) consume valuable screen space when only their current value needs to be shown elsewhere.
Proposed Solution:
Provide UI Alteration Actions and bindings with low-latency, GPU-friendly updates:
  • Set Text / Format Text:
    Update a label or button text from constants, variables, expressions, or another widget’s value; support formatting (units, padding, precision).
  • Set Color:
    Background/foreground/tint; support theme tokens and expressions (e.g., color by state).
  • Set Icon / Emoji / Glyph:
    Swap icon assets based on state.
  • Set Visibility / Enablement / Opacity:
    Show/hide or enable/disable widgets; optional fade duration.
  • Add/Remove Class:
    Apply named style classes (e.g.,
    selected
    ,
    warning
    ,
    armed
    ) for bulk style changes.
  • Pulse/Blink:
    Temporary highlight with duration/easing; optional repeat while condition true.
  • Group Selection:
    Radio-group semantics for grids (one selected item highlighted, auto-unselect others).
  • Watchers:
    Bind alterations to MIDI/Keyboard/OSC feedback, clip/track states, or arbitrary expressions.
  • Scopes:
    Target a specific widget, all widgets with a tag/class, or a page/global HUD element.
  • Safety/UX:
    Undo-aware; reset to template defaults on project load (configurable). Backward-compatible.
Benefits:
  • Clear, trustworthy visual feedback after actions and external MIDI changes.
  • Frees screen real estate by showing values in compact labels rather than large controls.
  • Faster programming: fewer helper widgets and workarounds.
  • Consistent, themeable look via classes and tokens; easier maintenance across pages.
Examples:
  • A patch grid highlights the currently active patch and dims others; a quick “pulse” confirms selection.
  • Buttons that send CC toggles change text to “On/Off” and background color to reflect hardware state returned via MIDI feedback.
  • A compact label on the main page mirrors a stepdial’s selected value (e.g., “Step: 11 • 73%”), letting the dial live on a secondary page.
  • When a track arms for record, class
    armed
    applies globally: buttons turn red and an icon switches to a REC glyph.
  • Show a warning banner (
    visible = true
    ) if input level exceeds a threshold; fade out after 1 s.
This summary was automatically generated by GPT-5 Thinking on 2025-08-20.
Original Post:
I’d love to see a family of UI actions that allow doing things like dynamically setting the Text of a button or label as a result of an action, setting the background colors to simulate state changes. For example, I have some buttons then send an action as a CC, but I can’t tell if I turned it on or not afterwards. Also I gave a grid of buttons that send patches, but I can’t highlight the one that is currently on.