Feature Requests

Description: Show the currently installed version of Loopy Pro (stable or beta) on the initial splash screen when the app launches. Problem: Currently, there is no immediate visual confirmation of which version (e.g. beta or stable) is being run upon startup. While this information can be found in the settings, it's not visible during the app's launch—making it harder to quickly verify the build, especially when testing or switching between versions. Proposed Solution: Display the current version number (e.g. v1.1.24 (beta) ) on the splash/start screen. The version info could appear discreetly in a corner or beneath the Loopy Pro logo. It should display long enough to be readable, even if only for a second or two. Benefits: Provides immediate visual confirmation of the active version. Helps testers and beta users ensure they are running the correct build. Useful during troubleshooting, support requests, or when switching between app versions. Examples: A beta tester opens Loopy Pro and instantly sees “v1.1.24 (beta)” on the splash screen before the session loads. A live performer verifies that the stable version is running before a gig without needing to open the settings. This summary was automatically generated by ChatGPT-4 on July 30, 2025.

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.

Description: Allow users to toggle individual MIDI or Bluetooth controller instances on or off within specific project profiles using standard actions and follow actions . Problem: Currently, controller activation is tied to project profile structure. To manage two separate controller configurations (e.g. one Bluetooth, one wired), users must duplicate entire project profiles. For example, managing 8 setups for two controllers results in 16 total profiles. This becomes increasingly unsustainable in complex projects where many profiles are already used for other routing or behavior configurations. Proposed Solution: Add support for actions and follow actions that can enable or disable specific controller instances (e.g. “Bluetooth Controller A” or “Wired Controller B”) within any existing project profile. These toggles should be exposed as mappable actions and follow action targets, ideally with controller identifiers for precise control. Benefits: Reduces the number of project profiles required for managing multiple controller configurations. Greatly improves workflow efficiency and scalability in complex performance setups. Allows dynamic switching of controller roles (e.g. switching between foot controller and tabletop pad) without duplicating profiles. Enables context-based controller switching using gestures, MIDI triggers, or automation. Examples: A user has 8 project profiles for different performance sections. Instead of creating 8 duplicates for Bluetooth vs wired control, they assign a toggle to enable the relevant controller instance globally. A follow action at the end of a performance section disables Bluetooth control and enables wired MIDI, preparing for the next segment seamlessly. A MIDI pedal can toggle its own input handler on or off across all profiles it’s used in—without touching profile structure. This summary was automatically generated by ChatGPT-4 on August 3, 2025.

Description: Add a lightweight widget that listens to a chosen MIDI source and shows the currently detected chord (root, quality, extensions, inversion) in real time on the main canvas/template. Problem: When using generative MIDI tools (e.g., Scaler 2) or external keyboards, the chord name is only visible inside the AUv3 window. Keeping that window open is bulky, clutters the layout, and breaks the “single-screen performance” workflow—making it easier to lose track of the harmonic context. Proposed Solution: A “MIDI Chord Display” widget that can be placed anywhere in a template. It lets users select a MIDI source (track, bus, virtual input), filter by channel, and displays detected chords with low-latency smoothing and an optional “hold” time. Support common/extended chords, slash chords, and enharmonic preferences (C♯/D♭). Provide size/color/font controls, optional HUD overlay, and an action/variable to expose the current chord for labels, scripting, OSC, or automation. Benefits: Single-screen performance without AUv3 windows. Immediate harmonic feedback while playing or practicing. Works with any MIDI source (plugins or hardware). Useful for teaching, live looping, and backing-track workflows. Examples: Scaler 2 drives a chord progression; the widget shows “Bm7 → E7 → Amaj7” on the main page. External keyboard input is monitored; the widget displays “D/F♯” as you play. Use the exposed “current chord” variable to label sections, trigger scene changes, or send OSC to a lighting rig. This summary was automatically generated by GPT-5 Thinking on 2025-08-09. Original Text: My request is for a simple widget that can detect and display incoming Midi Chord information to display on the main template screen. I feel like it would be very helpful when utilizing generative midi apps like Scaler 2, to have the current chord displayed in Loopy pro without having to have the AUv3 window open. Personally I like to have Scaler 2 generate and play a base chord progression that I play along with. the AUv3 window for scaler 2 is a bit bulky and it is so nice to have no windows open to utiliize the full functionality of my LP template. having a small widget that could detect and display the incoming chord in real time would make playing along and not getting lost really easy.

Description: A MIDI keyboard widget that can be added to a layout in Loopy Pro, similar to the existing pads widget. This widget would facilitate a cohesive layout without the need to reposition or toggle the keyboard during a jam session. Problem: Currently, users rely on the Velocity Keyboard AU for most projects, but it lacks integration with Loopy Pro’s layout. Additionally, mapping a range of MIDI notes to multiple buttons is cumbersome, as each note must be assigned individually. There is also no simple way to transpose all keys together, such as using octave up/down buttons. Proposed Solution: Develop a built-in MIDI keyboard widget for Loopy Pro that offers: Velocity-sensitive key input similar to the Velocity Keyboard AU. Integrated octave up/down transposition for quick access to a broader note range. Flexibility to add, reposition, or hide the keyboard easily within a layout. Customizable layouts to accommodate different use cases, like live performance or studio setup. Benefits: Simplifies live setups by integrating a keyboard directly into the Loopy Pro interface. Reduces dependency on external AUs for basic MIDI input. Offers a more intuitive and flexible solution for MIDI control. Facilitates live looping by allowing quick transposition and note access. This summary was automatically generated by ChatGPT-4 on 2025-05-07.

Description: Enable users to globally reassign the MIDI destination for all MIDI-triggering actions within a project. This would allow for seamless redirection of output when switching to a different MIDI device or host. Problem: Currently, each action that sends MIDI is hard-linked to a specific MIDI device. When a project contains 100+ MIDI actions, replacing the destination device one-by-one becomes extremely time-consuming and error-prone. If the originally used MIDI device is unavailable or replaced (e.g. when using a different host or sharing a project), the project becomes effectively unusable. Proposed Solution: Introduce a centralized MIDI routing table or alias system. Allow users to reassign all MIDI actions linked to a given device to a new one in a single step. Optionally prompt for reassignment when a project is opened and the original MIDI device is not found. Benefits: Dramatically improves project portability across different setups. Saves time when replacing MIDI devices or migrating to new hardware. Makes project sharing between users or systems far more reliable. Avoids project breakage when devices are renamed, disconnected, or replaced. Examples: A user creates a full project using an external MIDI device. Later they switch to a MIDI host, and the destination names no longer match, rendering the entire project non-functional. During collaboration, another user imports the project but doesn’t have the same hardware; with global remapping, they can instantly reroute all MIDI outputs. This summary was automatically generated by ChatGPT-4 on July 24, 2025. Original Post: Possibility to replace MIDI destination for all actions All actions triggering MIDI are bound to 1 MIDI device. When +100 MIDI actions are created it's tedious to replace the destination one by one. Example: I made a whole project controling a MIDI device, But the day I choose to use a MIDI host, the device isn't the same in Loopy so my whole project is unusable. Also, it will be very useful in case of project sharing

Description: Introduce a “Select None” option in the clip action assignment interface, allowing users to clear existing actions from a clip without reassigning new ones. Problem: Currently, users cannot remove an assigned action from a clip easily; they have to overwrite it with another. This limitation complicates workflows where users want to disable an action temporary or reset a clip’s behavior. Removing actions often requires manual reconfiguration or workarounds. Proposed Solution: Add a “Select None” or “Clear Action” entry in the action dropdown menu for clips. Choosing this option removes any action binding from the clip. Ensure this clears visual indicators and disables associated triggers without affecting other clips. Benefits: Empowers users to disable clip actions easily and revert clips to default state. Enhances flexibility in dynamic setups, enabling quick changes without overwriting. Simplifies editing workflows and setup clean-up processes. Examples: Remove a clip’s “Mute” action during live performance without assigning another. Reset clip behavior in templates by clearing unwanted actions in bulk. Temporarily disable a clip-triggered effect and re-enable later by assigning a new action. This summary was automatically generated by ChatGPT-4 on 2025-06-30. Original Post: I imagine this would be very easy to add so I'll keep it brief.. Under Clip Actions > Select, can we please have the ability to select 'None'. I use clip select sometimes but other times I don't want anything to be selected (like when you first open a project). Thanks!

Problem: Currently, a template can only be used as default by manually choosing it via "New Project > Select Template". There's no quick way to promote a template to be the new default. Proposed Solution: Add an option in the template browser to set any template as the default ("Default of the defaults") with one click. Benefit: Saves time, reduces clicks, and makes it easier to start with your preferred setup – especially for users relying on customized defaults. This summary was automatically generated by ChatGPT-4 on April 30, 2025.

Description: Allow users to defer project tempo detection to a loop other than the first — enabling Loopy Pro to set the project tempo based on a later, user-selected loop. Problem: Currently, Loopy Pro determines and locks the project tempo based on the very first recorded loop. This limits flexibility in sessions where the first loop is not rhythmically relevant or is intended to be free-tempo (e.g. ambient texture, drone, or vocal swell). Users have no option to tell Loopy Pro to wait and derive the tempo from a different, later loop that better represents the intended timing. Proposed Solution: Add a feature that allows users to: Bypass tempo detection from the first loop Optionally choose which loop (e.g. second, third, or any later one) should define the project tempo Or let Loopy Pro auto-detect tempo from the first rhythmically meaningful loop This could be implemented as a toggle or dropdown in the project/session settings. Benefits: Greater control over when and how project tempo is set Enables free-form intros and ambient starts without locking the grid too early Better suited for complex arrangements and live workflows where rhythm develops gradually Improves compatibility with creative, non-linear loop layering Examples: First loop: ambient pad (no timing) → ignored Second loop: rhythmic guitar riff → sets tempo Third loop: beatbox loop → sets tempo while earlier ones remain unquantized This summary was automatically generated by ChatGPT-4 on 2025-05-17. Original Post: Currently, LP fix the project tempo thanks to the first loop recorded. The aim of this new feature is for LP to fix the project tempo thanks to the detection of the tempo of a loop other than the first one (or first ones pre-chosen).