Feature Requests

Description: Allow a sequencer clip to define multiple loop regions (multiple loop points) and switch between them. This enables workflows like verse/chorus patterns, A/B/C sections, fills, and structured arrangements within a single sequencer clip without duplicating clips. Problem: With only one loop region per sequencer clip, users must duplicate clips or create multiple separate clips to represent different sections (Verse/Chorus/Fill). That leads to: More clutter in the clip grid. More triggers and more controller mappings to manage. Higher performance risk (triggering the wrong clip). Harder iteration when multiple sections should remain part of one coherent “song pattern” object. A multi-loop-region model would make the sequencer far more expressive and arrangement-friendly. Proposed Solution: 1) Multiple loop regions per sequencer clip Allow defining Loop Regions A/B/C… (each with start/end points). Display them in the sequencer UI as labeled regions. 2) Switching mechanisms Manual selection in the sequencer editor: choose active loop region. Actions: - Set Loop Region (A/B/C or by index) - Next/Previous Loop Region Follow Actions support: - Switch loop region at loop end, after N loops, or on cue. 3) Musical timing safety Optional quantized switching: - switch on next bar/beat - switch only at region end Optional “queue next region” behavior: - choose next region now, but change only when safe. 4) Optional advanced behaviors “Fill” regions that play once then return to the previous region automatically. Random region selection within a defined set (for generative sequencing). Benefits: Cleaner projects: fewer duplicated sequencer clips for sections. Faster arrangement building inside one clip (verse/chorus/fill as regions). More reliable live control: one clip can cover multiple sections with predictable switching. Enables generative and performance sequencing (queued fills, random region selection). Examples: Verse/Chorus: - Region A = Verse pattern, Region B = Chorus pattern. - Action switches regions quantized at the bar boundary. Fills: - Region C = Fill. - Trigger "Play Fill Once" action that switches to C for one cycle, then returns to A. Generative pattern: - Multiple regions configured; Follow Action randomly selects the next region every 4 bars. This summary was automatically generated by GPT-5.2 Thinking on 2026-01-18 . Original Post: Allow for MULTIPLE loop points in the squencer CURRENT STATE: The sequencer supports ONE, and only ONE loop point. There are WORK-AROUNDS, which take more work, more time, more confusion, more chance for error..... come one.... just do in right.... create a sequencer that allows multiple loop points. This may be similar to the feature request below. The functionality in the sequencer now is LAME, and workarounds are soOOOoo painful, and time consuming - like creating 1 bar empty loops that. I am wasting time making something that has a hidden secret meaning. This type of stuff destroys a users' confidence in the software. https://roadmap.loopypro.com/feature-requests/p/arrangement-markers-in-sequencer-with-bpm-time-signature-loop-sections-and-cue-c

Description: Allow a clip/loop to have a user-defined "bar start" position that is not necessarily the beginning of the audio. This enables loops where the musical phrase begins before the downbeat (pickup/anacrusis), while the loop still stays perfectly in sync with the clock when launched and stopped. Problems: Many real musical phrases start before the bar (pickup notes/words). With a strict "audio start = bar start" assumption, these loops feel wrong or require awkward workarounds. When launching such a loop, users want the pickup audio to be heard before the downbeat, while the downbeat still lands exactly on the bar. When stopping such a loop, users may want it to play through the remaining tail segment (including the "pre-bar" portion that conceptually belongs to the end of the cycle) so it ends musically instead of cutting early. Proposed Solution: 1) Add a "Bar Start Offset" (or "Cycle Start Marker") inside the clip In the clip editor, allow placing a marker that defines where bar 1 beat 1 occurs within the audio. The audio segment before this marker becomes the "pre-roll" pickup. 2) Launch behavior: pre-roll playback with synced downbeat When the clip is activated, playback can begin slightly before the bar so the pickup plays naturally. The defined bar-start marker aligns to the next quantized start point (beat/bar) so the groove is in time. 3) Stop behavior: finish the cycle musically When deactivating the clip, provide an option to continue playback until the end of the current cycle (including the segment after the bar start and then the wrapped pickup segment), so the clip completes the phrase cleanly. 4) Actions integration (optional but important for performance rigs) Actions to set/adjust the bar-start marker (nudge left/right, set to playhead, reset). Actions to choose stop behavior (stop immediately vs stop at cycle end). Benefits: Makes pickup-based musical phrases usable as tight, clock-synced loops. Eliminates the need to bake silence into files or duplicate/reshape clips as workarounds. More musical launches and stops during performance, especially with vocals and phrases that lead into the downbeat. Examples: "Roxanne" (pickup vocal before the bar). "All You Need Is Love" (pickup phrasing). "Purple Rain" style lead-in phrasing where the emotional pickup needs to happen before the groove locks in. Any vocal loop where the first syllable lands before the downbeat but the groove must still align exactly on bar start. This summary was automatically generated by GPT-5.2 Thinking on 2026-01-18 . Original Post: Shifted loops Sometimes, a vocal part begins a half note before the bar. I would love Loopy to give me the ability to select where the bar beginning is in the loop and synchronize the loop so whenever starting it I can hear that beautifully groovy premptive word(s) before the bar groove takes over. Think Police’s « Roxanne », or the Beatles’ « All you need is love », or Prince’s « Purple Rain ». In the attached example, a yellow vertical bar marks where the bar starts. when the loop is activated, it should begin a bit before so the pre-start bit is played along with the rest in time. also, when the loop is deactivated, it should play until it’s very end: which is until the relooped part before the bar start.

Description: Add metronome subdivision controls so the click can play not only the main beat, but also selectable subdivisions (e.g., 8th notes, 16th notes, triplets). This should be configurable per project (and ideally controllable via Actions) to support different practice and performance needs. Problem: A metronome that only clicks on the main beat is often insufficient: Users practicing tight rhythmic accuracy may need 8ths or 16ths for reference. Triplet-based feels (shuffle, 12/8) benefit from triplet subdivision clicks. For complex looping, users may want a stronger internal grid to stay locked without relying on visual cues. In performance contexts, different songs/sections may need different click densities (e.g., sparse click in verse, denser click in a fast section). Without subdivision options, users must rely on external metronomes or workarounds. Proposed Solution: 1) Add metronome subdivision setting Metronome options: - Off - Quarter notes (current) - 8th notes - 16th notes - Triplet 8ths (1/8T) - Triplet 16ths (1/16T) (optional) Optional: dotted values or 12/8 style patterns. 2) Accent behavior Keep the downbeat accent (and optionally beat accents) independent from subdivision ticks. Provide level controls for: - main beat click - subdivision click so subdivisions can be quieter and less intrusive. 3) Actions and automation (important for live use) Actions: - Set metronome subdivision - Toggle subdivisions on/off - Cycle subdivisions (optional) Allow binding these actions to widgets/MIDI. 4) Presets / per-song recall (optional) If setlists/songs have distinct settings, ensure subdivision choices recall correctly per song/project. Benefits: Better timing support for practice and tight performance. Makes triplet/shuffle feels easier to lock in. Reduces reliance on external click solutions. Enables section-specific click behavior when controlled via Actions. Examples: Fast piece: - 16th subdivisions at low volume to maintain tight timing. Shuffle/12-8: - Triplet subdivisions to reinforce the feel. Live looping: - Subdivisions enabled during recording setup, then switched back to quarter-only (or off) for performance. This summary was automatically generated by GPT-5.2 Thinking on 2026-01-18 . Original Post: Metronome subdivision I would like to have the option to select 8th ot 16th notes and triplets on the metronome

Description: Add an option for Tap Tempo so the project tempo is only updated after a user-defined number of taps (N), instead of changing immediately. This prevents accidental tempo changes from stray taps while still allowing deliberate tap-tempo use. Problem: Tap Tempo is extremely sensitive by design: even a single accidental tap can immediately change the global tempo. In live performance, accidental tempo changes are high-impact: They can throw loops, quantization, and synced effects off instantly. A user may brush a control unintentionally or trigger a bound tap action by mistake. Recovery can be stressful and disruptive mid-song. Users want Tap Tempo to be safer by requiring intentional input rather than reacting to one or two unintended taps. Proposed Solution: 1) Add a Tap Tempo safety setting Preference (global) or per-widget/per-binding option: - "Update tempo after N taps" - N configurable (e.g., 2–8 taps) Default remains current behavior to preserve existing workflows unless enabled. 2) Define behavior while accumulating taps Until N taps are received: - Do not change tempo (hold current tempo). - Optionally show a small indicator: "Tap tempo: 2/4" to confirm progress. On the Nth tap: - Set the tempo based on the last (N) taps (typical tap-tempo averaging). 3) Optional timing rules (nice-to-have) Timeout: if taps stop for X seconds, reset the tap counter. Optional "use last N-1 intervals" averaging to improve stability. Optional "quantize apply" to next bar/beat to avoid mid-bar disruption (if desired). 4) Actions/MIDI binding integration Ensure this safety rule applies equally whether Tap Tempo is triggered from: - a UI button, - a widget binding, - or a MIDI/foot controller. Benefits: Prevents catastrophic accidental tempo changes in live sets. Makes Tap Tempo practical on crowded performance pages and foot controllers. Allows deliberate tempo setting with controlled confidence. Reduces stress and improves reliability for tempo-synced workflows. Examples: Live safety: - Set N = 4 taps. A single accidental tap does nothing; only an intentional 4-tap sequence updates tempo. Foot controller: - Tap tempo is bound to a pedal; N-tap requirement prevents tempo change from an accidental pedal bump. Stable update: - User taps 6 times; tempo is computed from the last intervals and applied once, yielding a smoother result. This summary was automatically generated by GPT-5.2 Thinking on 2026-01-18 . Original Post: Tap tempo: trigger change after N taps to avoid accidental changes I tap tempo very often so i've put in on the most accessible button on my foot controller. This button is also quite easy to hit accidentally - sometimes even 2 times, which is enough to change the tempo. Happens quite a lot to me. Especially frustrating, 'cause tempo changes cannot be undone with Undo action. If I could set it to e.g. 4, I think it'd fix the issue - it's very low chance to tap 4 times accidentally in a short time

Description: Add support for a second, independent app window/view when an iPad is connected to an external display. This should allow the iPad and the external screen to show different parts of the project simultaneously (e.g., operate clips/widgets on the iPad while showing Mixer/Sequencer on the external display). Problem: Using a single iPad screen forces frequent view switching during performance and setup: Users often need to see and control clips/widgets while also monitoring the mixer, meters, routing, or the sequencer. Mirroring to an external display does not solve this, because it still shows only one view at a time. For live performance and studio workflows, simultaneous visibility of multiple views reduces mistakes and speeds up operation. Proposed Solution: 1) External display mode with a dedicated second view When an external display is connected, provide an option: "Use External Display as Second Window". The external display shows an independently selected view, while the iPad remains fully usable with its own view. 2) Assignable views per screen Allow choosing what each screen displays: - iPad: Clips/Canvas/Widgets (typical performance control) - External: Mixer, Sequencer, Set List, Browser, Meters, etc. Provide quick switching and persistence (remember per-project or global preset). 3) Interaction model options If the external display is touch-capable: allow direct interaction on the external screen. If it is not touch-capable: keep the external screen as a “monitor” view, and allow controlling it from the iPad (optional pointer/cursor support if applicable). 4) Performance-safe features Optional "Lock external view" to prevent accidental edits. Optional high-contrast / large text mode for distance viewing. Clear indicator of which screen is showing which view. 5) Compatibility and fallback If the platform cannot support true dual independent UI in a given mode, provide the best possible fallback (e.g., a dedicated “external monitor” view) while keeping behavior predictable. Benefits: Dramatically less view switching during live use and setup. Better situational awareness: keep clips/controls visible while monitoring mixer/levels/sequence. Makes an external display genuinely useful (not just a larger mirror). Improves reliability and speed for complex projects. Examples: Live performance: - iPad shows performance widgets + clip triggers; external display shows Mixer with meters and FX chains for monitoring. Production/editing: - iPad shows Clips and clip editing; external display shows Sequencer timeline. Troubleshooting: - iPad remains on the main performance page; external display stays on routing/mixer to quickly identify where signal is going. This summary was automatically generated by GPT-5.2 Thinking on 2026-01-18 . Original Post: Second Loopy Window when using a second display If I have a computer screen connected to my iPad, it would be good to have a second loopy per window. For example, you could operate the loops and controls on the Ipad, while the sequencer and the mixer are displayed on the screen.

Description: Introduce a new type of clip: AUv3 Clips. These would function similarly to Audio and MIDI Clips, but are directly tied to AUv3 plugins. Each clip could instantiate and control its own AUv3 plugin instance with specific state, allowing highly modular, per-clip plugin behavior. Problem: Currently, AUv3 plugins must be assigned at the channel level, limiting flexibility. If a user wants a specific plugin to behave differently across different clips, they must use multiple channels, which becomes inefficient and cluttered. There is no way to encapsulate AUv3 plugin states within a clip itself. Proposed Solution: – Add a third clip type: AUv3 Clip – Each AUv3 Clip can load and store its own AUv3 plugin instance and state – Clips can load different plugins, presets, or plugin configurations – Include per-clip plugin automation and recall – Allow AUv3 Clips to be used in the sequencer and timeline like any other clip – Support seamless switching between clips with different AUv3s, without audio dropouts – Provide options to pre-load plugins or load on activation to optimize performance Benefits: ✅ Enables highly modular setups with clip-specific sound sources ✅ Allows radically different processing chains per clip without extra channels ✅ Makes Loopy Pro more DAW-like while staying loop-oriented ✅ Ideal for creative sound design, plugin chaining, and live performance setups ✅ Simplifies session organization and expands creative potential of the clip model This summary was automatically generated by ChatGPT-4 on April 30, 2025.

Description: Users would like to have a new type of loop specifically designed for automation within MIDI learning workflows. This loop type would exclusively record automation data, never audio, allowing for precise control over MIDI parameters. Problem: Currently, there is no dedicated loop type that can record and manage automation separately from audio. This limitation makes it difficult to create complex automation sequences, especially when using MIDI learning for live performances or automation stacking. Proposed Solution: Introduce an "Automation Clip" that functions solely as a container for MIDI automation data. These clips could support overdubbing, stacking, and be triggered via button presses or gestures. Additionally, users should have the option to combine one-shots or loops to control sequences and playback of other clips. Benefits: Enhanced control over MIDI automation workflows. Allows for complex automation stacking and precise triggering. Facilitates more dynamic live performances by separating audio and automation loops. This summary was automatically generated by ChatGPT-4 on 2025-05-07.

Description: Add an Ableton Link offset adjustment so users can compensate timing differences between linked apps/devices. This should allow positive or negative offsets (in milliseconds) to align metronomes, clip launches, and tempo-synced behavior when Link timing is consistently early/late relative to other peers. Problems: In real multi-device setups, Link can feel slightly late/early due to audio buffer sizes, interface latency, routing, or host/driver differences. Some apps (e.g., AUM) provide a Link offset control that makes it possible to line up metronomes and downbeats precisely; without an offset control here, users have to add external hosts/workarounds just to correct timing. oai_citation:0‡Loopy Pro Live reliability suffers when two linked systems are almost in sync but not perfectly, especially for click alignment, tight rhythmic performance, and synchronized recording/launching. Proposed Solution: 1) Add a Link Offset parameter A simple control: "Link Offset (ms)" with negative/positive values. Range should be wide enough for practical compensation (e.g., at least +/- 100 ms), with fine resolution (0.1 ms or 1 ms depending on implementation). Display current effective offset clearly. 2) Scope options Global setting (applies to all projects), and/or per-project override. Optional per-session behavior: remember the last offset used with Link enabled. 3) Integration with Actions and bindings (important for performance rigs) Actions: - Set Link Offset (ms) - Nudge Link Offset (plus/minus step) - Reset Link Offset to 0 Allow MIDI binding so a user can quickly calibrate on stage or during rehearsal. 4) Usability and safety Optional quick calibration helper: - Tap-based or metronome alignment aid (visual) to help users find the correct offset quickly. Ensure the offset affects Link timing alignment only, without unexpectedly altering unrelated latency compensation features. Benefits: Enables tight metronome alignment between linked peers without external hosts. Faster setup for mixed rigs (iPad + desktop, multiple iPads, different interfaces). More reliable clip launching and tempo-synced effects when Link is used as the shared clock. Reduces the need to insert additional apps just to fix timing. Examples: iPad + desktop: - User hears the desktop click slightly ahead; set Link Offset to -16 ms (example) until clicks align. Multi-iPad rig: - Different buffer sizes cause small drift in perceived attack; offset corrects consistent lead/lag. Live recalibration: - Bind nudge actions to a controller to fine-tune Link offset during soundcheck. This summary was automatically generated by GPT-5.2 Thinking on 2026-01-18 . Original Post: Ableton Link offset option AUM provides an Ableton Link offset adjustment feature. It would be great if Loopy Pro offered the same functionality.

Description: Add the ability to explicitly set the MIDI output channel (or channel set) used by MIDI-generating features such as MIDI Clips (loops) and MIDI One Shots, so users can control where outgoing note/CC data is sent. Problem: At the moment, MIDI Clips and MIDI One Shots cannot be configured to send on a specific MIDI channel. This is a significant limitation because selecting an output channel is standard practice across MIDI hardware (keyboards, pads, controllers) and MIDI-generating software (sequencers, arpeggiators, generative tools). Without per-source channel control: MIDI generated inside the app can collide with other MIDI sources (external controllers, AUv3 MIDI generators, other tracks). Users cannot isolate internal MIDI for routing, filtering, or bindings. Workflows that depend on "channel separation" become fragile and require messy workarounds. A concrete use case: a simple MIDI Clip with a few notes is used to trigger button widgets via MIDI bindings. The user wants those notes to be sent on (for example) MIDI Channel 5 to avoid interfering with other notes coming from plugins or external hardware. Proposed Solution: 1) Per-clip / per-one-shot MIDI channel setting Add a "MIDI Output Channel" parameter to MIDI Clips and MIDI One Shots. Support at least: - Single channel (1-16) - "All channels" / "Omni" (for backward compatibility and special cases) 2) Optional: multi-channel selection If feasible, allow selecting multiple channels (e.g. 1+2+10) or a channel range, for advanced routing. 3) Consistent availability anywhere MIDI is generated Apply the same concept anywhere the app generates MIDI notes/CC internally (e.g. MIDI clips, one shots, virtual keyboard, other MIDI emitters if present), so the behavior is predictable and consistent. 4) Safe defaults and project compatibility Default existing projects to the current behavior (e.g. "All channels" or the current implicit channel behavior), so nothing breaks on update. Clearly display the selected channel in the relevant editors and inspectors. Benefits: Proper channel isolation for complex rigs and multi-device setups. Prevents unintended MIDI interference between internal MIDI, AUv3 MIDI generators, and external controllers. Enables cleaner routing, filtering, and bindings (especially for performance control schemes). Aligns with established MIDI standards and user expectations. Examples: Widget triggering without collisions: - A MIDI Clip sends four notes on Channel 5. - MIDI bindings listen only on Channel 5, so external keyboards (Channels 1-2) do not accidentally trigger widgets. Multi-instrument routing: - One Shots on Channel 10 trigger a drum module. - MIDI Clips on Channel 2 trigger a bass synth. - Live keyboard on Channel 1 stays independent. Template reliability: - A performance template project uses dedicated channels for internal automation clips (e.g. Channel 16). - Copying the template preserves channel discipline and prevents setup drift. This summary was automatically generated by GPT-5.2 Thinking on 2025-12-27 . Original Post: Sadly.... right now, you CANNOT specify which channel or channels a MIDI Clip (loop) or MIDI One Shot - broadcast, or sends MIDI data /notes out on. Very Sad STANDARD of PRACTICE: Pretty much EVERY MIDI generating plugin or software (Harmony Bloom, Rozeta, etc.) and EVERY MIDI generating hardware, like keyboards of all types, drum pads, etc. --- they ALL let you specific or setup which MIDI Channel(s) to send MIDI out on. RATIONALE: Since LP is not following the standard or best practice.... that should be enough itself. HOWEVER.... use case: I have a MIDI Clip (loop) with 4 simple notes, that I created in the LP Editor. I will use these 4 notes to trigger button widgets, via a MIDI binding in the control profile. I want these 4 MIDI notes sent out on MIDI Channel 5 so as not to interfere with any other MIDI notes - from plugins (MIDI generators) or physical keyboards, or physical drum pads. REQUEST: In any place in LP where MIDI can be generated, e.g. MIDI clips (loops), MIDI One Shots, Virtual Keyboards .... (did I miss anything ?) ; add functionality in the software to let the user setup which MIDI channel the MIDI is sent out on.

Description: Add Actions to change a group’s mutual exclusivity behavior at runtime. This allows users to dynamically switch whether clips in a group can play simultaneously or whether starting one clip should stop the others. Problem: Mutual exclusivity is a powerful structural control (e.g., verse/chorus switching, one-of-many variations), but today it is typically a static configuration: Users may want the same group to behave differently at different times. - Example: during a build, allow layers to stack; during the main arrangement, enforce “only one at a time”. Without runtime control, users must create duplicate groups/pages or redesign clip layouts to achieve dynamic behavior. This limits performance flexibility and complicates controller-driven workflows. Proposed Solution: 1) Add group exclusivity Actions Provide Actions such as: Set Group Exclusivity: Exclusive / Non-Exclusive Toggle Group Exclusivity Optional: Set Exclusivity Mode variants if more than one exists (e.g., "Stop others on start" vs "Fade out others" if supported) 2) Scope and target selection Target a specific group by name/ID. Optional: apply to selected groups, or "current group". 3) Performance-safe timing (optional) Allow exclusivity changes to be: - immediate, or - quantized (next beat/bar) to avoid unexpected mid-bar stopping behavior. 4) Clear UI feedback Show an indicator that exclusivity was changed (and current state) to prevent confusion during performance. Benefits: Enables dynamic arrangement behavior without duplicating groups or redesigning layouts. Supports advanced performance macros: switch from “layering mode” to “section switch mode” instantly. Makes controller-driven rigs more expressive and less brittle. Reduces project complexity by keeping a single group that can change behavior when needed. Examples: Build-up layering: - Set group to non-exclusive so multiple clips can stack during a crescendo. - Then set group to exclusive for verse/chorus switching. Rehearsal vs show: - Non-exclusive during rehearsal for experimentation. - Exclusive during show for strict arrangement control. Footswitch macro: - One footswitch toggles group exclusivity while another triggers next clip, enabling different behaviors on demand. This summary was automatically generated by GPT-5.2 Thinking on 2026-01-09 . Original Post: An action to adjust group mutual exclusivity It would be great if there were an action to adjust group mutual exclusivity. This would allow me to easily create scenes on-the-fly.