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.

Sadly.... right now, you CANNOT specify which channel or channels a MIDI Clip (loop) or MIDI One Shot - broadcast, or sends MIDI data /notes out on. Very Sad STANDARD of PRACTICE: Pretty much EVERY MIDI generating plugin or software (Harmony Bloom, Rozeta, etc.) and EVERY MIDI generating hardware, like keyboards of all types, drum pads, etc. --- they ALL let you specific or setup which MIDI Channel(s) to send MIDI out on. RATIONALE: Since LP is not following the standard or best practice.... that should be enough itself. HOWEVER.... use case: I have a MIDI Clip (loop) with 4 simple notes, that I created in the LP Editor. I will use these 4 notes to trigger button widgets, via a MIDI binding in the control profile. I want these 4 MIDI notes sent out on MIDI Channel 5 so as not to interfere with any other MIDI notes - from plugins (MIDI generators) or physical keyboards, or physical drum pads. REQUEST: In any place in LP where MIDI can be generated, e.g. MIDI clips (loops), MIDI One Shots, Virtual Keyboards .... (did I miss anything ?) ; add functionality in the software to let the user setup which MIDI channel the MIDI is sent out on.

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 .

Description: Allow users to assign custom names to individual AUv3 effect instances within Loopy Pro, enhancing clarity and organization in complex projects. Problem: Currently, AUv3 effect instances in Loopy Pro are labeled with their default names, which can lead to confusion when multiple instances of the same effect are used. This lack of distinction makes it challenging to identify and manage specific effects, especially in intricate setups. Proposed Solution: – Enable renaming of each AUv3 effect instance directly within the Loopy Pro interface. – Display the custom names prominently in the mixer and effect lists. – Ensure that these custom names are saved with the project and persist across sessions. – When the custom label is deleted, the instance should automatically revert to showing the default AUv3 name. – Optionally, allow for color-coding or tagging of renamed instances for additional visual organization. Benefits: – Improves workflow efficiency by making effect instances easily identifiable. – Enhances project organization, particularly in complex or collaborative environments. – Reduces the likelihood of errors caused by misidentifying effects. – Aligns with standard practices in other DAWs, providing a familiar experience for users. This summary was automatically generated by ChatGPT-4 on April 30, 2025.

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

Description: Allow users to group multiple AUv3 plugins into a reusable "plugin group" that behaves like a single plugin container. This makes management easier and introduces powerful features at group level. Problem: Managing multiple plugins on a channel becomes complex. There is no way to treat a combination of AUv3s as a single, unified module. Also, many plugins lack a wet/dry mix and other basic options. Proposed Solution: – Treat plugin groups as if they were individual plugins – Groups show up in plugin lists (add to project, add via action, etc.) – Allow instantiating multiple plugin groups – Allow actions to apply to the group as a whole (e.g. enable/disable) – Provide group-level settings: • Group name (user-defined or internal) • Wet/dry mix control for the group • Reorder plugins in the group • Actions to enable/disable the group – Display group with visual indicators (e.g. folder-style icon, color tag, red/green circle for status) – Allow edit mode and save as preset or duplicate – Restrict to only unused plugin instances (avoid duplicate references) Stretch Goals: – Group presets for wet/dry mix and plugin order – Icon sets to help users identify groups – Choose from visual folder/container symbols – Future option to include plugin parameter presets per plugin inside the group Benefits: – Modular plugin workflow – Reusable effect chains – Add missing features like wet/dry to plugins that lack them – Better project organization – Faster setup and management – Enables actions and visual feedback at group level This summary was automatically generated by ChatGPT-4 on April 30, 2025.

Description: The feature request proposes the ability to copy, move, or swap actions between two widgets within Loopy Pro. This would greatly streamline workflow, especially when working with complex setups. Currently, there is no efficient way to transfer actions between widgets without manually recreating them. Problem: When setting up multiple widgets, it can be tedious to replicate or transfer actions, especially in scenarios where similar actions need to be applied across multiple widgets. The lack of a copy, move, or swap function leads to redundant manual work. Proposed Solution: Introduce a feature to easily copy, move, or swap actions between two widgets. This could be implemented with a "Pin" function that allows the user to mark a widget, then switch to another widget and choose to copy, move, or swap the actions. Additionally, the feature should support replacing existing actions when moving actions from one widget to another. Benefits: Saves time when managing complex action setups. Reduces the need for manual copying and configuration of actions. Improves workflow efficiency by allowing users to quickly duplicate or transfer action sets. This summary was automatically generated by ChatGPT-4 on 2025-05-07.

Description: Enable saving and recalling entire channel strips (including all plugins and optionally widgets) as presets. This allows fast loading of complex FX/instrument chains across different projects. Problem: Rebuilding plugin chains and settings for each project or channel type (input, color, bus, master) is time-consuming, especially in live setups or when consistent tone is needed across songs. Proposed Solution: – Add a feature to save a full channel (strip) as a reusable preset – Optionally include bound widgets and layout elements – Allow importing/exporting channel strip presets – Add "recall channel preset" and "save channel preset" actions – Allow presets for: – input channels – color channels – bus channels – master channel – Optional: grey out unloaded channels to free up RAM/CPU – Optional: preload (but inactive) channel strips for fast switching – Optional: include full widget configuration (position, behavior, etc.) – Add tags or labels to organize channel strip types (e.g. “Guitar FX”, “Vocal Bus”) Benefits: – Save time during project setup – Allows modular, reusable channel configurations – Supports consistent tone in live and studio workflows – Ideal for musicians switching instruments/effects between songs – Reduces CPU/memory load by offloading unused channels – Encourages structured and repeatable setups This summary was automatically generated by ChatGPT-4 on April 30, 2025.