Feature Requests

Threshold-Based Follow Action Trigger (e.g. "Stop Recording when Input Drops Below Threshold")
Description: Introduce a new Follow Action type that triggers when the input signal drops below a user-defined threshold, rather than exceeding it. This should act as a general-purpose condition and support triggering any available action — not just starting or stopping recording. Problem: Currently, Loopy Pro allows actions to be triggered when input levels rise above a certain threshold (e.g. for auto-start recording), but not when they fall below a defined threshold. This limits dynamic control, such as automatically stopping a recording or triggering other actions when the input dies away. Proposed Solution: Implement a new threshold-based Follow Action condition: If input signal drops below X dB for Y ms → trigger any specified action. This trigger should be available in the same flexible context as existing Follow Actions (e.g. post-loop, after X bars, etc.). The action itself could be anything available in the Action system: Stop, Play, Mute, Clear, etc. Examples: Stop Recording when input drops below -50 dB for 500ms Switch Scene or Trigger Next Clip when input signal fades out Mute Output automatically after a quiet passage Benefits: Enables more responsive and context-aware automation during live looping Allows fully hands-free looping workflows (e.g. one-shot recordings that auto-stop) Adds symmetry to the existing "threshold above" logic, increasing flexibility This summary was automatically generated by ChatGPT-4 on 2025-05-17.
1
·

under review

Convert Widget Type: Switch Between Fader and Dial Without Recreating the Widget
Description This feature request proposes the ability to convert an existing widget between Fader and Dial types without having to delete and recreate the widget. The goal is to streamline the UI customization workflow and preserve widget configurations during visual adjustments. Problems Redundant Workflow : Currently, if a user wants to switch a Fader widget to a Dial (or vice versa), they must manually delete the original and recreate the new widget from scratch. Loss of Configuration : This process risks losing existing bindings, parameter settings, styles, and actions tied to the original widget. Time-Consuming in Complex Layouts : In large or layered setups, replacing one widget type with another can disrupt the design and require manual re-alignment and reconfiguration. Proposed Solution Widget Type Switch Option : Add a toggle or dropdown in the widget settings to convert between Fader and Dial types. Preserve All Attributes : - Parameter bindings - MIDI/OSC mappings - Actions and behaviors - Size, styling, and position Optional Appearance Reset : Offer a checkbox to reset to default style for the new type, or retain the current styling where compatible. Examples Layout Tweaking : A performer wants to switch a vertical Fader to a compact Dial for better space usage, without redoing parameter assignments. Aesthetic Adjustments : A user redesigns a page layout and prefers Dials for consistency. With this feature, they can quickly convert all Faders without data loss. Iterative UI Design : During testing, a creator toggles between widget types to decide which feels best, without re-binding or repositioning every time. Benefits Faster UI Prototyping : Enables fluid workflow for experimenting with control layouts. Preserved Logic : Maintains all functional connections and behaviors. Better UX : Saves time, reduces error risk, and improves overall design flexibility in Loopy Pro’s UI system. This summary was automatically generated by ChatGPT-4 on 2025-05-16.
1
·

under review

Cycle-Synced Timing and Ramping for Actions: Trigger and Ramp Until Next Cycle of Specific Clip
Description This feature request proposes an extension to Loopy Pro's action system, allowing both timing delays and ramping durations to be dynamically synced to the next cycle of a specific clip. Instead of defining a static number of beats, bars, or milliseconds, users would be able to align the timing or ramp of an action to end precisely when a chosen clip’s loop restarts. Problems Fixed Timing Only : Currently, action delays ("timing") and ramps must be defined using fixed durations. There is no option to align these to the rhythm of an existing clip loop. Phase Misalignment : Without synchronization to a specific clip cycle, actions may feel disconnected from the rhythmic context of a performance. Manual Syncing Required : Users must manually calculate or guess the correct delay or ramp value to align with another loop's timing. Proposed Solution Introduce two new dynamic timing modes for actions: Execute Action at Next Cycle of [Clip] - Replaces or complements the current “timing” delay field. - Waits until the specified clip reaches its next loop boundary, then executes the action. - Example: Trigger a filter toggle exactly when clip “VerseLoop” starts its next cycle. Ramp Until Next Cycle of [Clip] - Replaces or complements the current ramp duration setting. - Starts the ramp immediately, but stretches its entire range (e.g., 0% to 100%) over the remaining time until the chosen clip’s next cycle restart. - Example: Gradually increase reverb mix over the next full measure of a specific pad loop. Both options would allow selection of any running clip as a timing anchor, and the system would calculate the precise remaining time dynamically. Examples Quantized Parameter Modulation : A performer starts a ramp for filter cutoff that ends exactly when the chorus loop restarts, ensuring the effect swells into the next musical phrase. Action Sync Across Clips : A mute action for Clip B is set to execute at the next cycle of Clip A, allowing for cross-clip timing alignment without quantization hacks. Layered Automation : Several ramps (volume, pan, FX send) are timed to different clips' cycles, creating rich, rhythm-aware transitions. Benefits Rhythmically Precise Automation : Ensures that even delayed or gradual actions remain musically in phase with clip loops. Flexible Timing Anchors : Allows users to tie any action’s execution or ramp behavior to another clip’s structure. Advanced Performance Control : Unlocks subtle or dramatic transitions that always land at just the right musical moment. This summary was automatically generated by ChatGPT-4 on 2025-05-16.
1
·

under review

Multilingual Search Support: Enable English and User Interface Language Terms in Loopy Pro Search
Description This feature request proposes enhancing Loopy Pro's search functionality to support multilingual search terms. Specifically, it suggests allowing users to search using both English terms and terms from their selected user interface (UI) language. This dual-language search capability aims to improve usability for non-English speakers who may be familiar with English terminology, thereby facilitating a more intuitive and efficient user experience. Problems Limited Search Flexibility : Currently, Loopy Pro's search function is restricted to the active UI language, which can hinder users who are accustomed to English terms but use the application in another language. User Frustration : Non-English speakers may experience difficulty locating features or settings if they are only familiar with the English terminology, leading to a less efficient workflow. Inconsistent User Experience : The inability to search using English terms in non-English UI settings creates an inconsistency that can be confusing and counterintuitive for users. Proposed Solution Implement Dual-Language Search : Modify the search algorithm to recognize and return results for both English terms and terms in the user's selected UI language. Maintain Language Consistency : Ensure that search results are displayed in the user's chosen UI language, even when searched using English terms, to maintain a consistent language experience. Optional Language Toggle : Provide users with the option to enable or disable multilingual search support based on their preferences. Examples German UI User : A user operating Loopy Pro in German searches for "clip" and successfully finds the relevant feature, even though the German term is "Clip." Spanish UI User : A user with the Spanish UI searches for "mixer" and is directed to the "Mezclador" section, facilitating quicker access to desired functionalities. French UI User : A user using the French interface searches for "loop" and is presented with options related to "boucle," streamlining the navigation process. Benefits Enhanced Usability : Allows users to search using familiar English terms, improving accessibility and reducing the learning curve for non-English speakers. Improved Efficiency : Facilitates quicker access to features and settings, enhancing overall workflow and productivity. Inclusive Design : Supports a diverse user base by accommodating multilingual search preferences, aligning with best practices in user-centered design. This summary was automatically generated by ChatGPT-4 on 2025-05-16.
1
·

under review

Ability to Reassign the Visual Color of Clips Without Changing Their Color Channel
Description This feature request proposes the ability to change the visual (display) color of clips in Loopy Pro without altering their functional Color Channel assignment. The goal is to give users more freedom in organizing and customizing the appearance of clips for aesthetic or navigational purposes, while preserving their underlying behavior and routing. Problems Visual Color Tied to Functional Channel : Currently, a clip’s visual color is directly tied to its Color Channel assignment. Changing the color affects the clip’s behavior, actions, or routing, which is often not desired. Lack of Independent Styling : Users have no way to differentiate clips visually without also changing how they function. Manual Workarounds : In order to change the appearance of clips, users are forced to reassign them to a different Color Channel, which can disrupt logic, actions, or control mappings. Proposed Solution Independent Clip Color Option : Introduce a secondary layer of clip coloring (or override option) that lets users assign a custom visual color to a clip, independent of its Color Channel. Batch Recoloring Tool : Optionally provide a way to select multiple clips (e.g., all clips with a certain current color) and change their appearance color without affecting their function. Visual Override Indicator : Display a subtle icon or outline to indicate when a clip's visual color has been customized independently of its assigned Color Channel. Examples Visual Organization : A user wants all intro clips to appear blue, chorus clips green, and bridge clips red — regardless of their Color Channel. This helps with navigation in live setups. Aesthetic Customization : A performer adjusts clip colors to match stage lighting themes or personal preferences without affecting playback logic. Avoiding Mistakes : A user wants to distinguish clips by look without accidentally altering their behavior or action groups, maintaining performance integrity. Benefits Improved Visual Clarity : Users gain more control over how their sessions are visually structured and understood. Preserved Functionality : Keeps all functional assignments (Color Channels) intact while allowing for flexible styling. Efficient Workflow : Saves time and avoids logic-breaking errors from unintentional Color Channel reassignment. This summary was automatically generated by ChatGPT-4 on 2025-05-15.
1
·

under review

Set Clip Length via Widget Action
Description This feature request proposes the implementation of a dedicated action in Loopy Pro that allows users to set the length of a clip directly via a widget or MIDI control. The goal is to enhance live performance flexibility by enabling dynamic control over clip lengths without navigating through menus or manually adjusting settings. Problems Manual Adjustment Required : Currently, setting a clip's length necessitates manual configuration within the clip's settings, which can be time-consuming and impractical during live performances. Limited Real-Time Control : The absence of a widget-based action to set clip length restricts performers from making spontaneous adjustments on the fly. Inconsistent Workflow : While actions exist to multiply or divide clip lengths, there is no straightforward method to set a clip to a specific length directly through a widget or MIDI command. Proposed Solution Introduce 'Set Clip Length' Action : Develop a new action that allows users to define a specific length for a clip (e.g., 1 bar, 2 bars, 4 bars) directly through a widget or MIDI control. Widget Integration : Enable this action to be assigned to on-screen widgets, such as buttons or dials, facilitating quick and intuitive adjustments during performances. MIDI Learn Compatibility : Allow the action to be mapped to MIDI controllers, providing hands-free control over clip lengths. Quantization Options : Incorporate quantization settings to ensure that length changes occur seamlessly in sync with the project's tempo and timing. Examples Live Looping Performance : A musician uses a MIDI foot controller to set the next clip's length to 4 bars before recording, allowing for precise loop durations without manual intervention. Dynamic Arrangement : During a live set, a performer adjusts clip lengths in real-time using on-screen widgets to create evolving musical structures. Studio Workflow Enhancement : A producer assigns different clip lengths to various buttons on a MIDI controller, streamlining the process of building complex arrangements. Benefits Enhanced Performance Flexibility : Provides performers with the ability to adapt clip lengths on the fly, fostering creativity and spontaneity. Improved Workflow Efficiency : Reduces the need for manual adjustments, allowing for a more streamlined and intuitive user experience. Greater Control Precision : Enables exact specification of clip lengths, ensuring consistency and accuracy in musical arrangements. This summary was automatically generated by ChatGPT-4 on 2025-05-16.
1
·

under review

Load More