Feature Requests

Description: Introduce a “live-linked” master template system where projects created from a template can optionally remain linked to that template. Structural changes made to the template (layout, routing, actions, etc.) are automatically propagated to all linked projects, while each project keeps its own recordings and project-specific content. Problem: Currently, once a project is created from a template, it becomes a completely independent copy. This creates several issues for performers who maintain multiple projects: Tedious maintenance: Any improvement to the setup (UI tweaks, routing optimizations, better controller mappings, new widgets, updated macros) must be manually replicated across every existing project. Inconsistency over time: Older projects gradually diverge from newer ones; some have the “old” layout or routing, others the “new” one, making it harder to remember what behaves how. Risk of breakage: When a user wants to improve their master setup, they may hesitate because it would require touching many projects—or risk breaking older recordings with incompatible routing or missing controls. Inefficient iteration: Rigs evolve constantly. Without a master template link, users can’t just refine one place and trust that all performance projects inherit the improvements. For heavy Loopy users running multiple shows/projects, this lack of “central configuration” makes their workflow more fragile and time-consuming than necessary. Proposed Solution: Implement a true master template system with live linkage and controlled overrides: Master templates as structural source: - A template stores all “structural” aspects: - Layout and UI widgets - Routing and buses - Mixer settings - MIDI bindings and controller mappings - AUv3 configuration (which plugins are loaded and their parameters) - Global actions, macros, track setups, etc. - Projects created from this template only store project-specific data: - Recorded loops and audio - Clips, timeline content, other per-session material Live linkage: - When a template is updated (e.g. add a new widget, adjust routing, change MIDI mappings), all linked projects automatically inherit those structural changes. - Projects remain playable and current without manual re-editing. Control per project: - A clear toggle such as: - “Link to template / Unlink from template” - Per-project override system, so a project can: - Override specific elements (e.g. one widget layout or a particular binding) while still inheriting the rest from the template. - A manual “Refresh from template” command: - Pull the latest changes from the template on demand. - Useful if automatic updating is disabled or for safety. Conflict handling and transparency: - Optional diff/merge view when applying template updates: - Shows what will change in the project (new widgets, changed mappings, removed elements, etc.). - Allows the user to accept or reject certain changes if overrides exist. - Clear indication in the UI that a project is linked to a given template and how up-to-date it is.

Description: Provide an Action Inspector with optional Graph View to show every action attached to a selected object (widget, clip, track, mixer channel, AUv3, page, project), including triggers, conditions, follow actions, targets, and cross-references . Enable quick navigation, test-fire, and safe refactoring. Problem: In complex sessions it’s hard to know what a control will do or why something fires . Actions may live on multiple widgets, clips, or page events, making troubleshooting slow (duplicates, circular triggers, wrong targets) and risky during shows. Proposed Solution: Inspector (List View): - Consolidated list of all actions bound to the selected object grouped by Trigger (On Press/Release, On Value Change, On Load/Unload, Clip Start/End, Follow Action, MIDI/OSC, etc.). - Shows conditions , quantize/late-press guard , ramp settings , targets , and scope (this page/project). - Inline controls: enable/disable, reorder, edit, jump to target , duplicate , move to… . Graph View (Dependencies): - Node graph of sources → actions → targets , highlighting inbound (who triggers this) and outbound (what this triggers). - Detects loops , shows cycle guards , and flags missing/invalid targets . Cross-References (“Where Used”) - Searchable index of every place this object is referenced (other widgets, scenes, follow actions, variables, OSC/MIDI maps). - One-click navigation and batch disable. Live Monitor & Test: - Event log (timestamped) for the selected object; optional record while performing . - Test-fire sandbox (respecting quantize) with undo; “simulate at next bar/beat.” Filters & Safety: - Filter by trigger type, page, color group, or action category (transport, mixer, OSC/MIDI, AUv3). - Read-only mode to prevent edits during shows; compare changes (diff) before applying. Refactor Tools: - Promote to Preset/Bundle , Extract to Page Action , Replace Target(s) , Convert duplicates → shared macro . - Bulk enable/disable , rename referenced objects , auto-relink by tag/color. Actions & Variables: - Actions: Open Action Inspector , Show Graph , Where Used , Test-Fire , Enable/Disable All on Object , Move Actions to … , Export Action Bundle . - Vars: object.actionCount , object.triggerCount , object.hasLoops , object.references . Benefits: Instant clarity : see everything tied to a control or clip in one place. Faster debugging and safer shows (catch loops, duplicates, bad targets). Confident refactoring with navigation, batch ops, and undo. Reusable setups via export/presets. Examples: Select a Record button: Inspector shows Press/Release actions, quantize, a follow action that arms the next clip, and an OSC cue; Graph reveals a hidden text widget also triggers the same macro. A clip won’t stop cleanly: Where Used shows a scene action re-starting it at End; disable that rule in one tap. Before tour, record a Live Monitor during rehearsal; fix two late-press guards and convert three duplicate ramps into a shared macro. This summary was automatically generated by GPT-5.1 Thinking on 2025-11-24. Original Post: Abilty To See ALL ACTIONS Tied to an Object CURRENT STATE: Troubleshooting objects /controls are nothing less than PAINFUL in LP; especially if/when more than one action interacts with them. SOLUTION: Allow a user to select ANY object /control - a widget, a fader of any kind/type, a plugin of any kind/type; and then .... allow them to get a view of ALL the actions that set or change or interact with them. Any action that changes any parameter - so the user can troubleshoot when something is going wrong.

Description: Add a configurable “New-State Feedback” system that makes UI elements light up / flash / glow when a target state changes (e.g., Armed→Recording, Empty→Has Audio, Mute→Unmute), with per-widget rules for when , how , and how long the feedback appears—optionally synced to bars/beats. Problem: On dense canvases it’s easy to miss that something actually changed—especially when actions fire quantized or off-screen. Users need a fast, unambiguous visual confirmation (brief highlight, pulse, LED) that a control or clip entered the intended state without adding extra widgets or staring at tiny labels. Proposed Solution: Triggers (per widget/clip/mixer item): - On State Enter/Exit/Change (e.g., recording , overdub , playing , muted , hasContent , armed , queued ). - Threshold Crossings (e.g., send > 0%, level > −6 dB). - Event Hooks: Follow Action finished, Scene load, Export complete, MIDI/OSC message received. - Quantize Start (None/Beat/Bar/Loop; late-press guard aware). Feedback Styles: - Flash (one-shot), Pulse (N repeats), Glow (decay), Steady LED (while in state). - Controls: color , intensity/opacity , duration (ms/beats), decay curve (linear/S-curve), outline vs. fill , icon blink . - Epilepsy-safe option (limit frequency/contrast; respect “reduce motion”). Scope & Targeting: - Apply to Buttons, Radios, Dials/Faders, Clips, Mixer Strips , and Text (underline or background blink). - Cross-page relay : optionally mirror a remote state to a local indicator. - Priority system to avoid multiple styles clashing; last-writer-wins or queue. Programming & QoL: - Inspector Feedback tab with presets (e.g., Record Confirm , Clip Armed , FX Toggled ). - Actions/Variables to trigger or query feedback: Show Feedback (style, color, dur) ; vars widget.state , clip.hasContent , feedback.active . - Theme-aware palette with auto-contrast; dark-stage brightness cap. Performance: - GPU-friendly animations; Performance-Safe mode throttles repetition; zero impact on audio thread. - Fully undoable; per-project/page defaults. Benefits: Immediate, unmistakable confirmation that an action landed. Fewer mistakes on stage; eyes off the screen sooner. Cleaner canvases—no extra “OK” lamps or duplicate widgets needed. Consistent, theme-aware signals across pages and projects. Examples: Record button does a white flash (200 ms, Bar-quantized) when recording actually begins; a steady red LED persists while recording. A Clip tile pulses green once when it transitions from Empty → Has Audio after a take. Toggling FX Bypass briefly glows cyan on the insert tile; long glow means “bypassed.” Send A knob emits a short pulse the first time it crosses >0% , confirming the bus is now active. After a Follow Action completes, a small header badge blinks to acknowledge the chain finished. This summary was automatically generated by GPT-5.1 Thinking on 2025-11-24. Original Post New State Feedback - LIGHT UP The State Feedback mechanism is LP is complicated, confusing, time consuming and detrimental to the health of the users. Seriously.... Users need a button to light up, when it is pressed REGARDLESS of anything; regardless if there is or is not a press action in the button REGARDLESS of anything; regardless if something happens or doesn't happen downstream WE JUST NEED TO BE ABLE TO LIGHT UP a button via an action (or MIDI binding action) without a PhD in software, or complications, or spending an HOUR..... trying to get something to work. MAKE IT EASY!!!

Description: Add an action that can directly replace the text content of a text widget on the canvas. A button (or other trigger) should be able to target a specific text box and set its text to a defined value, or potentially to a dynamically generated string. This enables text widgets to act as live information displays for controller profiles, signal chains, lyrics, notes and other performance-related messages. Problem: Currently, text widgets are mostly static labels. There is no simple way to: Press a button and have a text box update to show a different message. Use text widgets as dynamic status displays (e.g. current MIDI controller profile, which signal chain is active, which section of a set is playing). Integrate text changes with follow actions or other logic to step through lyrics, chord prompts, or performance notes. As a result: MIDI controller users cannot easily see which “mode/profile” they’re in from a big on-screen label. Live performers can’t quickly show large, clear messages on screen for themselves or the audience (“Chill Part”, “Solo Coming Up”, “Next Song: …”) triggered by buttons. Designers who create on-screen control layouts for midimapping can’t annotate or update these layouts with changing text states. Any kind of pseudo-teleprompter, chord progression steps, or random notes requires awkward workarounds instead of a straightforward text-replace action. This limits the potential of text widgets as flexible, performance-relevant UI elements. Proposed Solution: Introduce a “Replace Text in Text Box” action with clear targeting and configuration: Core action behavior: - Action: “Change / Replace Text” - Parameters: - Target: select a specific text widget. - New Text: user-specified content (literal string or dynamic expression in the future). - When the action is triggered, the target text widget’s content is immediately replaced with the specified text. Trigger sources: - Canvas buttons (on press). - MIDI controller inputs. - Follow actions (e.g. step through a sequence of messages). - Other Loopy actions/macros. Dynamic usage examples and extensions: - Use with dials and other widgets while a broader “dynamic text” system is still evolving: - For example, a button that updates a text box to show which control profile is active. - Support performance communication: - Show large text on screen indicating which signal chain is currently in use. - Display notes to the audience on an external screen (“Next piece”, “Short break”, etc.). - Integration with follow actions: - Cycle through chords, lyrics fragments, or other notations by chaining text-replace actions. - Build a “scrolling” or stepwise teleprompter-style system. Future-friendly design: - The same mechanism could later be expanded to accept variables or bindings (e.g. insert current tempo, section name, loop name). - Could integrate with a more advanced “dynamic text” concept, but this basic replace-text action is a powerful step on its own. Benefits: Dynamic information display: Turn text widgets into live status indicators for MIDI profiles, routing states, scenes, and more. Better feedback for controller users: MIDI controller setups can have clear on-screen labels showing which layout or profile is currently active. Performance messaging: Easy way to push big, legible messages to the screen for performer or audience, especially when Loopy is on a large display. Lightweight building block: A simple, generic action that unlocks many creative uses (teleprompter, chord prompts, random notes) without requiring complex new UI. Examples: A MIDI controller profile display: - Several buttons select different MIDI controller modes (e.g. “Drums”, “FX”, “Loop Control”). - Each button triggers a “Replace Text” action targeting a central text box: - “Current Profile: DRUMS” - “Current Profile: FX” - “Current Profile: LOOPS” Signal chain indicator: - Different buttons activate different signal chains or scenes. - The same button press updates a big text widget to show: - “Chain A: Clean Ambient” - “Chain B: Heavy FX” - “Chain C: Vocals + Delay” Lyrics / chords / notes: - A series of follow actions steps through a list of text replacements: - Each trigger replaces the text box content with the next lyric line or chord. - On the big screen, this becomes a simple scrolling notes system for the performer or audience. This summary was automatically generated by GPT-5.1 Thinking on 2025-11-20 .

Original Post: Description: Allow users to define default settings per widget type (Button, Fader, Dial, Text, Radio, Meter, etc.) so newly created widgets inherit preferred visual styles and behaviors (actions, guards, ramps, visibility rules, label templates)—with defaults scoped to Global , Project , and Page . Problem: Every new widget starts from factory settings, forcing repetitive styling and reconfiguration (colors, fonts, outlines, ramp curves, quantize/late-press guards, default actions). This is slow, error-prone, and leads to inconsistent UIs across pages and projects. Proposed Solution: Scopes & Priority: Defaults at Global → Project → Page ; the most specific scope wins. Per-type entries (e.g., Button , Fader ) plus optional subtype profiles (e.g., Button: Transport , Text: Small Label ). What a Default Can Include (checklist): - Visual: size anchors, colors/tints, fonts, borders/rounding, icon/pictogram/Genmoji, safe text size, background image mode. - Behavior: prewired actions/follow actions , quantize and late-press guard , ramp defaults, toggle policies, visibility rules. - Mappings (optional): include/exclude MIDI/Keyboard/OSC learns; auto-scope retargeting (e.g., map to selected clip ). - Label Templates: tokenized text (e.g., Play {clip.selected.name} ) and number formatting. Capture & Apply: - “Save as Default for This Type (scope…)” from any configured widget. - New widgets adopt the active default automatically; Override per instance remains possible. - Reset to Factory or Reapply Current Default commands. Management UI: - Defaults Manager with thumbnails, tags, and diff view; enable/disable fields included in a default. - Export/import Default Sets (team sharing) with asset de-duplication. Compatibility with Presets: - Defaults = auto-applied baseline ; Presets remain for named variants you apply manually or link to. Option: “After create, apply preset X .” Actions & Variables: - Actions: Save Current Widget as Default (scope/type) , Set Active Default (scope/type) , Reset to Factory , Reapply Default to Selection . - Vars: defaults.scope.active , widget.default.applied , widget.default.sourceScope (Global/Project/Page). Benefits: Dramatically faster page building; fewer repetitive steps. Consistent look & behavior across large projects and teams. Fewer mistakes (guards/quantize/ramp policies are standardized). Clean separation between auto defaults and optional presets . Examples: Set a Button default with bar-quantized actions and a 120 ms late-press guard; every new Button comes pre-armed. A Text default uses a high-contrast font with {tempo.bpm|0} formatting for status labels across pages. On a FOH page, define Fader defaults as compact with numeric trims; on the main page keep full-height faders—via Page-level defaults. Share a Global Default Set with your band so new widgets match branding and behavior out of the box. This summary was automatically generated by GPT-5.1 Thinking on 2025-11-24. Default Widget Settings Allow users to create /set defaults for widgets, and then whenever widgets are used in any of their projects, their desired are already "set" or "defaulted. E.g. - in all of my use of STEPDIALS, I want the State Feedback setting disabled, by default. So allowing users to create default settings, they won't have to SPEND HOURS, remembering what /how they set up something. Having to look in other projects is terribly TIME consuming. ~Thanks for great software~ AJ

Ability to set a widget’s highlighting/color/appearance from an action . Sometime we need to use action sequences (next trigger) like toggles or stepped controls but there is no way to provide visual feedback about the state. It would be good if there were some action that lets you change the appearance as you step through its "Next Trigger" actions.

Description: Add a dedicated “Recent Projects” folder to the Projects browser that automatically lists the last few projects the user has opened (for example, the 5–10 most recent). This folder would be available alongside the existing folder hierarchy and root, providing a fast shortcut to jump back into recently used projects without needing to remember their exact location. Problem: Users often organize their projects into multiple folders for different purposes (gigs, sessions, experiments, templates, etc.). In practice, this leads to a couple of common issues: They frequently switch between several projects that live in different folders. To reopen a recent project, they must remember: - Which folder it lives in, and - Where it sits inside that folder (especially if the folder contains dozens of projects). Without a dedicated “recent” list, reopening a previous project can require: - Navigating through the folder tree, - Visually scanning long lists of project names, or - Using search, which is slower for quick back-and-forth switching. This slows down workflows where users are actively bouncing between multiple projects during a session or rehearsal and adds friction to a task that should feel instant. Proposed Solution: Add a “Recent Projects” virtual folder in the Projects list: - Displays a configurable number of recently opened projects (e.g. at least the last 5; ideally user-configurable to 10, 20, etc.). - Projects appear in reverse chronological order (most recently opened at the top). Behavior details: - The Recent Projects folder is automatically maintained by Loopy, with no manual organization required. - Entries in the Recent Projects folder are shortcuts/links to the actual project files in their existing folders; they do not move or duplicate the real projects. - Each entry could optionally show: - Project name, - Original folder path (e.g. “Gigs / 2025-11-20 – Berlin Set”), - Last opened date and time. Optional enhancements: - Settings for: - How many recent projects to display. - Whether to show a “pinned” section for favorites. - Context menu item to: - “Remove from Recent Projects” (without deleting the project). - Platform-aware behavior: - On iPad or macOS, Recent Projects could also appear in quick-access areas like the start screen or “Open Project” dialog. Benefits: Faster navigation: Users can jump back into the last few projects they were working on without navigating the folder hierarchy or remembering file locations. Better for multi-project workflows: Ideal for users who constantly alternate between a couple of projects (e.g. rehearsal vs. performance version, or different setlists). Less cognitive load: No need to recall which folder a project is filed under; “Recent Projects” acts as a short-term memory buffer. Scales with large libraries: Even if a folder contains dozens of projects, the most relevant ones (recently opened) are always just one tap/click away. Examples: A performer rehearses three different show projects stored in different folders: - Instead of navigating “Shows → Club Set”, then “Shows → Festival Set”, then “Rehearsals → Practice Rig”, they open all three once. - After that, all three appear in “Recent Projects,” allowing rapid switching during rehearsal. A user experiments with new templates: - They open and tweak several template-based projects spread across “Templates,” “Experiments,” and “Live Sets.” - The Recent Projects folder keeps these at the top, so they can easily return to yesterday’s experiments without remembering where they filed them. A busy session workflow: - During a recording day, the user jumps between a “Recording” project, a “Soundcheck” project, and a “Test” project. - “Recent Projects” always shows these three at the top, reducing friction when moving back and forth. This summary was automatically generated by GPT-5.1 Thinking on 2025-11-20 .

Description: Allow users to define the filenames of recordings created in Loopy Pro, instead of relying solely on automatically generated names. Users should be able to type a custom name before recording, and/or define reusable filename templates (with wildcards) that Loopy applies automatically when rendering or recording to disk. Problem: Currently, recordings made in Loopy Pro (for example, recording the main output, buses, or stems) are saved with automatically generated filenames. While this works technically, it has several practical drawbacks: Hard to identify later: Generic or timestamp-based names make it difficult to know what a file contains (“Recording 2025-11-20 23-08”, “Project Render 3”, etc.), especially when quickly browsing in the Files app, DAWs, or other software. Poor organization across sessions: When exporting multiple takes or songs from different projects, all recordings end up with similar-looking names. It becomes harder to know which recording belongs to which song, section, or show. Inefficient in professional workflows: Users who archive recordings, send them to collaborators, or import them into DAWs often need to rename files manually to reflect: - Song title or project name - Section (Intro, Verse, Chorus, etc.) - Take number - Date or venue Risk of confusion and mistakes: Manual renaming outside Loopy (in Files or on a computer) is error-prone and time-consuming, and it breaks the nice directness of a live performance workflow. In short, the app decides the filenames, but users—especially those working professionally—need more control to keep their recordings organized and meaningful. Proposed Solution: Add flexible, user-controlled filename options for recordings: Simple per-recording name field - In the “Record / Render” panel, provide a text field such as: - “File name:” (default pre-filled with the current auto-generated name). - Before starting a recording, users can: - Edit this name manually (“SongName_Verse_Take01”). - Loopy then saves the resulting file with that exact name (plus extension). Filename templates with wildcards - Allow users to define reusable filename templates that can automatically include: - Project name ( {project} ) - Date and time ( {date} , {time} ) - Section or group name ( {section} , {playgroup} if available) - Output or bus name ( {output} , {bus} ) - Take number ( {take} ) - Example templates: - {project}_{section}_{take} - {date}-{project}-{output} - Provide a small “Wildcards” helper list or popup so users can see which tokens are available and insert them quickly. Per-project and global defaults - Global default template in Settings (applies to all new projects). - Per-project override so each project can have its own naming pattern: - e.g. “BandName_{date}_{section}_{take}` for a live show project. - Option to quickly reset to the default template. Auto-increment take numbering - When a template includes {take} , Loopy should: - Automatically increment the take number when recording repeatedly with the same base name/template. - Ensure unique filenames and avoid overwrites, e.g.: - SongA_Verse_01.aif - SongA_Verse_02.aif , etc. Compatibility and safety - Ensure generated filenames avoid problematic characters for common file systems and cloud services. - If a user types disallowed characters, Loopy could: - Show a small warning, or - Auto-sanitize them (e.g. replace with _ ).

Description: Introduce a built-in voice assistant that can create and edit templates based on natural language descriptions. The assistant should understand spatial layout requests (“put three loops across the top, faders along the bottom”), widget behavior (“this button should start all drums”), and routing/logic, and then translate the user’s spoken instructions into concrete changes in the template. The assistant would work in phases: Phase 1: The assistant parses spoken instructions and replies with text in a popup window, describing what it would do or suggesting how to achieve the layout/behavior. Phase 2: The assistant can actually perform complex edits across multiple widgets and loops, with a confirmation step before applying changes, and optionally reply via on-screen text and/or audible voice. Problem: Building and editing complex templates in Loopy can be time-consuming and cognitively demanding, especially for users who: Are new to the app and don’t yet know where every option lives. Think in musical or spatial terms rather than in UI terminology. Want to iterate quickly while keeping their focus on playing rather than on detailed UI editing. Current workflow challenges include: Manual layout work: Placing widgets, sizing them, and arranging them spatially can be fiddly, especially on smaller screens. Steep learning curve for logic and behavior: Defining what each widget should do, which loops it controls, and how they interact may require navigating multiple menus and inspectors. High friction for complex editing: Editing several widgets and loops at once (e.g. changing multiple parameters, routing schemes, or actions) is possible but involves many separate manual steps. Accessibility and ergonomics: Some users may have physical or visual limitations that make drag-and-drop UI editing or intricate menus less comfortable. A voice-based assistant could dramatically reduce the friction of going from “I have an idea for a layout/behavior” to a working template. Proposed Solution: Implement a two-phase voice assistant feature with a strong focus on clarity, safety, and iterative conversation: Phase 1 – Conversational design assistant (text-only): - Users can speak instructions such as: - “Create a template with four loop widgets arranged in a row at the top.” - “Add a big play/stop button in the center that controls all loops.” - “Make this knob control the filter cutoff of my main synth.” - The assistant: - Interprets the request and displays its proposed actions in a popup text window. - Asks clarifying questions when unsure, for example: - “When you say ‘drums’, do you mean the group ‘Drums’ or track 3?” - “Should this button start all loops on this page or in the whole project?” - Suggests how to achieve the requested behavior using existing features, even before it has direct editing capabilities. - This phase focuses on understanding, guiding, and educating the user, building trust and a shared vocabulary. Phase 2 – Voice-driven editing and execution: - The assistant gains the ability to actually apply changes to templates: - Create, move, resize and delete widgets. - Assign actions and bindings. - Configure loops, buses, and basic routing. - Support for complex multi-step commands , for example: - “Create a new performance page with eight loop buttons, each controlling its own track, and a master mute button in the bottom-right corner.” - “Make all existing faders control the headphone mix instead of the main output.” - Before executing, the assistant: - Shows a confirmation popup summarizing what will change. - Lets the user approve or cancel the operation. - The user can choose how responses are presented: - Text in a popup window only. - Text plus audible spoken feedback (text-to-speech), useful for hands-free editing. Clarification and safety: - The assistant should: - Default to asking clarifying questions when intent is ambiguous. - Avoid destructive changes without clear confirmation. - Offer undo or a quick “revert” option after applying changes. - Provide a simple way to inspect what the assistant has just done (e.g. a brief change log or “What did you just change?” query). Integration with existing workflows: - Voice commands should work alongside all existing UI and action-based workflows: - Users can mix voice-driven edits with manual fine-tuning. - Potential actions to start/stop listening, or to trigger a “repeat last instruction” or “explain current layout” interaction. - Over time, the assistant could also help explain the current template: - “Tell me what this button does.” - “Describe how this page is laid out and what each control is for.”

Description: Unify sliders and dials into a single Continuous Control that auto-morphs its presentation based on widget shape/orientation: tall = vertical slider, wide = horizontal slider, square ≈ dial . The control keeps the same ID, mappings, actions, and ranges regardless of presentation, with an optional lock to force a chosen style. Problem: Currently, sliders and dials are treated as different widgets, so changing layout (e.g., making a slider more square) often means rebuilding or re-mapping to switch to a dial—and vice versa. This duplicates work, breaks consistency, and slows iteration for dense, responsive layouts. Proposed Solution: One Control, Three Presentations: A single Continuous Control renders as - Vertical slider when height ≫ width, - Horizontal slider when width ≫ height, - Dial when aspect is near-square (threshold user-settable, e.g., 0.85–1.15). Preserve Everything: Same midi/osc mappings, actions, ranges/min-max, step/curve , ramp/quantize guards, and visual style regardless of presentation. No re-assignment needed. Lock & Overrides: Optional Style Lock (Slider-V / Slider-H / Dial) to prevent auto-morph for users who prefer fixed visuals; project/page defaults. Smart Gestures: - Linear/fine-adjust drag for all presentations; circular + linear drag for dials. - Optional accel for long throws; scrubbing with modifier keys; double-tap to reset. Inspector Controls: Aspect threshold, pointer angle range for dial, tick/indicator options, value readout mode, snap points. Copy/Duplicate Safety: Duplicates retain the same control type and presentation logic; resizing triggers morph without breaking bindings. Themes & Accessibility: Contrast guard, large-type readouts, color-blind-safe indicators; pictogram/Genmoji labels supported. Benefits: No re-mapping when switching between slider and dial looks. Faster, cleaner page design: layout drives look, function stays identical . Consistent behavior across devices/orientations while preserving muscle memory. Less widget proliferation; simpler templates and maintenance. Examples: A volume control grid is resized to fit a tight matrix; square cells automatically render as dials without losing MIDI learns. Sound-design page: widen Cutoff to become a horizontal slider for precision, then shrink to square for a dial —all mappings intact. Duplicate a control to a second page; it appears as a vertical slider on a tall strip and a dial in a compact header, yet both share the same actions and ranges. This summary was automatically generated by GPT-5.1 Thinking on 2025-11-21.