Feature Requests

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 .

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: Add a dedicated way to open "Set Lists" directly from the main UI, without having to navigate deeper through the browser hierarchy. This should be optimized for quick, reliable access during performance. Problem: Accessing set lists can currently require multiple taps and context switches, which is slow and error-prone on stage (especially on smaller screens or when moving quickly between songs). Set lists are a performance-critical feature, and burying them behind additional navigation increases the chance of mistakes and interrupts flow. Proposed Solution: Provide one (or more) of the following UI options: 1) Main menu entry Add a direct "Set Lists" entry in the main menu, alongside the existing top-level destinations, so it is always one tap away. 2) Dedicated button under the folder (browser) icon Under the current main menu folder icon, add a distinct "Set Lists" button that opens the set list view immediately. 3) Optional floating "Set Lists" button (best for performance) Add a preference: "Show Set Lists Button". When enabled, display a floating button that opens the set list view instantly. Allow positioning anywhere on the canvas (drag to place), so left- and right-handed users can optimize access. Allow toggling visibility (on/off) in preferences to keep the UI clean when not needed. Benefits: Faster navigation between songs/projects in live scenarios. Reduced tap count and cognitive load under performance pressure. Better accessibility and ergonomics (especially with a movable/floating option). Encourages set list usage for larger libraries (dozens/hundreds of songs). Examples: Live set with 60+ songs: Tap the floating "Set Lists" button -> tap next song -> load immediately. One-handed operation: Place the floating button near the dominant-hand area for consistent, muscle-memory access. Clean studio layout: Disable the floating button and rely on the main menu entry when needed. This summary was automatically generated by GPT-5.1 Thinking on 2025-12-09 . Original Post: Dedicated Set List Menu Option 1: Have a direct link to 'set lists' in the main menu Option 2 (Better): Have a separate button under the current main menu folder icon just for setlist Option 3: A floating 'set list' menu button (that you can turn on and off in preferences) that you can position anywhere on the screen, so left or right handed people have options.

Description: Enable routing of AUv3 effects that expose multiple output buses (e.g. 4 outputs) so each output can be sent to different inputs/tracks for separate processing and mixing. Problem: Some AUv3 effects provide multiple discrete outputs (for example, separate taps, layers, or processing paths). Currently, these multi-output effects behave like single-output units, so their additional outputs cannot be routed independently. This prevents common workflows like splitting an effect's individual outputs to different tracks for separate EQ/comp/reverb, parallel chains, or distinct mixes. Proposed Solution: 1) Expose AUv3 output buses as routable nodes When an AUv3 effect reports multiple output buses, display each bus as a selectable output source (e.g. "Out 1", "Out 2", "Out 3", "Out 4"). Allow routing each bus to different inputs/tracks/mixers. 2) Add an output-bus selector per route (minimal UI option) In the routing UI, add a field like "Output Bus" for AUv3 effects. Default to the main/mixed output for compatibility, with manual selection for additional buses. 3) Clear channel/bus mapping and monitoring Show how each bus maps to channels (mono/stereo) to avoid confusion. Provide a safe fallback (downmix or "main out only") if a project is opened on a system where the AUv3 reports a different bus configuration. 4) Optional: per-bus level meters Lightweight metering for each exposed bus to confirm signal is present and routed correctly. Benefits: Unlocks advanced multi-chain workflows on iOS/iPadOS with AUv3 effects that are designed for multi-output operation. Enables separate processing per output (EQ/comp/reverb), parallel routing, and cleaner mixes. Makes complex performance setups more reliable and predictable (no hidden downmixing). Examples: Use Bram Bos Scatterbrain with its 4 outputs: - Route "Out 1" -> Track A (dry-ish) -> compressor - Route "Out 2" -> Track B -> shimmer reverb - Route "Out 3" -> Track C -> band-pass + delay - Route "Out 4" -> Track D -> distortion + limiter Sound design: Send different effect outputs to separate loopers/tracks to record and layer each output independently. Live mixing: Keep one output as the main mix, while routing another output to a dedicated track for sidechain or audience FX send. This summary was automatically generated by GPT-5.1 Thinking on 2025-12-09 . Original Post: Trying to use bram Bos Scatterbrain with its 4 ouputs in Loopy Pro but it seems that is not yet possible? Would be my main feature request to be able the route multiple outs from an fx to multiple inputs for seperate processing.

Description: Enable Loopy Pro to access and route individual outputs from multi-output AUv3 plugins. This would allow users to handle complex signal routing within Loopy itself, without needing to rely on external hosts like AUM. Problem: Currently, Loopy Pro does not expose the individual outputs of multi-output AUv3 plugins. As a result, users cannot route separate channels (e.g., drum parts or stems) to different buses, apply individual effects, or send them to discrete hardware outputs. This makes advanced mixing setups cumbersome and forces users to rely on external apps. Proposed Solution: – Detect and expose multiple output channels from AUv3 plugins – Allow routing of each AUv3 output to a different Loopy Pro bus or track – Enable per-output effect chains (e.g., reverb on snare, delay on hi-hats) – Permit discrete outputs to be routed to specific physical outputs on an audio interface – Maintain compatibility with AUv3 instruments like Digistix, Hammerhead, FAC Drumkit, Loopy AU (backing tracks), etc. – Provide clear UI to manage output-channel mapping within Loopy Pro’s mixer or plugin settings Benefits: ✅ Gives users full control over plugin output routing inside Loopy Pro ✅ Eliminates the need to use AUM or other routing apps for multi-output AUv3s ✅ Supports pro-level mixing setups with buses, FX, and separate audio interface outputs ✅ Makes Loopy Pro a more complete AUv3 host, especially for beatmakers and live performers ✅ Enhances flexibility for handling multi-part instruments and complex backing tracks This summary was automatically generated by ChatGPT-4 on April 30, 2025.

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: 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 the ability to control MIDI transposition amount via widgets or buttons within Loopy Pro. Problem: Users currently lack a direct and flexible way to control MIDI transposition on a specific channel in real time. This makes it difficult to adapt to different keys or transpose input on the fly, especially when performing or working with MIDI controllers or apps like Onsong. Proposed Solution: Provide widget actions to increase/decrease or set MIDI transposition value per channel. Allow widgets like buttons, sliders, or dials to control this. Make transposition optionally recallable and automatable for live use (e.g. key changes). Benefits: Enables key changes and MIDI mapping workflows directly via touch or MIDI-bound widgets. Essential for users working with live MIDI input, key-based instruments, or backing tools like Onsong. Aligns with other MIDI control needs (e.g., LFOs, scale mapping), providing consistency in the interface. This summary was automatically generated by ChatGPT-4 on 2025-05-02.

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!!!