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: Introduce an explicit control-type setting for continuous controllers on the canvas (e.g. “Slider” vs “Dial”), so that resizing a widget—especially making it more square—does not automatically change its visual type. Users should be able to freely adjust the aspect ratio of a control without it turning from a slider into a dial (or vice versa) unless they explicitly choose to change its style. Problem: Right now, when working in the canvas editor, sliders that are resized into a more square shape can automatically change into dials. This creates several issues: Unexpected behavior: Users carefully shape a layout with sliders, only to see them change into dials when they tweak size or proportions. Design constraints: If someone wants a compact, almost-square slider (for space reasons or for a specific visual style), the auto-conversion to a dial prevents that. Inconsistent UI: Two controls with the same function may end up with different visual types (one slider, one dial) purely because of small sizing differences. Frustrating iteration: Fine-tuning layout becomes trial-and-error: adjust size → widget flips to a dial → undo or fight the aspect ratio, instead of focusing on musical workflow. In short, the visual type of a control is currently tied to shape, which makes UI design less predictable and more annoying than it needs to be. Proposed Solution: Decouple widget type from widget aspect ratio and give the user explicit control: Add a “Control Type” setting in the widget inspector for continuous controls, for example: - Type: Slider / Dial (and any other relevant variants). When resizing: - The widget keeps its chosen type regardless of width/height ratio. - No automatic conversion just because it is square or nearly square. Optional advanced behavior: - A small, explicit “Convert to Dial / Convert to Slider” command in the context menu, so quick type changes are still easy—but always deliberate. - If the current auto-switch logic is considered useful by some users, make it a toggleable preference , e.g.: - “Automatically convert sliders to dials when square: On/Off” (default: Off). Ensure that: - Duplicating or copying widgets preserves their type. - Templates remain visually stable when edited on different devices or aspect ratios. Benefits: Predictable layouts: Designers know that if they choose “Slider”, it stays a slider, no matter how they resize it. More flexible UI design: Users can create compact, nearly square sliders or wide dials without fighting automatic conversions. Cleaner aesthetics: A consistent visual language can be maintained across a project, independent of layout tweaks. Less frustration in the editor: Small alignment or size adjustments no longer risk changing the control type, making canvas editing smoother and faster. Examples: A performance layout with a tight grid of level controls: - The user wants short, almost square sliders for volume, arranged in a neat matrix. - With explicit control type, they set all controls to “Slider” and freely resize them to fit the grid; none of them turn into dials unexpectedly. A sound-design page: - Cutoff and resonance are shown as dials , while volume and sends are sliders . - The user tweaks sizes for better spacing on iPad vs iPhone, and the dial/slider distinction always remains intact. A template shared across devices: - On one device, the user adjusts some widgets to better fit a different screen size. - Even after resizing, sliders remain sliders and dials remain dials, so the template looks and feels consistent across all devices. This summary was automatically generated by GPT-5.1 Thinking on 2025-11-20 .

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: Add a “Curve” selection option for volume parameter actions to switch between different fade curve types – especially to implement equal-power curves for smoother crossfades. Ideally, this would include a dedicated crossfader widget with assignable audio sources on each side and custom crossfade curves. Problem: Currently, volume fades in Loopy Pro often drop too fast and are hard to control precisely. Smooth transitions between sources are tricky, especially when using a single MIDI controller. Only the leftmost curve is configurable for x-faders, while more musical options like the middle curve (often used for transitions) are not available. A workaround using two separate faders is suboptimal. Proposed Solution: – Add selectable volume curve types: linear, equal-power, logarithmic, etc. – Allow curves for both parameter actions (e.g., volume fades) and widgets – Create a dedicated crossfader widget with: – Assignable inputs (e.g., color channels or audio sources left/right) – Crossfade-specific curves (e.g., DJ-style equal-power or scratch-friendly behavior) – Optional: allow visual reference or preset selector like on DJ mixers (e.g., PX5 curve options) – Let users apply different curves to channel faders and crossfaders separately Benefits: – Enables precise, musical volume transitions and fades – Better suited for DJ/live use (e.g., drum blending, FX fades, source switching) – Simplifies setups by avoiding workarounds with multiple faders – Brings Loopy Pro closer to a professional live/DJ mixing environment – Empowers users with custom workflows through curve selection This summary was automatically generated by ChatGPT-4 on April 30, 2025.

Description: Loopy Pro users would like the ability to create multiple timeline regions within the sequencer, allowing for more flexible arrangements and looping possibilities. Problem: Currently, the sequencer only allows for one continuous timeline looping region. This limitation makes it challenging for users who want to set up more dynamic and flexible arrangements, especially during live performances or when experimenting with song structures. Proposed Solution: Implement the ability to define multiple timeline regions that can loop independently or in sequence. These regions should be customizable, with options for setting different loop lengths and behaviors. Additionally, an arrangement widget that functions like a master timeline would allow for quick restructuring during performances. Benefits: Enhanced flexibility for live looping and performance. Ability to experiment with different song structures without stopping playback. Improved workflow for users who want to set up looping regions with minimal interaction during performance. This summary was automatically generated by ChatGPT-4 on 2025-05-07.

Description: Introduce a “take folder” style recording mode where Loopy continuously records multiple passes of the same loop and stores each pass as a separate take within a single clip or container. After recording, the user can open this take folder and choose, slice, or combine segments from different takes to build a final “comped” loop—similar to the take folder and comping workflow in Logic Pro. Problem: When recording performance-based material (vocals, instruments, phrases) it is common to: Loop a section repeatedly. Perform multiple passes until one (or a combination) of them feels “right”. Want to keep all takes for later comparison or comping. In the current Loopy workflow: Repeating a looped recording typically overwrites or replaces the previous recording, or requires manual setup of additional tracks/clips for each pass. There is no dedicated container that automatically keeps all takes of the same loop together. Auditioning takes and building a composite loop (“comp”) requires manual duplication, editing, and management of multiple clips. This leads to: Extra track/clip clutter when trying to keep multiple takes. More time spent organizing and comparing takes instead of focusing on performance. No simple, integrated way to create a best-of “comp” from several recorded passes of the same looped section. Proposed Solution: Add a “Take Folder” recording mode and comping tools: Take Folder concept: - When recording in looped mode on a clip/track, each pass is stored as a new take within a take folder. - The main loop on the grid represents the currently active comp; the folder contains all underlying takes. - A take folder can be opened in a dedicated editor view. Recording behavior: - Enable a “Record into Take Folder” option on a clip or track: - As the playhead cycles, each new pass is automatically appended as a separate take. - The user can stop recording at any time, keeping all recorded passes associated with that loop. - Optionally allow: - Auto-creation of a take folder when a clip is recorded repeatedly on the same loop. - A clear indication that the clip contains multiple takes (icon/badge). Comping and editing: - Within the take folder view, show each take as a horizontal lane (similar length, aligned in time). - Allow the user to: - Solo and audition entire takes quickly. - Select segments (ranges) from different takes to construct the final comp. - Switch selected segments seamlessly so the resulting comp plays as a single continuous loop. - Provide basic tools such as: - Click-and-drag to define a segment from a specific take. - Crossfade or smooth transitions at boundaries (optional). - “Promote to main loop” button to commit the comp. Integration with existing Loopy features: - Comped loop behaves like a normal loop for playback, actions, and routing. - Take folders can be saved within the project and re-opened later for re-comping. - Optional action bindings: - Start/stop “take folder recording”. - Cycle to next/previous take for quick audition on the fly. Benefits: Non-destructive recording: All passes are preserved, removing the fear of overwriting a great take. Efficient comping: Users can quickly build the “perfect” loop from multiple performances without managing many separate clips. Cleaner projects: Multiple attempts live inside one take folder instead of cluttering the canvas with extra tracks or loops. Better performance workflow: Encourages natural, musical loop recording (just keep playing the section) while capturing all variations for later refinement. Examples: A guitarist records a 4-bar riff: - Enables “Record into Take Folder” and plays the riff repeatedly for several passes. - After recording, opens the take folder, auditions each take, and selects the best bar from take 3 and the best bar from take 5. - Promotes the comped result to become the final loop, with all original takes still stored in the folder. A vocalist building a hook: - Loops a phrase and sings 6–8 takes back-to-back. - In the take folder view, chooses the best syllables and phrases from different takes to create a polished composite loop. - If the singer later wants to try a different comp, they simply re-open the folder and re-select segments. A beatmaker refining a drum performance: - Records a live drum pad performance over multiple loop cycles. - Uses the take folder to quickly compare entire drum takes or swap out just a few hits or fills from alternative takes, preserving groove while fixing minor mistakes. This summary was automatically generated by GPT-5.1 Thinking on 2025-11-20 .