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: 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.

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: Introduce a variety of improvements to the MIDI editor (piano roll) in Loopy Pro for better usability, control, and creative workflow. Problem: The current MIDI editing tools are limited in precision, customization, and usability, especially when handling larger arrangements or detailed MIDI programming. Proposed Solution: Add zoom and scroll via pinch or keyboard/mouse (vertical and horizontal). Add velocity and other CC lanes with automation-like editing. Implement step input and MIDI note drawing tools. Allow custom grid sizes, including triplets and dotted rhythms. Add tools for selecting/editing multiple notes (e.g., marquee select, quantize). Snap options (absolute/relative), plus the ability to nudge notes by steps. Option to mute/unmute notes. Add ghost note view (e.g., display other MIDI clips faintly in the background). Add folding/collapsing of unused or empty note rows. Optional playback preview for selected notes or areas. Benefits: Empowers users with a modern, flexible MIDI sequencing experience. Speeds up composition and editing for both simple loops and complex arrangements. Brings Loopy Pro closer to traditional DAW-level MIDI editing capabilities. This summary was automatically generated by ChatGPT-4 on 2025-05-02.

Description This feature request proposes the addition of a "Create Empty Channel" functionality within Loopy Pro. Currently, channels are instantiated by assigning specific audio units or sources during creation. Introducing the ability to create empty channels would allow users to set up templates with predefined configurations, such as MIDI mappings and routing, without the immediate need to assign audio units. This enhancement aims to streamline the workflow, particularly for users who utilize complex setups or frequently switch audio units. Problems Limited Template Flexibility : The current workflow requires assigning an audio unit during channel creation, which restricts the ability to create versatile templates that can accommodate various audio units or sources later on. Inefficient Workflow for Reconfiguration : Users who frequently change audio units or sources must reconfigure channels each time, leading to redundant setup processes and increased potential for errors. Constraints on Pre-Assigning MIDI Mappings : Without empty channels, users cannot pre-assign MIDI mappings or routing configurations independently of the audio unit, limiting customization and efficiency. Proposed Solution Empty Channel Creation : Introduce the ability to create channels without assigning an audio unit or source, allowing users to configure other parameters such as MIDI mappings, routing, and effects in advance. Deferred Audio Unit Assignment : Enable users to assign or change the audio unit or source at a later stage without disrupting existing configurations. Template Integration : Allow empty channels to be saved within templates, facilitating the creation of flexible and reusable project setups. Examples Template Setup : A user creates a template with multiple empty channels, each pre-configured with specific MIDI mappings and effects chains. Later, they assign different audio units to these channels based on the project's requirements. Dynamic Reconfiguration : During a live performance, a user quickly swaps audio units on pre-configured empty channels to adapt to different musical pieces without altering the underlying MIDI and effect settings. Educational Use : Instructors set up empty channels with predefined configurations to demonstrate various audio units or effects, streamlining the teaching process. Benefits Enhanced Workflow Efficiency : Reduces the time and effort required to set up or reconfigure channels, particularly in complex projects or live performance scenarios. Increased Flexibility : Allows for greater adaptability in project setups, accommodating a wide range of audio units and sources without the need to recreate configurations. Improved Template Utility : Enables the creation of more versatile and reusable templates, fostering consistency and efficiency across different projects. This summary was automatically generated by ChatGPT-4 on 2025-05-17.

Description: Allow users to save and reuse canvas elements as modular blocks – including their UI widgets, actions, bindings and layouts – to streamline plugin setups or effect chains. Problem: When adding a new AUv3 plugin or building a project from scratch, users often need to rebuild the same set of widgets, actions and bindings manually. This is time-consuming, error-prone, and breaks workflow consistency. Proposed Solution: – Save canvas areas or full pages as reusable "project modules" – Include all widget settings, bindings, colors, layout and actions – Add saved modules to new or existing projects (e.g. on a new page or layer) – Ideal for prebuilt plugin controller layouts or effect chains – Optional auto-scaling for canvas size or channel width Benefits: – Saves time by reusing complex setups – Ensures consistent UI and behavior across projects – Great for building custom plugin templates – Helps live performers and advanced users maintain modular workflows This summary was automatically generated by ChatGPT-4 on April 30, 2025.

Description: Add a feature to hide widgets in Loopy Pro to keep the workspace clean and organized. This would be particularly useful for users who use a large number of widgets for macro tasks but prefer a more streamlined visual interface. Problem: Currently, all widgets are visible on the canvas, even if they are used solely for macro purposes and do not require direct interaction. Moving these widgets to a separate page is possible but makes template management more complex. Manually hiding each widget individually is also cumbersome. Proposed Solution: Implement a toggle within each widget’s settings to make it visible only in the editor, not on the canvas. Additionally, introduce a dedicated "Hidden Widgets" page within the editor where users can place all undesired widgets in one go, rather than individually marking each as hidden. This dual approach would offer both flexibility and simplicity. Benefits: Cleaner and more organized canvas layout. Easier management of macro widgets without cluttering the workspace. More efficient template creation and editing. Improved user experience by reducing visual distraction. This summary was automatically generated by ChatGPT-4 on 2025-05-07.