Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Presets: plugin and host app interoperability
Hi Everyone,
After seeing that a lot of recent, popular releases (and even those from major brands) don't populate the factory preset lists in DAWs/hosts, the question arises whether this is widely accepted now, or this is actually a pain point for some and maybe they already contacted developers requesting this feature.
The near-zero adoption rate of iOS13's user presets feature (e.g. "Save in plugin" feature in AUM) was already a curious phenomenon - though some legitimate arguments can be made against it.
However, the increasing occurrence of unpopulated factory preset menus seems to be a next-level regression (or a shift) in the overall state of things, especially when it happens with plugins that do in fact have the concept of factory banks plus an otherwise uncomplicated preset system.
A lot of things point to this becoming the new norm, but exploratory feedback has been inconclusive so far. Any opinions and feedback would be genuinely appreciated.
For our upcoming plugin, we're exploring the possibility to have a multi-bank preset system. To support the best host app preset interoperability, we're looking at ways in which the bank concept could be bridged to the flat lists that's displayed in host app menus. But given the amount of effort that could potentially go into that, a reality check is in order to make sure that this actually provides value other than being a good AUv3 citizen. While the latter was never, ever questioned up to this point, actual expectations and practicality concerns (e.g. the possibility of very long lists to scroll - and generally, the limitations of the API) may call for a more pragmatic approach...
Thank you!
P.S. needed to re-attach the poll after replacing the images with smaller ones. There were two votes so far, one for option #1 and for #3.
- Do you use the host app's UI to select presets?13 votes
- Frequently, and it's a hindrance if these lists/menus are empty for a plugin46.15%
- Yes, but only if there are not too many presets to scroll through7.69%
- Yes, but only for user presets I saved in the host app23.08%
- Sometimes, and it's not a problem if a plugin doesn't populate these lists15.38%
- No, I always select presets from within the plugin's UI7.69%
Comments
I usually only use it for host specific patches. I usually just use the apps preset selector though.
I haven’t voted as there isn’t an option that matches my usage, which is: yes, if the plug-in doesn’t have any other way of saving/loading presets. Main plug-in I have where I use this is Gauss, but there are others.
It’s a pity that a) it’s not more sophisticated than a flat list, and b) it’s not used more (probably because of a). Learning a zillion different preset management systems is a royal PITA, especially where they’re clunky or confusing (Fundamental and SpaceFields spring immediately to mind). A bit of standardisation wouldn’t hurt!
Regarding the flat lists (of both user and factory presets in AudioUnit v2&3), I would be open to participating in some standard way to "encode" bank names in the preset names, and thus be able to represent them like that in AUM. One often see the form "Category - PresetName", or sometimes "Category: PresetName", etc.
That would be great! Shall we try to tag developers here and have a vote, or could there be a better way?
In any case it sounds like a risk-free experimental addition, though some mechanism needs to be added to prevent accidental pickup of the separator char sequence if it wasn't intended - probably should disengage unless the separator is found uniformly in all preset names.
Perhaps the tricky part for a developer is to decide how to deal with the other hosts in such a scheme.
The primary concern would be the length of the full preset name, in hosts that squeeze the preset list into limited screen space.
(For us, what is being under consideration is to use short prefixes like BNK01:, BNK02:, or even shorter or user-definable. It may take some getting used to, but still much better than endless flat lists and it's also something found on some beloved HW synths
)
I'll be happy to adopt any conventions going forward. Not sure I want to retro-actively apply it to all my existing apps.
FWIW, I'm already supporting the "Save in plugin" in all my new apps since iOS13, but I get questions and confusion about the name of the feature every so often. In the mental model of many users it does not convey that it makes presets available across all hosts on the system rather than actually saving the preset inside the plugin (which is usually what the built-in preset system of the plugin already covers).
I think ":" is a good delimiter character, since it's unlikely to be used as part of the name, and is already the standard delimiter in other AUv3 areas (manufacturerName: pluginName).
Any presets without the delimiter could be listed under an "Uncategorized" bank.
If it becomes a problem, I could have a user toggle in the preset browser to switch back to a simple flat list.
Would you prefer a drill-down navigation or a split table with banks on the left pane and presets within that bank in the right pane?
I could change the name of that button to make it more clear. Perhaps "Save globally" instead?
Yeah that should work, or "Save for all hosts" or something
Cheers, agreed on the ":" delimiter. Not sure which navigation would be best though - maybe the split table is more touch interface friendly and it's more straightforward to present a currently active selection in? At the cost of possibly occupying more horizontal space though.
Was wondering why this feature ended up confusing even some professionals. And probably to a great extent, the explanation may be that since other host apps didn't support shared presets, AUM remained the only app where these showed up, creating a perceived redundancy of the feature when compared to regular app-saved presets (on the surface).
Really hoping folks are making host app developers aware of this missing feature... the current situation needs to improve, it has to shift away from being a needlessly mind-melting problem for plugin developers who care.
I think it makes sense if a plugin that enables system wide User Presets also presents them in its own preset browser (if it has one). It's simply user presets that are saved in a place where the plugin can access them at all times, regardless of host, that's why I named the button "Save in Plugin" as opposed to saving in the host.
It's a fairly good naming choice. "Save for all hosts" or perhaps "Save shared preset" may only really be an improvement if a number of other hosts would actually include them in their preset lists. But it would seem a 100% success rate in conveying the right message might not even be possible due to the way preset handling evolved on iOS, considering @brambos 's description how there is a gap in the mental model regarding the equivalence of a preset contained in the plugin and its availability across all hosts (again we might be back at square one, which is the lack of other hosts listing these presets).
Also possibly, maybe some didn't even realize the preset appearing inside the plugin as well (in some cases it's not far fetched to think that there is no consistent overlap between usage patterns of those relying on the app's preset list versus those who prefer the plugin's own UI).
The naming choice "Save in Plugin" could also convey the information that the preset will be erased if the plugin is re-installed. But it may be a minor point, given that this information may be skipped over just as well, and hopefully everyone takes care of backing up important data.