Feature Requests

Currently ‘save’ and ‘restore’ is only possible if it’s the same widget, but in some cases it’s neccesary to restore target A to target B. Especially the Step Dials because they can’t be ‘synced’ to each other like the normal dial and faders do. I think it’s not possible though. I also would like to be able to delete all the stored values on a project basis.

Description: Improve Loopy Pro’s audio engine by enabling true multi-core (multi-threaded) CPU processing for audio rendering, especially useful with multiple AUv3 plugins and parallel signal paths. Problem: Currently, Loopy Pro does not seem to fully utilize multi-core CPU processing for audio tasks. This can quickly lead to CPU overloads in complex projects with several AUv3 plugins, effects, or multiple audio channels – even on high-end iPads. Proposed Solution: – Implement multi-threaded audio rendering – Distribute AUv3 plugin processing across available CPU cores – Prioritize per-track or per-plugin parallelization – Dynamically allocate threads based on system load – Add CPU usage per-core display (optional) Benefits: – Much better performance on modern multi-core CPUs – Lower risk of audio glitches and dropouts – Enables more complex, creative setups with more plugins – Extends device longevity by improving resource efficiency – Makes Loopy Pro more competitive as a DAW alternative This summary was automatically generated by ChatGPT-4 on April 30, 2025.

Description This feature request proposes enhancing Loopy Pro's audio routing capabilities by allowing buses to be assigned as destinations and enabling buses to send their output to multiple destinations, including other buses. This would facilitate more complex and flexible routing configurations, such as creating monitoring buses with effects like reverb or delay that are applied across multiple channels. Proposed Solution Bus as Destination : Enable buses to be selected as destinations for audio sources, similar to how colors or outputs are currently assigned. Multiple Destinations for Buses : Allow a single bus to route its output to multiple destinations, including other buses, colors, or outputs. Dynamic Routing : Implement actions or controls that allow users to dynamically change bus destinations during live performances or within a project setup. Monitoring Enhancements : Provide options to monitor through buses, enabling users to hear the combined effects applied to multiple channels in real-time. Problem Limited Routing Flexibility : Currently, buses in Loopy Pro can only send their output to the main output, restricting the ability to create complex routing scenarios. Monitoring Challenges : Users cannot monitor the combined effects of multiple channels through a single bus, making it difficult to set up cohesive monitoring environments. Workflow Limitations : The inability to route buses to other destinations limits creative possibilities and complicates setups that require shared effects processing or parallel routing paths. Benefits Enhanced Creative Control : Users can design intricate audio processing chains, such as parallel effects or subgroup processing, improving the overall sound design capabilities. Improved Monitoring : Facilitates the creation of dedicated monitoring buses with specific effects, aiding performers in hearing exactly what they need during live sessions. Streamlined Workflow : Reduces the need for workarounds or external routing solutions, allowing for a more integrated and efficient project setup within Loopy Pro. This summary was automatically generated by ChatGPT-4 on 2025-05-07.

Description: Improve control settings and preset management by adding undo/redo, search, filter, and advanced sorting options for MIDI bindings, actions, OSC directions, and plugin presets. Problem: Currently, managing large sets of mappings and actions is tedious and prone to error. Deleting entries in bulk is not possible. Labels can remain even after deletion due to bugs. There's also no way to recover deleted entries or track changes without undo/redo functionality. Proposed Solution: – Add Undo/Redo buttons scoped per section (e.g., MIDI bindings, actions, OSC, plugin presets) – Make list entries deletable via swipe (e.g., after accidental import) – Fix bug where labels don’t disappear after full deletion – Add search with auto-focus – Enable filtering – Support drag & drop sorting by: • Global profiles • Project settings • MIDI bindings • Actions • OSC directions • Plugin presets • Control Settings categories – All list items should support: • Reorder • Move between categories • Copy to category • Delete • Copy/paste • Move to another profile • Move up/down • One-click top/bottom move Benefits: ✅ Massively improved efficiency when editing bindings or presets ✅ Prevents accidental loss of work ✅ Much better clarity and control over large setups ✅ Brings consistency to all control-setting areas ✅ Saves time by avoiding full rebuilds of profiles This summary was automatically generated by ChatGPT-4 on April 30, 2025.

A way to ensure that... 1) song sections will always start from the beginning even if they are different lengths, and also 2) all the loops within each song section will always stay synced with each other THE PROBLEM: PHASE-LOCK VS FREE TRADEOFF While phase-lock is great for keeping loops synced, it doesn't work for songs that have multiple sections of differing lengths because when switching sections, the new section won’t necessarily start from its beginning. For example, if the verse is 4 bars and the chorus has an 8 bar loop, switching to the chorus after one verse means that the chorus will start playing from halfway through. While turning phase-lock off (aka "free looping") solves this problem and ensures that loops always start playing from their beginning, the user can no longer start loops at any time within that section and ensure that they stay synced. This is musically limiting and introduces risk of accidentally playing loops out of sync from each other. It’s especially problematic for sections with long loops. For example, if the verse is a 12 bar non-repeating chord progression, any of the 12 bar loops that aren’t started at the beginning of the verse can’t be added until the entire 12 bar verse comes back around to the beginning or else the loops will play out of sync. PROPOSED SOLUTION: INTERNALLY PHASE-LOCKED PLAY GROUPS Play groups should have the option of being "internally phase-locked", which would mean... 1) Whenever the play group is inactive (meaning none of its clips is currently playing or recording)... -All of the clips' playheads wait at the beginning and don't move -This is "non-phase-locked" aka "free" behavior 2) Whenever the play group becomes active (meaning any of its clips starts playing or recording)... -All the playheads of this play group start moving from the beginning (including for clips that aren't currently playing) and they all continue moving as long as any clip in that play group is still playing -This is essentially "phase-locked" behavior except for one important difference: rather than the playheads being synchronized from when the transport became active, they are instead synchronized from when the play group became active BENEFITS: NO MORE PHASE-LOCK VS FREE TRADEOFF Users no longer have to choose between the following benefits- they can have them all! -Song sections can be any length -Song sections will always start from the beginning -Loops within a song section can be started and stopped at any time, not just at the cycle boundary -Loops within a song section will always stay synced to each other While "Internal phase-lock" is probably most useful for mutually exclusive playgroups that "play and stop independently" (as in the verse/chorus use case described above), it could also be useful for “one at a time” play groups. For example, a “one at a time” play group might be made up of variations of a musical part (e.g. bass line variations) to be switched between but not played at the same time. Internally phase-locking this group would ensure smooth, synced switching even mid-loop. Note: “internal phase-lock” is not applicable to "all at once" play groups because by definition, they always start playing together so they can’t get out of sync

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 rename audio busses and optionally add visible notes or hints describing their function or purpose. Problem: Currently, busses in Loopy Pro are automatically named with letters (A, B, C...) upon creation, and users are unable to rename them. This makes it difficult to organize and recall bus functions, especially in complex projects with many busses. The default visual representation is also hard to distinguish from color groups, making the UI harder to parse quickly. Proposed Solution: – Allow users to rename busses at any time – Display the name prominently (e.g. at the top of the bus or next to the letter) – Optional: restore default letter-based name (e.g., "A") if custom label is deleted – Add support for a “hint” or “notes” field for each bus (shown e.g. on hover or toggle) – Consider visual improvements to further differentiate busses from color groups – Optional: provide a UI dialog showing an overview of a bus’s routing and settings, including name, balance, etc. Benefits: – Greatly improves clarity in complex routing setups – Reduces need for external “cheat sheets” – Helps identify and manage up to 24+ busses more efficiently – Enhances UI and UX, especially for live performance or sound design – Makes Loopy Pro more scalable and user-friendly for professional workflows This summary was automatically generated by ChatGPT-4 on April 30, 2025.