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 This feature request proposes the implementation of a radial (pie-style) pop-up menu within Loopy Pro's gesture system. The goal is to provide users with a more efficient and visually organized method to access multiple actions or presets through a single gesture or button, enhancing the user interface and workflow. Problems Inefficient Navigation : Currently, navigating through step dials or radio grids to select a specific action or preset can trigger unintended actions for each intermediate step, leading to workflow disruptions. Screen Real Estate Constraints : Limited screen space, especially on smaller devices, makes it challenging to display multiple controls simultaneously without cluttering the interface. Limited Gesture Integration : The existing gesture system lacks a dynamic menu that can present multiple action options in a compact and accessible manner. Proposed Solution Radial Menu Integration : Introduce a radial pop-up menu that can be triggered via gestures or button presses, displaying multiple action options in a circular layout. Deferred Action Execution : Ensure that actions within the radial menu are only executed upon final selection, preventing unintended triggers during navigation. Customizable Menu Items : Allow users to customize the actions or presets available within the radial menu to suit their specific workflow needs. Visual Feedback : Provide clear visual cues within the radial menu to indicate the currently highlighted option and confirm selection upon release. Benefits Enhanced Workflow Efficiency : Users can quickly access and execute desired actions without navigating through multiple menus or triggering unintended actions. Optimized Interface : The radial menu offers a compact and organized method to present multiple options, conserving screen space and reducing clutter. Improved Gesture Utilization : Integrating the radial menu into the gesture system expands the functionality of gestures, allowing for more complex and efficient control schemes. This summary was automatically generated by ChatGPT-4 on 2025-05-08.

Description This feature request proposes the implementation of flexible groove quantization options for MIDI recording in Loopy Pro. The goal is to provide users with advanced tools to adjust the timing and feel of MIDI recordings, enhancing musical expression and aligning with various rhythmic styles. Problems Rigid Quantization : Currently, Loopy Pro offers basic quantization settings that may not accommodate the nuanced timing required for different musical genres or personal playing styles. Limited Groove Customization : Users lack the ability to apply swing, shuffle, or custom groove templates to MIDI recordings, restricting creative possibilities. Inconsistent Timing Feel : Without flexible groove quantization, achieving a humanized or genre-specific rhythmic feel requires manual adjustments, which can be time-consuming and imprecise. Proposed Solution Advanced Quantization Options : Introduce a range of quantization settings, including swing percentages, shuffle rhythms, and customizable groove templates. Real-Time Groove Application : Allow users to apply and adjust groove settings in real-time during MIDI recording and playback. Groove Template Library : Provide a library of preset groove templates representing various musical styles (e.g., funk, jazz, hip-hop) and allow users to create and save custom templates. Visual Feedback : Implement visual indicators within the MIDI editor to display the applied groove adjustments, aiding in precise editing and alignment. Benefits Enhanced Musical Expression : Flexible groove quantization enables users to infuse their MIDI recordings with desired rhythmic feels, enhancing the musicality of their productions. Streamlined Workflow : Real-time groove application and visual feedback simplify the process of achieving the intended timing, reducing the need for manual corrections. Creative Versatility : A comprehensive set of groove options allows users to experiment with different rhythmic styles, fostering creativity and innovation in their music. This summary was automatically generated by ChatGPT-4 on 2025-05-08.

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 _ ).