Audiobus: Use your music apps together.
What is Audiobus? — Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.
Download on the App StoreAudiobus is the app that makes the rest of your setup better.
AU presets are saved on host, not the AU?
So i made a preset for ruismaker on modstep, saved it aaand, that saved preset doesent appear elsewhere than on modstep, but modstep for some reason doesent make any sound if i change ruismaker from the init preset..
Is this some bug, or does the AU presets get saved on the host and there is no way for me to get that preset elsewhere?
Comments
They save on the host. As far as I know it's a limitation of AUx.
AU presets can be saved in the host AND the container app of the Audio Unit Extension.
We think they should not be saved in the host, because it leads to a situation where a user saves a preset in a host, thinking they can use it in another host, only to then find out that it doesn't work like that.
There is currently only one way to make sure that you can use all of your presets in any host you want, and that is to save it in the preset management system that is part of the UI of the Audio Unit Extension.
I've talked to a few developers of Audio Unit Extensions and told them that I think they should add preset management to their AUXs and so far they all agree.
In Audiobus 3 we're not offering any way to manage AUX presets other than saving their settings as part of an Audiobus preset - because you wouldn't expect to load that in another app. This is also how Cubasis and Garageband do it as far as I know.
I've talked with the developer of Beatmaker 3 to also make him aware of this. It's an education process that needs to involve users, developers of hosts and developers of Audio Unit Extensions.
Thanks guys. Ill try to get it working on modstep somehow and will sample from there if possible(that was my idea when doing the preset).
Since we're talking about Ruismaker, let me chime in.
What any one of us thinks remains a philosophical discussion, as it is Apple's standard. If anyone needs to facilitate the education process it's them.
When I was making Ruismaker there were few plugins around. IIRC there was only iSEM and NS-1 and most of us developers were just testing the waters. There was also not much in terms of documentation (Apple only kept referring to the WWDC video, which can hardly be called 'documentation') and the SDK was terribly buggy.
Back then I remember some of us discussing this very topic with Apple. An Apple dev forum representative (named 'analog kid' iirc) hinted in several ways that it was not the responsibility of the plugin to handle the presets. All the plugin had to do was handle factory settings. This was strengthened by several other factors:
Apple's own host, Garageband, takes care of managing user presets
iOS's sandboxing and the nature of the extension paradigm make it really hard for plugins to effectively handle presets (you have to fiddle with 'App groups' and kludgy synchronization mechanisms to keep everything in sync between the standalone app and various active instances of the plugin - everything about it feels like it wasn't meant to be used this way).
there is no sign of any user preset handling in the (by now) extensive plugin sample code, nor are there any provisions for it in terms of iOS library support or file handling (again, 'App Groups', really?)
in the several discussions I've had with Apple regarding my plugins, they never mentioned it to me as something that was my responsibility.
Perhaps Apple changed their mind, perhaps they didn't expect a proliferation of AU hosts on iOS, perhaps they simply didn't think it through and left the issue ambiguous. If anything I expected iOS to take care of preset handling on a system level by now. This would allow user presets to be synced to iCloud, essentially tying them to the user profile and making them device independent (even allowing easy synchronization between plugins existing both on iOS and MacOS). It would have made all the sense in the world.
But alas, Apple still haven't explicitly cleared up this issue.
Because this is a complicated issue, I want to make clear that I'm talking about the UI the host app provides to manage presets.
I've just checked Garageband and it does not provide any UI to either load default presets for Audio Unit Extensions nor does it let users save their own presets in the AUX UI inside of Garageband.
As far as I'm concerned, this is the main issue here: hosts providing UI for managing presets that makes users assume that when they're using that UI, the presets they've created are available in other hosts.
The whole issue becomes less severe if Apple either provides a standard for AUX presets being saved in the container app. I doubt they'll do that.
Or if Audio Unit Extensions all provide a UI inside of their view that lets users save a preset that would otherwise be 'locked away' inside of a host.
Yes it does. Pretty much the same way AUM also does it:
@sebastian
This is interesting. I hope this thing will be handled better in the future.
@brambos
Do you know if this modstep only being able to get sound from init patch of ruismaker fm is a bug on modsteps end or on the ruismaker fm? Kinda feels like its the modstep thats bugging after hearing about how this AU preset thing works. I tried restarting my ipad and the problem didnt go away
There are several ways Apple could solve the ambiguity. Some more elegant than others, but we all have high expectations of the way Apple can streamline and design user experiences.
Since they impose so many sandbox limitations on 3rd party developers (plugin and host devs alike, extensions are even more severly blocked from any access to the [file]system) I see it as Apple's job to fix this mess. Basically: make the system more accessible for us, or clean up your own mess if you won't let us in to help. They can't have their cake and eat it too.
Right now, my painful experience implementing a user preset system in Phasemaker has taught me that making even a basic user preset handling system inside a plugin extension is more work than making the entire synth engine. Something seems very wrong about that.
Wow, that is definitely an interesting way to hide that feature. But that's beside the point.
I still think the point stands that users switch around between hosts on iOS much more than they do on the desktop. Since every midi controller can become an AUX host, it's probably on the AUX developers to make sure their apps' value isn't diminished by presets getting locked away in host apps.
Sadly, I don't think Apple will do anything regarding standardisation of features of their previously released sdks. They haven't done that with IAA or CoreMIDI either.
Hard to say as it used to work fine before in Modstep and nothing preset-related has changed on Ruismaker's end since it was launched. I'm not ruling out that Apple changed something in the AU framework in a recent system update so I'll look into it.
Yes, I guess Captain Hindsight would have something to say about this, but it is what it is
Last time I checked extensions aren't even allowed to implement a "file open in..." dialog nor can they accept files from other apps making preset backup/exchange a royal pain.
Seriously, I believe this issue requires more than a gentlemen's agreement between 3rd party devs. A first course of action could be a polite open letter signed by many of us, AU developers, toward Apple to propose a future proof way forward. AU is picking up rapidly, with some big names involved who also have a significant stake in AU on MacOS. Leaving things half-baked would seem rather irresponsible of them.
If we have centralised presets then we have the issue that IAA suffers from which is overwriting a used preset and affecting an existing project...this is the whole point of saving state within a project is it not ? If it is in the project then the host MUST do it.
The problem is that it's hard for Apple to define a standard for this now. The correct way to do it would be to save the all the presets inside of the container app and to make the space where they're saved accessible to every host to write to and read from. And then that behaviour would have to be enforced somehow.
With AUXs and hosts already out in the wild that don't do either of it... how else can you move to a better way of doing it without either breaking apps (Apple doesn't want to do that) or just getting everyone to agree to the new thing and do it right(TM)?
I think a gentlemen's agreement is the most straightforward way to do this.
But I'd be really happy if Apple took the reigns on this and proved me wrong.
State saving inside a project is something that works regardless of user presets (although I see some plugins already requiring users to also save their plugin state as a user preset, notably to handle imported user samples, which quite frankly is another big mess waiting to happen). The host simply asks the plugin for its current state and saves it inside its project file. If implemented correctly this should work with or without user preset management being available.
They could simply give extensions a bit more freedom. E.g. being able to access the container app's file system would already make a huge difference and take away a massive PITA for AUX developers. Other things to consider would be allowing plugin extensions to import/export files using "open in", or even offering an easy-to-implement standardized file browser dialogbox, etc.
All these things would at least lower the threshold for plugin devs to harmonize preset management platformwide and provide a common way of working for end users - without breaking anything that's already out there...
Ahhh ok...so is that plug-in state equivalent to getting a sysex dump from a hardware synth ? as opposed to being 'Use this preset with these tweaks' ?
If so then can I please have a 'Sound browser' that is host and AUx independent.....So when in my project I add a track, then load the 'Sound browser' and it lists all of my presets, nicely arranged by tags of my choice....I can then select the sound I want without having to think about which AUx is providing that sound, and then the 'Sound Browser' loads the relavent AUx and associated preset.
And can that please be cloud based so that I can use the same 'Sound Browser' across all of my devices and to also provide an off device backup
In order for a HOST or AUx to have access to the Sound Browser they can be made to do things with AUx in a certain way.....so basically a Gentlemens agreement but with an incentive to co-operate
And we users get to think more about the sound and not on how to get it
I would love to see @brambos @Sebastian and @lfs draft something and escalate it directly to Craig Federighi
That should always be the goal.
Hi there !
I discussed this issue with Sebastian, as I was going to add preset management in BeatMaker 3. In the end, I did not for the aforementioned reasons.
I think the only reasonable solution right now is to educate AUX developers so they implement proper preset management within their app, as suggested by @brambos and @Sebastian. Audiobus is a developer community as well so I guess writing a small "AUX preset manifesto" would make sense.
That said, we should reach out to Apple, and ask for a clear statement on this discrepancy. Sadly, there's still a chance this issue will never get addressed.
As I see it, some sort of document picker interface would be absolutely perfect, with the ability to save to iCloud or "Open in..." another app.
Let's see where this goes.
Cheers !
Mathieu.
Okay thanks for the reply
I kinda suspect that apple wanted to move preset handling to hosts, so that people would be more willing to develop AU's and to upgrade their apps with AU functionality that work with their garageband.
Ps. Im having very high hopes for bm3, it seems clearly better than anything similar currently(which all seems to be lacking in something). Only thing im slightly concerned is how recording audio loops is done. Im sure im not the only one who uses external instruments, and would prefer to record them directly on bm3, instead of using loopers like blocs or loopy. If the sampler is able to start recording on beat and you can determine how long it records(and able to cut it in half, so that you could play it twice and use the second half to get the fx tail on the loop), then it should be good. Also i saw no mention about link or ableton export on bm3 website, link at least is something that all apps should have today and just missing that one little feature could ruin the whole app. Oh yea and the ability to midimap the repeat speed would be really nice.
Yes, please.
In Modstep I consistently get the problem of no sound from RuisMaker when I re-load a project. For some reason the volume is at zero and has to be turned back up every time on every instance except sometimes the first one.
I don't know if it's a Ruismaker or Modstep issue, and don't really feel like running it down. I kinda set Modstep aside for awhile after issues like this with the latest update. I hunt down problems with software all day at work and get tired of doing it at home sometimes.
Getting better, but yes, still a few hitches. I do the hosting elsewhere thing because I prefer it that way for other reasons as well. But I do like to try just to see how things are working when there's a new release. Getting better all the time IMO.
Thanks. I thought i lost the preset and had already forgotten it
I havent used modstep in a while and just wanted to host ruismaker for it to sample the hits elsewhere. Wasnt a very warm welcome..
@brambos is exactly right, Apple needs to get their act together instead of putting out half baked SDKs and documentation that mean developers have to figure out how to implement basic procedures that should have been part of the SDK to begin with. The S in SDK stands for software but it should also represent standard as a primary goal of an SDK should be to make development easier and to provide a more reliable and consistent user experience across apps from multiple developers who use the SDK.
AU preset saving is another example of a half baked Apple SDK. Why wouldn't users want to be able to use their presets in multiple hosts rather than having to reinvent the wheel inside each AU host app? Since Apple has no standard for their standard, basic functionalities must be developed by independent developers to provide them and naturally this can lead to inconsistencies which undermines one of the primary attractions of AU which is consistent state savings. Having to reconstruct the AU app settings for each AU host app is absurd. If you want to use the AU preset on another device, you can reconstruct the AU preset yet again. This is a particularly nasty surprise after you've invested a lot of time creating presets, expect them to be available in another AU host when you use the AU app but they aren't.
How about when an existing AU host app is about to be replaced with a new app that has improved functionality? Once again, be prepared to reconstruct your AU presets.
With IAA you can have only one instance at a time but user presets are available in multiple AU hosts.
With AU you can have multiple instances but developers must go through all sorts of manipulations to come up with a preset saving system and therefore there is inconsistency among AU apps as to how they handle presets. This has been a known issue since AU apps were first introduced and apparently Apple has yet to address it.
There is no iPad Pro workflow until Apple creates and supports an iOS that addresses these and other basic issues so developers and users can manage their apps and projects in a consistent way including sharing presets between devices, AU hosts, and other users.
How can we clearly and effectively communicate with Apple on this topic?
Yeah, loading up two instances of RuisMaker was my very first test, and it failed on a couple of levels. I still can't open a project with just two simple RuisMaker drum tracks if I have auto load turned on. The first loads, then it hangs trying to load the second. if I turn auto load on, I just have to touch each instance once and then they play ... except that sometimes the volume is zero.
My direct contacts on other subjects to the Modstep developers were answered promptly, but I lost interest before pursuing the RuisMaker issues. I think they know about them since they were the ones to alert me to the RuisMaker volume knob, which I had overlooked since all the other settings were saved.
This does seem very wrong! Though if the iOS audio community had waited for Apple to give us The One True Way, then many advancements would still be forthcoming. Surely Audiobus's travails from bespoke standard through the complete rewrite around IAA were quite the struggle. As well has been your experience pushing the envelope with Phasemaker's preset system (btw big thanks!). Perhaps this will spur Apple to think about how presets can work beyond a single AU host. Perhaps not. In the meantime users of AUs that, like Phasemaker, allow presets to be saved and loaded across AU hosts benefit hugely! Is there any way your pioneering work can be contributed to an open source library that all AU developers can benefit from and the burden of maintenance could be spread across all the interested AU developers? Picturing something like AudioKit, but for dealing with presets. If the AU development community rallies around a common solution then maybe they won't have to struggle individually each time they go to make a new AU with how to deal with the sandbox issues to accomplish something that should be as simple as reading/writing a file.
Once the Audiobus 3 launch is done I'm going to look into this. The problem is not unknown for them.
Awesome. Audiobus to the rescue, again.
Yes, thank you very much for this and all of your work over the years to help us create music with iOS.