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

Description: Add first-class OSC transmit so Loopy Pro can send Open Sound Control messages—alongside its existing OSC receive —from actions, follow actions, widgets, and mappings. Include typed arguments, bundles with timetags, quantized scheduling, reusable targets/profiles, and a built-in monitor. This enables many projects to run without TouchOSC , using Loopy Pro itself as the OSC hub. Problem: Loopy Pro already receives OSC, but cannot send it natively. That forces external bridges or companion apps to drive lights, visuals, mixers, or remote UIs—adding latency, setup complexity, and failure points. Tight, bar/beat-quantized cues are harder without host-level scheduling. Proposed Solution: OSC Targets: Named destinations (Host/IP, Port, UDP default, optional TCP/multicast), mDNS discovery, test ping, per-target rate limit and reconnect policy. Message Builder: Path (e.g., /loopy/clip/1/play ) with typed args ( int, float, string, bool, blob ). Variables/expressions usable in path and args (e.g., /tempo/{tempo.bpm} , {clip.name} ), presets for common cues. Bundles & Scheduling: Build OSC bundles with timetags ; schedule Now , Next Beat/Bar/Loop , or Cycle of Clip X with ±beat/ms offsets; integrates with late-press guards and cycle-synced ramps. Integrations & Triggers: Send on clip/transport/page events; bind to widgets/faders with delta thresholds and throttling (e.g., 30 Hz). Templates/Compat: One-click profiles for TouchOSC , Resolume , QLC+ , OBS , etc.; optional OSC Query to browse remote parameters and auto-generate mappings. Monitor & Debug: In-app OSC Monitor (timestamped log, resolved args, per-target counters, latency estimate), log-to-file, failure HUD. Security & Safety: Allowlist/local-network-only toggle, max message size/rate, pause during critical recording if desired. Presets & Actions: Project/page OSC Profiles and actions to Send OSC , Send Bundle , Select/Enable Target , Load Profile . Variables like osc.targetName , osc.lastLatencyMs , osc.sentCount . Benefits: Direct, low-latency control of lighting, visuals, mixers, and remote UIs without extra apps . Musically tight, bar/beat-quantized cues aligned to clips/scenes. Simpler rigs with fewer points of failure and clearer debugging. Reusable, portable profiles across projects and tours. Examples: On clip launch , send /layer/3/trigger to Resolume at next bar with {clip.name} as an argument. A tap-tempo widget also transmits /tempo and /timeSig to lighting; changes apply bar-quantized . A fader streams /mix/ch/1/fader {widget.value} to an external mixer, throttled to 30 Hz with Δ≥0.01. On scene load , fire a bundle: set synth program, switch OBS scene, and display a confirmation HUD on a remote tablet via TouchOSC— all from Loopy Pro . This summary was automatically generated by GPT-5 Thinking on 2025-10-08. Original Post: The option to not only recieve but also send OSC messages

Description: Enable support for AUv3 plugins with multiple audio inputs, including standard sidechain inputs on FX and instruments (e.g. FabFilter Twin 3), and allow flexible audio routing between tracks to use this functionality. Problem: Loopy Pro currently doesn’t support AUv3 sidechain inputs or multi-input routing. This limits its use as a fully capable DAW for those relying on dynamics control or complex routing setups (e.g. ducking via sidechain compression). Proposed Solution: – Implement routing of audio from one track to the sidechain input of a plugin on another track – Support AUv3 FX plugins with standard sidechain inputs – Support instrument AUv3 plugins that also include sidechain inputs (e.g. FabFilter Twin 3) – Allow use of multi-output AUv3 instruments with flexible routing to Loopy tracks or groups – Provide clear UI elements to manage input/output routing between tracks and plugins Benefits: – Makes Loopy Pro viable as a standalone DAW for advanced users – Enables mixing techniques like ducking, pumping, spectral sidechaining – Makes full use of AUv3 plugins that already support these features – Greatly enhances creative potential in sound design, live setups and dynamic control workflows This summary was automatically generated by ChatGPT-4 on April 30, 2025.