Feature Requests

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.

The text inside widgets (such as rotary dials) appears blurry due to the inner color blending with the outer border. Please consider using a solid background color and providing an option to customize the text color for better visibility.

I set up radio buttons to use one MIDI keyboard for multiple instruments. Each instrument ultimately needed its own button, but I couldn’t assign a long press to open the effect or instrument interface—which would have been very useful. Please consider adding long press functionality to radio buttons for switching.

I suggest a listening mode (Napalm) where the application no longer responds but simply records the modulated parameters to then trigger them all at once with the Fire button. It's like being able to hear something coming like a bridge, being able to prepare it, then hear it without transition, or have the transition precisely quantified if desired. For practicality, it would be necessary to be able to return to the original parameters after launching, and this would allow us to be impulsive and sometimes push things to the extreme without fear of getting too lost. If we like it, we could also save all parameters as a snapshot or simply return to what we were doing. We could use a color to identify the parameters that have been modified during listening mode and visualize the target value. We could of course exit the mode to adjust certain details and then return to our preparations without losing progress until we press fire.

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.

Problem: Text in Loopy Pro widgets is static – there’s no way to display live values like AUv3 or MIDI, or to show dynamic status feedback. Users can’t show the value of a fader or knob, nor adapt text visibility, size or content dynamically. Proposed Solution: Text binding to controls: Let text widgets display live MIDI values from bound faders or knobs Placeholder system with support for: - $project.name$ , $bar.current$ , $channel_name_1$ , $AUv3_post_3$ - Current/total clip layers, named layers - Clip colors, groups, AUv3 plugin parameters User-defined labels for value ranges , e.g. 30–155 Hz = “Rumble”, 1000–3000 Hz = “Medium” Conditional formatting & visibility - Show exact value only while knob/fader is touched - After a delay, return to label display (e.g. "Range name") Text resizing logic - Auto-scale font size with widget/canvas changes - Manual ± font size per widget Formula-based expressions , like SWITCH(...) Text changes via actions , e.g. “Set label to: VERSE” Benefit: Real-time, intelligent feedback in the UI itself No need for extra screens or MIDI displays Clear overview of dynamic values, actions and playback states Great for live performance, section navigation, parameter feedback and more Customizable and responsive interface that adapts to user interaction Extension: Define Dynamic Behavior for Each Placeholder Ideally, each placeholder should have its own display logic – controlling when and how it appears. Examples: Always visible (default) Only visible during interaction , e.g. while a fader or knob is being moved Visible for a short time after interaction , e.g. 1 second after release Conditionally visible , e.g. only when a clip is playing or a value is in a certain range Toggle visibility via actions or logic This would allow for highly adaptive and context-aware UIs – showing the right info at the right moment without visual overload. It would give Loopy Pro a unique edge as a flexible, user-definable performance environment. This summary was automatically generated by ChatGPT-4 on April 30, 2025.

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!

When “Play in background” is enabled and LP is left unattended for a day, the battery of my iPad Pro M4 gets totally depleted and it’s damaging the (expensive) battery. This happened now 3 times with my Satechi USB-C hub attached (I tested this). When the “Play in background” option is disabled or LP is shut down, there is obviously no excessive battery drain (with or without the hub). This is unacceptable in my view. We should be leaving our hubs attached and apps open all the time without the risk of depleting (and possibly damaging) our batteries. Apple even suggests not to quit frequently used apps because of waste of battery and system resources. My suggestion is to build in a “idle” detector which turns off this ”Play in background” option or force quit LP when left unattended for one or several hours and/or any USB accessory is connected, in this case a simple USB-A to USB-C hub to allow my Focusrite Clarett+ as my audio interface for Loopy Pro.

Description This feature request proposes the implementation of a scrolling container widget within Loopy Pro. The goal is to enhance interface customization by allowing users to embed various elements—such as clips, buttons, and other widgets—into a scrollable area, facilitating more flexible and organized layouts. Problems Limited Space for Widgets : Currently, users are constrained by the fixed canvas size, making it challenging to accommodate numerous widgets without cluttering the interface. Inflexible Layouts : The absence of scrollable containers restricts the ability to create dynamic and adaptable layouts tailored to specific performance or production needs. Difficulty Managing Large Preset Lists : Without a scrolling mechanism, navigating through extensive lists of presets or controls becomes cumbersome and inefficient. Proposed Solution Scrolling Container Widget : Introduce a new widget that acts as a container with scrollable capabilities, allowing users to place multiple elements inside and navigate through them vertically or horizontally. Anchor Points and Navigation Actions : Enable the use of actions or controls (e.g., dial widgets) to jump to specific positions within the scrolling container, facilitating quick access to desired sections. Customizable Scroll Behavior : Provide options to configure the scrolling behavior, such as scroll direction, speed, and visibility of scrollbars, to suit various use cases. Integration with Existing Widgets : Ensure compatibility with existing widgets, allowing seamless incorporation of clips, buttons, sliders, and other elements into the scrolling container. Examples Performance Setup : A musician sets up a fixed row of essential clips at the top of the interface while using a scrolling container below to access additional loops and effects during a live performance. Preset Management : A producer organizes a large collection of presets within a scrolling container, enabling efficient browsing and selection without overwhelming the main interface. Modular Layouts : A user creates multiple scrolling containers, each housing different groups of controls (e.g., drums, synths, vocals), allowing for a modular and organized workspace that can be navigated intuitively. Benefits Enhanced Interface Customization : Scrolling containers provide users with the flexibility to design interfaces that accommodate a larger number of controls without sacrificing clarity or usability. Improved Workflow Efficiency : By organizing elements into scrollable sections, users can access and manage their tools more effectively, streamlining the creative process. Scalability for Complex Projects : As projects grow in complexity, scrolling containers offer a scalable solution to maintain an organized and navigable interface. This summary was automatically generated by ChatGPT-4 on 2025-05-09. Original Post: new object that can be place in a page that can contain clip, button etc, but with a scrolling possibility. It can give us the possibility to keep certain thing permanent and others customisable. Exemple: 8 clip on the top as permanent Looper but a grid like ableton in a container where we can scroll the set. Exemple2: Having 4 containers with different object and scroll it to custom the layout depends on our needs.

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.