m
mccy
Description:
Add "Container Presets" so users can save and recall the full configuration of a container as a reusable preset: the contained AUv3 instruments/effects, their settings, internal routing, and the associated widgets/layout that control them. The goal is to make complex, repeated building blocks portable across projects and pages.
Problem:
Users often build the same functional module repeatedly:
  • A combined instrument + FX chain (e.g., synth -> saturation -> delay -> reverb).
  • A combined input processing chain (e.g., mic -> EQ -> comp -> gate -> reverb).
  • A performance control panel: multiple widgets mapped to plugin parameters and Loopy actions.
Today, recreating these modules is time-consuming:
  • Adding all plugins again, reloading the same presets, restoring routing, and rebuilding widget layouts/bindings.
  • Duplicating within a project helps, but portability across projects/pages is limited.
  • Complex setups are fragile and discourage experimentation because rebuilding them is costly.
Proposed Solution:
1) Save/Load presets at the container level
  • Add actions in the container menu:
- "Save Container Preset"
- "Load Container Preset"
  • Preset should capture:
- All contained AUv3 instances (instrument/effects) and their state/presets.
- Internal routing and channel assignments within the container.
- Widget layout inside the container, including widget settings and bindings to AU parameters/actions.
- Any container-specific settings (gain, monitoring, etc., where applicable).
2) Preset as reusable building block
  • Allow applying a preset to:
- A new empty container ("create from preset").
- An existing container (with options: replace contents, merge, or append).
3) Clear portability rules
  • Handle missing plugins gracefully:
- Show which plugins are unavailable and provide placeholders or bypass options.
  • Preserve bindings robustly:
- Use stable ID-based mapping so widget bindings remain intact even when the container is inserted into a new project.
4) Optional preset library management
  • Provide a preset browser/list with naming, tags, and search.
  • Allow exporting/importing container presets for sharing or backup.
Benefits:
  • Dramatically faster setup of complex rigs and repeated modules.
  • Encourages modular design: users build high-quality "blocks" once and reuse them everywhere.
  • More reliable live workflows: known-good modules can be recalled without manual reconstruction.
  • Simplifies collaboration and sharing of setups (if export/import is provided).
Examples:
  • "Vocal processing module":
- Container preset includes EQ, compressor, de-esser, reverb, plus a widget panel for threshold, wet/dry, and bypass toggles.
  • "Signature synth chain":
- Instrument + chorus + delay + reverb with macros on widgets; saved once, reused across multiple songs/projects.
  • "Busking template":
- Multiple containers (e.g., main instrument chain, ambient FX chain, emergency mute/limiter chain) each saved as presets and quickly assembled for a new show.
This summary was automatically generated by GPT-5.2 Thinking on 2025-12-27
.
Original Post:
In my series: From time to time reminder for track presets I had a new idea… Still I have massive problems with ram overload, because I use ‚too many‘ instruments. This would solve this and many other problems:
What about adding an FX/Instruments–Container, which would allow presets. This doesn’t sound innovative? Right, but: There should be another container/frame for widges, where you can specify an area on a page and set widges which are included in the presets, so widges would change with presets in a predefined area without making conflicts with others.
This way you would avoid all the hypercomplicated stuff with interdependencies with normal FX system and widges which made the idea of track–presets so difficult.
This way these presets would be kind of sandboxed and the possibilities of unwanted interactions would be much reduced.