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.
AUv3 user presets: what are the best workflow examples, which plugins handle things best?
With iOS 13, the promise of much better AUv3 user preset handling arose. For developers, Apple even laid out the use case of transparently using iCloud to share and sync presets even on different devices (and perhaps on different platforms).
Now, looking around, and checking practically all my AUv3 iOS plugins, I couldn't find a single plugin that takes advantage of the new user preset API. Which means that host-provided preset selection UI's remain useless for user presets that are stored in the AUv3, and not the app. And sharing presets between devices boils down to manual import/export workflows, not a single developer went the automagical iCloud route. (As a side note, I also noticed that plugins even from established vendors manage to mess up even the factory preset list. And host apps have some peculiarities as well, like not retaining the preset selection when reloading a project.)
I find this situation really curious, so far it appears that this API remains practically unused, although some host apps definitely support it.
I'd appreciate if you could describe what counts as best practice at this point in time, in terms of workflows and examples of actual plugins that best enable them.
Has anyone encountered a plugin that had its user presets show up correctly in the host app's preset list UI?
Comments
I don't understand what you are referring to with the iCloud section. Can you point at something from Apple that explains what you mean with this? As fas as I know, the only connection with iCloud and AUv3 presets is what is standardly available to all apps and is actually a bit more complicated to use from extensions.
My AU's support the newer plugin to host stuff that Apple added a couple of years ago. The issue is that almost no hosts support it so almost new AU's bother so no hosts bother ... (or run that loop in reverse). The real issue is that Apple didn't start with this in place and then didn't require it or even make it part of the default interactions. So, it's basically doomed as a standard. The easiest and probably best path would be to enable what happens on macOS and simple define a location (and an entitlement on iOS) for all presets to be.
I've actually got about a third of an application written that is a preset librarian for iOS. I stopped bothering when I realized that it would be pointless to finish the application because the number of AU's that support it would be very small and unlikely to grow.
I personally think the whole factory preset thing is a bad idea even going back to v2 AU's on the Mac. There should only be one kind of preset and where it comes from doesn't matter. Because of the difficulty with the way Apple implemented preset sharing with iOS I was pretty much forced to include factory presets for my iOS AU's. Back when I was doing Mac AU's I simply bundled a collection of preset files with the AU -- no need for the factory thing at all.
The issue with hosts knowing the preset to load with a project starts with the point that a project is very likely not using a preset at all. Tracking when something is a preset or not when the state can be changed from the host, AU, and MIDI makes it difficult for the host to know. The mechanism for getting the AU state for saving a project is decoupled from the preset management in the AUv3 spec. To save the project state, the DAW/host calls the fullStateForDocument method on the AU. Nothing about the preset is communicated in a standard way.
I think I saw a suggestion from Apple that this method could directly save to iCloud. Maybe it's in the sample app, or could even be in a comment in the AudioUnit header files.
In the AUAudioUnit header, for the saveUserPreset method, there is a comment that an Audio Unit could override it to "operate on a different location (e.g. their iCloud container)".
Yes, I suspect that there is some reluctance stemming from difficulty in reconciling the pre-iOS13 implementations with the new API feature of user presets. Still, I find it shocking that I wasn't able to find a single plugin that makes use of it, and now I'm genuinely curious to see one in action.
>
Yes, the current situation is not good. Seems like some plugins completely forego the whole AU preset thing, and manage the entire thing internally with AU parameters, which means you will get an empty list if you open a preset list from the host app.
Cubasis uses a workaround, by simply remembering the last set preset, which is crude but at least you have some idea what was loaded. On the other hand, in AUM I never, ever saw the "check mark" being retained in any preset list after loading a project. And I used AUM a LOT.
That is until one day, a BLEASS plugin somehow pulled it off. Although at this point I wouldn't be surprised if it was a bug or otherwise unintentional thing, given that I've never seen that happen before with any plugin.
Looking at the spec, maybe what could make some sense if the AUv3 plugin would set the currentPreset property when reading a full state (of course leaving it up to the plugin to make the determination based on whatever black magic, extra AU params, or value comparisons), and the host would listen.
But anyway... I am still genuinely curious if some people found good use host-provided preset UI's when user presets are involved. Or whether any plugin exists at all that makes use of the new user presets API from iOS13 and up.
I would be almost inclined to ask whether these host-provided preset selection lists are used at all, but both I and some other iOS musicians regularly use them, so I cannot really reconcile that with how broken things look when user presets are involved, so maybe something is missing from the picture.
Correction: I investigated the above mentioned BLEASS case, and indeed it is a bad anomaly. Even though it remains the only instance where I can see a check mark appearing in the preset list after a project load in AUM, that preset indication has absolutely zero to do with whatever had actually been selected, regardless whether the selection happened via the AUM preset list, or using the plugin's own UI.
Doing it like Cubasis won't work, because it wouldn't update the preset selection UI inside the plugin itself, unless one actually sets the preset before loading state. But that would load state twice, once via set preset and then via set full state, which is certainly non optimal.
There's no method to set a preset (name) on a plugin without the plugin actually loading the preset.
What plugins could do is to remember their last selected preset, by saving the preset name and index in their state, and pretend that this is the current preset after loading state. Note it would mean the presented preset might not at all correspond to the actual state.
Yes the AU can actually do anything it wants here that a regular iOS application can do. But, being useful for saving the preset state takes out most anything other than simply saving the state. Saving them to a network location or places that the user might delete them really complicates things.
There are a couple of AUv3 around on iOS that I've found that support the user preset host interaction. All of mine do for example. I think if you were to use PhaseDelayArray in AUM then you would see how Apple intends the interaction to work.
Right. A lot of opportunities for complexity...
Thanks, I will definitely check it out.
Looks pretty neat in AUM. This is the first time I've seen this feature implemented in an AUv3 plugin, even though I looked at quite a lot.
Shockingly, Cubasis3 seems to have zero support for these presets. Wow. This gives at least a partial answer to the original question...
(Speaking of shocking things, as a technical side note, another absolutely mind-blowing thing about Cubasis, is that it always uses fullState (and not fullStateForDocument) even for saving the project. So if a plugin deems some per-instance settings not suitable for preset persistence, those won't be saved in the project either. What's more mind-boggling, is that GarageBand for iOS did the same thing last time I checked.)
This would be awesome for device hoppers like me. Hopefully as more and more of our favourite apps start to work on the new Macs, more people will begin to see the value of keeping their musical environment synced on multiple devices, and devs will start to include it more.
For almost every AU there's not going to be a difference between fullState and fullStateForDocument. The default implementation of fullStateForDocument is a passthrough to fullState. The default for fullState is to grab the parameters from the parameter tree. It wouldn't surprise me if some DAW's don't use fullState and instead store what they currently have as the parameter values in their own internal format.
Personally, I wouldn't have a difference in what I sent in fullState and fullStateForDocument. In a couple of my older v2 macOS AU's that had automation curves outside of the parameters I serialized this data into what was the equivalent of the fullState call.
Part of the issue with plugins on macOS/iOS is that devs use cross platform tools that mainly target VST. So, even if these tools do include the newer Apple specs, it takes time for it to eventually show up. Audio related companies and users are pretty slow to update too. So, we are kinda at the point now where those features introduced in iOS 13 might start showing up in more plugins -- maybe.
And it's ~6 months to go until iOS/iPadOS16 gets introduced...
...hopefully by then at least the majority has realized that they can skip iOS14.x and go straight to 15.x...
This way developers can focus on supporting the two most recent iOS revisions instead of having to back-track to <13...
'Things' that seem to take forever to get adopted and implemented for file-sharing are 'Share Sheet' and 'Document Picker' as well as exposing the 'Documents' folder to Files.app...
I hope not! Plugins might very well have settings that they don't want to expose as a parameter but still want to save with its state. For example reference to audio files, or even the audio data itself if it's not too big, or any setting that doesn't make sense to change on the fly while the plugin is running.
PS. AUM uses fullStateForDocument when saving a session, and fullState when saving a preset (if saving locally in AUM), but none of my own plugin makes a difference either. Not sure what an example would be for state that should be included in a project/session/document but not in a preset?
Maybe a trivial example, but the custom bypass switch almost every plugin implements on its own, named "active", "power", etc. isn't very useful to be saved as part of a preset, but makes sense to save it in the session. There are also some plugins that have a send / insert mode switch instead of dry/wet fader - but this is where the technical decision might become less clear, and we end up with features like the "locking" of the mix or dry/wet control so changing the preset won't overwrite it, etc. (To me this feature kind of suggests that maybe such a setting shouldn't be part of the preset, but it's really not that clear-cut, and I guess that can be up to personal preference.)
I'm not suggesting it as a good idea, just that I wouldn't be surprised.
If I remember right, Apple gave an example of tuning files for a synth as something that might be appropriate as something not to save in fullState but would be good in fullStateForDocument. That one makes some sense to me as the preset information is independent of the tuning but the project state needs that info.
I'm shocked yet again.
It seems AUM is the only generic host that supports shared/plugin user presets through its own UI.
I've looked at a lot of apps, from GarageBand, ZenBeats, Cubasis, BM3, AudioBus, NanoStudio, ... and haven't seen the feature incorporated in these.
Is this really the state of things? What is the underlying reason for this?
Are there any DAWs or other high-utility hosts that support this feature (that has been out there since iOS13)?
Hosts don't support it because AU's don't and vice versa. It's not required on either end, so it isn't going to happen for the most part. I'm projecting my own experience here a bit, but it's probably easier to implement on the AU side of things (if the AU already handles saving presets internally). And most of the AU's don't add the feature.
Another point is that this whole path is pretty much an overly complicated solution to Apple not defining a common location for presets like is done on the Mac. Define the location, let users opt in on a per app basis, give the users file system access to the location, and then all the issues with storing, accessing, and backing up presets goes away in one easy move.
@dspguy , I'm not sure why you feel this is so important. Plugin presets saved in a host are only accessible inside that host. Presets saved in the plugin are accessible when loaded in any host. So these plugin host presets seem more like a curiosity to me.
And I believe @NeonSilicon gave the underlying reason in his first post here: apps don't support it because hosts don't; hosts don't support it because apps don't.
If it were implemented in all AU's, then every host would have access to all the AU presets and the user would be able to use the host GUI in a consistent manner over all the AU's they used. AU's wouldn't need to write a GUI interface to the preset system (I think it would be better if most didn't --- mine included).
It would also let me write my plugin librarian app I want to write and sharing and backing up presets could be much easier.
I think it would be a good thing overall if support was added to everything. It's not a huge problem if it never materializes, but I think it could be useful if it did.
I develop plugins and decided to fully commit to supporting this new API, to be a "good citizen" about it. In the first post I also asked the question about workflows & practices to see what role this feature does / could play out there in the wild.
To me, questions about the current state of adoption / conformance is very important because the API documentation leaves some questions unanswered regarding these user presets. These ambiguities could only be addressed if more developers would adopt the API and converge to a common approach, which is probably going to be a rough and lengthy ride (given that some hosts already have trouble implementing even the clearly defined parts of the AUv3 standard), and I wanted to see where we are as a community along that path. Right now we seem to be at an impasse.
That is, unless Apple steps in and refines the API (I certainly wouldn't downplay the possibility), which is also something early adopters need to consider before they jump in. That's probably another reason why everyone seems to be sitting this one out...
Thanks for the replies and insights that you have given so far.
From my PoV, for an AUv3 that works today and has some future proofing you need to implement the host/AU preset interface. You also need to implement a preset solution directly in your AU because some hosts don't do anything here.
Test with AUM because it does the best job of implementing the AU spec. Test with GarageBand because it is by far the most used DAW/host even if it doesn't seem so from the impression you get from this forum.
Thanks for sharing your viewpoint. Good to know this about GB, I was starting to get the same impression, but was just a hunch.