O
Omri
Description:
Implement a robust MIDI binding system that links MIDI controls to persistent internal IDs for clips and widgets, instead of to their current index, position, or label. The goal is to keep MIDI mappings stable across layout edits, reordering, and design changes, so controllers remain reliable as projects evolve.
Problem:
Currently, MIDI bindings appear to be tied to positional or name-based references (for example, "Clip 15" or "Slider 7"). When the user adds, deletes, or reorders clips or widgets, these indices shift, causing existing bindings to:
  • Point to the wrong clip or widget, or
  • Break entirely and require manual rebuilding.
This leads to:
  • MIDI mappings becoming unreliable after even minor layout tweaks.
  • Repeatedly having to re-check and rebuild bindings when refining a page or moving UI elements.
  • A strong disincentive to iterate on layouts once MIDI is set up.
  • High risk of failure in live performance, where a moved clip or widget can silently invalidate mappings.
Users report that even moving a clip slightly on the canvas can change its internal numbering and break mappings, forcing a tedious verification pass over "each and every binding" after small visual adjustments. It also limits practical reuse of MIDI setups across pages and projects.
Proposed Solution:
Introduce ID-based object binding for all MIDI mappings:
  • Assign each clip and widget a persistent internal ID (unique object identifier).
  • When a MIDI binding is created, store the binding against that internal ID, not its index, row, column, or label.
  • Ensure that:
- Reordering clips or widgets on a page does not affect their MIDI bindings.
- Moving a clip or widget between rows or positions on the canvas leaves its bindings intact.
- Duplicating a clip or widget (including across pages or projects) offers the option to either:
- Copy the bindings along with the object, or
- Create a clean copy without bindings (user-selectable behavior).
- Only explicit deletion of a clip or widget invalidates its associated bindings.
Implementation notes:
  • Provide a safe migration path for existing projects (e.g. converting current index-based bindings to ID-based on load).
  • In the control settings / profiles UI, display the bound target by name and location for user clarity, but internally use the stable ID.
  • Optionally expose a "relink target" function for reassigning a binding to another object without recreating it from scratch.
Benefits:
  • MIDI mappings become resilient to layout changes, renaming, and reordering.
  • Users can freely refine pages, move clips a "few centimeters" for better ergonomics, or redesign a performance layout without destroying their control setup.
  • Greatly improved reliability in live contexts, where any unexpected re-mapping is unacceptable.
  • Enables copying individual clips or widgets (with their bindings) across pages and projects as reusable building blocks.
  • Encourages experimentation and modular UI design, fully aligned with Loopy Pro’s flexible canvas concept.
Examples:
  • Layout refinement:
- A row of clips is moved down to make room for new controls.
- With ID-based binding, the same footswitches still trigger the same clips as before, regardless of their new positions.
  • Reusing a performance widget:
- A "Record/Play/Stop" button widget with carefully tuned MIDI bindings is copied to a new page or project.
- The copy retains its mappings to the intended target clip or role, instead of reverting to default or pointing at the wrong object.
  • Multi-song setups:
- A user designs a template page with a grid of clips and a bank of widgets mapped to a MIDI controller.
- They duplicate the page for Song 2 and Song 3, adjust clip contents and layout, and all bindings continue to work without manual re-learning.
This summary was automatically generated by GPT-5.1 Thinking on 2025-12-27
.