Feature Requests

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: 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 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: 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: Add a global toggle in system settings to disable the automatic assignment of audio inputs and outputs when devices become available. Problem: Loopy Pro currently assigns available inputs and outputs automatically (e.g. assigning inputs to the internal mic and outputs to channels 1+2). This behavior can cause unexpected feedback loops—especially when an iPad is disconnected from a larger audio interface (e.g. a 16-channel interface) and reverts to internal I/O without warning. This can result in loud feedback if a track is unmuted unknowingly. Proposed Solution: Introduce a system-wide setting to disable automatic input/output mapping . When this option is active and an interface is unavailable, mapped channels should remain unassigned and be visually indicated (e.g. greyed-out). This avoids unintended re-routing and gives the user full manual control over signal flow. Benefits: Prevents feedback or unintended audio routing when interfaces are disconnected or unavailable. Provides a more robust workflow for users with complex setups. Does not interfere with users who prefer the current default (auto-mapping), as it is an opt-in toggle. Examples: A user disconnects their main audio interface and reopens a project—without this toggle, all tracks map to the internal mic and speakers, causing a feedback loop. With the toggle enabled, all I/O would be clearly marked as unavailable until reassigned manually. This summary was automatically generated by ChatGPT-4 on July 30, 2025. Original Post: Add: System setting toggle for automatically assigned input / output Default behavior of the mixer is setting the input / output automatically as they are available. This behavior makes me worried when iPad is not connect to main system (with audio interface that has 16 I/O). Having the individual outputs mapped to [1+2] and all inputs to internal mic causes feedback if any channel is unmuted and this has happened to me multiple times. I am not sure if saving newly made widgets with different audio interface, or no audio interface connected messes up the audio routing. Most robust idea that I have that does not affect those who like the default behavior is to add a toggle at system settings to not automap inputs and outputs. When mapped channels are not available, greyed out graphics as a feedback would be helpful.

Description: Introduce a mappable action that allows users to toggle input monitoring on audio inputs or tracks using external hardware—such as a MIDI controller (wired or Bluetooth) or a computer keyboard. Problem: In setups with external audio interfaces featuring multiple inputs and outputs, users frequently need to enable or disable input monitoring—for example, during recording sessions in Loopy Pro. Currently, this must be done manually via the Mixer Input settings, which can interrupt workflow and is not easily accessible in live or hands-free situations. Proposed Solution: Provide a general-purpose Loopy Pro Action that toggles input monitoring for a selected input or track. Make this action assignable to: - External MIDI controllers (including Bluetooth-enabled devices) - Bluetooth or USB keyboards (e.g. Apple Magic Keyboard) Benefits: Enables fast and hands-free toggling of input monitoring during live recording or performance. Greatly enhances workflow efficiency in multi-input environments. Reduces the need to navigate deep into menus for a frequently-used function. Particularly helpful for mobile users working without constant screen access. Examples: A user working with a Focusrite Clarett+ interface disables input monitoring with a keyboard key when tracking vocals, then re-enables it after take completion. A Bluetooth MIDI footswitch toggles monitoring for a specific channel mid-performance—without any need to access the Mixer view. This summary was automatically generated by ChatGPT-4 on July 28, 2025. Original Post: External Keyboard / MIDI Action for Input Monitoring When using external audio interfaces with multiple in- and outputs, I often need to disable monitoring of my incoming audio via the Mixer Input settings when I’m tracking in Loopy Pro. It would be very handy if we could switch this setting with a single Apple Magic Keyboard or any other (bluetooth) MIDI controller binding.

Description This feature request proposes the implementation of a mechanism within Loopy Pro that allows users to trigger specific actions when faders or knobs reach predefined positions. This functionality would enable more dynamic and responsive control setups, enhancing live performance capabilities and workflow efficiency. Problems Limited Interactivity : Currently, faders and knobs in Loopy Pro adjust parameters but cannot trigger actions based on their position, limiting their utility in complex setups. Workflow Constraints : Without the ability to initiate actions at specific control positions, users must rely on additional buttons or external controls, complicating the interface. Reduced Expressiveness : The inability to link control positions to actions restricts creative possibilities during live performances and sound design sessions. Proposed Solution Position-Based Action Triggers : Introduce the ability to assign actions that are triggered when a fader or knob reaches a specific value or crosses a threshold. Customizable Thresholds : Allow users to define multiple thresholds per control, each linked to different actions, enabling complex interaction schemes. Integration with Existing Systems : Ensure compatibility with Loopy Pro's MIDI Learn system, widgets, and automation features for seamless integration. Examples Dynamic Effect Activation : A performer sets a fader so that increasing the value beyond 75% automatically enables a reverb effect, while decreasing it below 25% disables the effect. Scene Switching : A knob is configured to trigger different scenes or sections in a performance as it passes through defined positions, streamlining live transitions. Parameter Modulation : Crossing a specific threshold on a control could initiate a modulation sequence or trigger a sample, adding expressiveness to performances. Benefits Enhanced Control Flexibility : Users can create more interactive and responsive control setups, reducing the need for multiple dedicated controls. Improved Workflow Efficiency : Automating actions based on control positions simplifies complex tasks, making the interface more intuitive. Expanded Creative Possibilities : Linking control positions to actions opens new avenues for creative expression in both live and studio environments. This summary was automatically generated by ChatGPT-4 on 2025-05-17. Original Post: Example: you added a fader on canvas – with let's say 16.383 steps (what is the maximum of 14 bit MIDI btw, right? – MIDI 2.0 will give us even finer resolution: 32-bit. Hopefully MIDI 2.0 won't take another decade – those inaccurate 0-127 steps are just not fine resolution enough.) Let's say (just an example) you can set up two ranges. One range is between 2.000 and 3.999. The second range is between 5.000 and 5.500. When reaching position 2.000 (or dialing from the opposite (downwards), reaching position 3.999) the fader will send an action. Then later at position 5.000 (or dialing from the opposite (downwards), reaching position 5.500) the fader will send another action. Now another but more very flexible example: let's say you have this said fader on your canvas with all said above BUT now the range between 2.000 and 3.999 is sending constantly values (for instance to MIDI or another already in canvas available fader or to an AUv3 plugin knob/fader parameter).

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.