Feature Requests

Description: Introduce visual feedback for text widgets when they are triggered or active, similar to button widgets. Since text widgets do not have a visible body by default, state feedback could be implemented through color changes, such as text inversion or background highlighting. Problem: Unlike button widgets, text widgets currently offer no visual feedback when triggered. This makes it difficult to confirm whether a text-based trigger has been activated during performance or editing. The lack of state indication reduces usability for workflows that rely on text widgets as controls. Proposed Solution: Implement state feedback via visual changes such as: – Inverting text and background colors on trigger – Switching from default (e.g. white) to a user-defined highlight color Ensure the feedback is optional and configurable for each widget. Benefits: Provides immediate visual confirmation of trigger or toggle state. Makes text widgets more usable as interactive controls. Enhances accessibility and confidence in live setups. Examples: A text widget labeled “RECORD” turns red when activated. Text inverts to black-on-white when toggled, and reverts when idle. Color changes only last during the trigger state or remain toggled until reset. This summary was automatically generated by ChatGPT-4 on 2025-07-05. Original Post: Text widget state feedback Same as for the button, but because there is no "body" for the text widget, maybe a reasonable solution is to invert the color of the text widget. Or the default state is "white" and triggered is a specific color.

Description: Introduce the ability to convert an empty clip between MIDI and Audio formats without deleting and recreating the clip. The clip would retain all metadata—such as position, color, play group, and mappings—while switching its type. Problem: Currently, switching from a MIDI to an audio clip (or vice versa) requires deleting the original clip and creating a new one. This disrupts workflows by breaking mappings, color assignments, and positioning. It makes experimenting with different formats tedious and time-consuming. Proposed Solution: Allow conversion of an empty clip slot from MIDI to Audio and vice versa via context menu or inspector toggle. Retain all clip attributes (e.g. index, color, group, mappings) during the conversion. Optionally, allow clips to hold both MIDI and Audio data simultaneously, with toggleable routing. Benefits: Speeds up workflow when changing clip types during song development or performance prep. Reduces the need to rebuild mappings or layouts when switching formats. Encourages experimentation and flexibility in session design. Examples: Start with an empty MIDI clip for sketching, then convert it to audio for final recording. Switch a routed clip from MIDI to audio based on current section needs. Clip retains its visual and functional identity even after format change. This summary was automatically generated by ChatGPT-4 on 2025-07-05. * Original Post: For different songs or sections of songs, sometimes I want to use a MIDI clip and other times I want to use an Audio clip. It would be amazing if we could quickly convert one to the other without deleting, then re-adding, and then checking/redoing all the mappings, settings etc. So for example, Clip 1 always remains Clip 1, in the same Colour Group, Play Group, mappings, etc, but you can quickly change it from MIDI to Audio and vice versa. Thanks!! Keep up the amazing work!

Description: Improve the Loopy Pro preset manager by aligning it with 7-bit MIDI program change and bank change messages. This would include default MIDI mapping from 000 to 127 (AUV3 standard) and improve compatibility with external MIDI hardware and plugins. Problem: MIDI program and bank change support varies across AUV3 plugins. There’s no consistent implementation, which complicates preset handling and controller integration. Users have no easy way to map program changes to default AUV3 states or toggle numbering schemes. Proposed Solution: Add support for preset banks indexed 000–127 (7-bit MIDI spec) to match AUV3 default states. Include options such as: – Setting a custom “initial” patch. – Global setting to toggle between numbering systems (e.g. 000→127 or 001→128) to match different hardware conventions. Ensure smooth mapping between MIDI messages and plugin state recall. Benefits: Enhances interoperability with MIDI hardware and plugin standards. Brings Loopy Pro closer to the experience of traditional hardware-based instruments. Reduces confusion around patch numbering inconsistencies between devices. Examples: Use a MIDI controller to recall plugin presets 012, 045, or 099 by sending program change messages. Match numbering between Loopy Pro and external synths or effect units. Define a starting preset per project or session as an “initial” state. This summary was automatically generated by ChatGPT-4 on 2025-07-12. Original Post: Midi program change and bank change messages are part of MIDI which is not always implemented in the Auv3, and when this is implemented the level of implementation varies greatly. My suggestion is to update the Loopy Pro preset manager to match 7-bit midi messages, with numbered banks, filled with auv3 default state from 000 -> 127. Extra features to this: custom "initial" patch system setting to toggle numbering from 000 -> 127 / 001 -> 128 ( as there is variance on how the program change messages are presented in different software / hardware) Goal of my feature suggestion is to bring software to resemble the ease of use of hardware instrument and effect.

Description: Allow Loopy Pro to use the internal microphones of iOS devices (e.g., top and front mics) as a stereo input source, enabling true stereo recording directly from the device without needing external hardware. Problem: Currently, Loopy Pro does not offer stereo input from built-in microphones, even though other apps (e.g. AUM by Kymatica) can access and utilize them. Users are limited to mono recordings, which restricts spatial realism and depth in acoustic recordings or field sampling. This creates a disparity between Loopy Pro and other iOS apps that offer advanced input routing. Proposed Solution: Add support for stereo mic configuration using available internal microphone channels (e.g., front = Left, top = Right). Make stereo input available as an input option in the routing matrix and Audio Input Devices menu. Clearly label internal mic channels so users can assign or disable individual sides as needed. Benefits: Unlocks the full potential of iOS devices for stereo field recording and live looping. Enables immersive soundscapes, realistic instrument capture, and spatial stereo effects. Eliminates the need for external stereo mic hardware in many situations. Examples: Record a stereo loop with natural room ambiance using only the iPad/iPhone’s built-in mics. Use stereo mic input for voice layering or binaural field recordings. Combine with panning and spatial FX in Loopy Pro’s mixer for dynamic performance setups. This summary was automatically generated by ChatGPT-4 on 2025-07-12. Original Post: In other apps, it is possible to create stereo recordings using the front and top microphones. Please enable this capability.

Description: Improve the MIDI editing experience in the piano roll by introducing draggable floating buttons or proxy widgets to manipulate MIDI notes without covering them with the finger during drag operations. Problem: When dragging MIDI notes on a touchscreen, the user's finger often obscures the note being moved. This makes it difficult to see the exact pitch or time placement during adjustments. It slows down precise editing and leads to frequent corrections. Proposed Solution: Implement floating editor buttons or draggable proxies for selected MIDI notes. These buttons could appear above, below, or to the side of the actual note and mirror its movement. Take inspiration from NanoStudio 2’s discontinued implementation, where dedicated floating widgets provided unobstructed editing. Benefits: Enhances visibility and control during MIDI editing. Enables more accurate pitch and timing adjustments. Makes touchscreen MIDI editing faster, smoother, and less error-prone. Examples: Drag a floating handle next to a note instead of the note itself to move it. Floating controls stay visible while your finger remains offset. Reduce reliance on zooming in for precision adjustments. This summary was automatically generated by ChatGPT-4 on 2025-07-12. Original Post: Issue: When trying to adjust/move a midi note in the piano roll editor, my finger is almost always obscuring the currently dragged note entirely, so it's hard to see and know where the note ends up. Potential Solution: The discontinued NanoStudio 2 had implemented a great solution to this issue with its floating widgets/buttons, that can be dragged as proxy for the selected notes: https://www.blipinteractive.co.uk/assets/img/song-editor.jpg (see bottom and right) I hope loopy can take inspiration from this.

Description: Add a dedicated “dummy” or “placeholder” plugin that can be used in templates to reserve routing configurations. This would allow users to pre-configure routings without committing to a specific plugin or audio source up front. Problem: Setting up routings in the mixer can be time-consuming, especially in complex templates. While Loopy Pro retains routing paths when replacing plugins, users currently rely on third-party plugins (like Streambyter) as placeholders to preserve those routings. This workaround is inefficient and may cause confusion or unnecessary system load. Proposed Solution: Create an official dummy plugin that takes no audio/MIDI resources but can occupy a plugin slot with routing preserved. Allow the placeholder to be swapped with real plugins without resetting its routing state. Include an “idle” state so the dummy plugin uses no CPU or I/O resources while in place. Benefits: Greatly reduces time spent configuring and reconfiguring routings in templates. Allows users to build flexible, modular setups that can be activated as needed. Prevents accidental routing loss when replacing plugins during setup or performance. Examples: Insert dummy plugins in a template and route them to buses or outputs in advance. Later, replace dummy slots with real synths or effects without losing connections. Use placeholder plugins to prepare alternate setups without committing plugin resources. This summary was automatically generated by ChatGPT-4 on 2025-07-12. Original Post: I like to spend as little time as possible in the mixer setting up routings. The audio source replacement feature is wonderful how it retains routings. In my templates I like to have several placeholder plugins with all my needed routings sitting idled. Then I can just replace the dummy instances, un-idle them and save a huge amount of time. I'm using the Streambyter plugin as a hack plugin, but think Loopy could benefit from such a Placeholder plugin, and I bet it would be fairly simple to produce.

Description: Add an option to toggle anchoring on or off for individual text widgets in the Text Edit window. This would allow some text widgets to remain anchored to screen positions, while others can be freely placed anywhere within the canvas. Problem: Anchoring is powerful and useful, especially for structured templates. However, there are situations where a user may want to position a text widget arbitrarily, without it snapping or sticking to layout constraints. Currently, anchoring behavior is not individually configurable, which limits flexibility for design workflows. Proposed Solution: Provide a per-widget toggle to enable or disable anchoring. When anchoring is off, allow freeform positioning within the canvas. This toggle should be easily accessible in the Text Edit window or widget settings. Benefits: Supports hybrid layouts with both structured and freely placed text elements. Enhances creative flexibility, especially in templates and visual arrangements. Enables users to preserve the power of anchoring without being restricted by it. Examples: Anchor one text label to the top-left corner, while placing another label arbitrarily for visual effect. Use precise anchored alignment for controls, and unanchored notes for user guidance or temporary info. This summary was automatically generated by ChatGPT-4 on 2025-07-05. Original Post: On/Off text anchoring inside Text edit window So I can set one Text widget sticking but another one is not. While anchoring is amazing and it is one of my core trick for my new template, sometimes I want to place text at a random position.

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!

In lots of apps, a double tap in space on the piano roll selects all notes. This would be great.

Description: Enable more flexible clip targeting by allowing selection based on both Colour and Play Group simultaneously. This eliminates the need for switching profiles on MIDI controllers just to target different Play Groups. Problem: In setups with multiple Colours and Play Groups, users often rely on MIDI controller profiles to switch between control targets. For example, a 6×4 grid controlled by a MIDI foot controller may require profile changes to address different Play Groups. Profile switching can cause visual glitches (e.g., flashing buttons on devices like the APC40 mkII) and disrupt live performance flow. Maintaining duplicate profiles adds unnecessary complexity. Proposed Solution: Allow clip selection using both Colour and Play Group together (e.g., “First Yellow Clip in Play Group 1” or “Next Empty Orange Clip in Play Group 3”). Optionally support setting a Control Group (or multiple) as active, so MIDI or button actions only affect those, without switching profiles. Benefits: ✅ Eliminates the need for profile switching in complex control scenarios ✅ Avoids disruptive controller behavior during live performance ✅ Enables faster and cleaner MIDI controller programming ✅ Simplifies setup and reduces configuration time ✅ Minimizes maintenance overhead when updating layouts This summary was automatically generated by ChatGPT-4 on 2025-06-30. Original Post: Description: Enable more flexible clip targeting by allowing selection based on both Colour and Play Group, eliminating the need for profile switching on MIDI controllers. Problem: I have a grid of 6 Colours by 4 Control Groups that I am controlling using 6 buttons on a MIDI foot controller (one for each colour), with Profile changes to control the selected Play Group. While my current setup achieves the needed functionality, switching profiles causes some buttons on devices like the APC40 mkII to flash briefly, presumably because they need to resync with the new Profile. This is distracting and makes the setup feel less robust. Proposed Solution: – Allow clip selection based on both Colour and Play Group (e.g., “First Yellow Clip in Play Group 1” or “Next Empty Orange Clip in Play Group 3”) – Alternatively or additionally, support setting a specific Control Group (or multiple) as active, and allow button/MIDI actions to target only the active group(s) — without requiring a change in MIDI Profile Benefits: ✅ Eliminates the need for profile switching in this scenario ✅ Avoids disruptive profile switching during live use ✅ Enables faster programming of MIDI controllers ✅ Speeds up and simplifies setup ✅ Saves time by eliminating the need to maintain duplicate profiles when updating controller layouts * written by chatgpt - excuse the strange and repetitive language (in the video you can see my APC40 flashing as I change between Profiles)