I’ve just discovered - a bit late in the day but just in the nick of time really - that iOS 11 will support building and hosting Auv3 plugins that can send MIDI and be “MIDI only” plugins.
If one doesn’t need to support AudioBus Remote what are still good reasons feature wise for what AB3 offers middle-ware-wise for a new developer still making their MIDI apps AB3 compatible - as opposed to just making an AUv3 app?
My biggest interest with AB3 was the MIDI page. But with iOS 11 support for MIDI only plugins and MIDI out - doesnt this mean that once AU hosts support this new API there will be less need for AB3 - and maybe AUM will support it too ?
Will AB3 still just make it easier to “wire up” MIDI between app inputs and outputs when compared to what could be done with the iOS 11 AUv3 middleware API spec ?
I’m guessing that this iOS 11 feature maybe swayed the JUCE team in taking AudioBus off their list of furture to-dos? Kind of makes a bit more sense now.
I agree with what one of the commenters on your audiobus post said: we’re in a bit of a transitional phase right now, so things kind of need to shake out.
Based on my experience about how these things shake out, once people figure out a minimum viable scenario, that tends to end up being the default “standard.” An excellent example would be VST2.4. As soon as VST2.4 became available, DirectX plugins died the flaming, screaming death they so richly deserved, and now VST2.4 is so firmly wedged in the normal usage vector that even Steinberg can’t escape it.
On iOS, we don’t really have that minimum viable use case yet, although iOS 11 will certainly move things along. Apple slept on coming up with a working format for so long that some others (e.g. AB) have grown roots.
My general thinking right now is that if you release at the end of September on an AUv3 Midi output vector, you’ll have a tough row to hoe for about three months, and after that you’ll get a lot of “my iPad Mini running iOS 5 can’t blah blah” but in general, it’ll be fine. We set our cutoff at 9.3, and don’t offer AudioBus connectivity at all, and since we have brand recognition, this forces the host devs to kind of bend to our needs. Ultimately, you want to build to the standards that Apple offers, so Inter-App Audio and AUv3 and some patience is my advice. As I said, it’s a bit of an uncomfortable time for MIDI-only (we have one in the pipeline as well, and are going to have to muscle through your exact same problem), but a little patience will let it sort itself out.
So tl;dr: my advice is to build to AUv3 midi plugs, and the normal internal MIDI I/O (you have to beat on the JUCE standalone mode a bit to publish the I/O; the normal template standalone app is just a suggested starting point, and isn’t really ship-worthy). And let the routing onus be on the AB and AUM folks.
4 Likes
thanks for that feedback. What stands out though is that you didnt actually mention any standout features in AB3 that would be missed if only going AUv3 - so i’ll take that as an encouragement to 0 as you say- go all out on the Apple API standards .
Unfortunately there’s still Ableton-Link to contend with… but who knows - maybe in years Apple will see the light and do something similar…
I’m currently fighting with Link right now. Ugh.
Regarding the AB-specific stuff, we don’t bother. In theory, AUv3 obviates any necessity of AB-specific foolishness. We’ve gotten a few letters from people that use AB2 (which doesn’t host AUv3) that they’re sad or whatever, but we’re pretty aggressive with our cutoffs, and it has never really affected us. On the whole, people with very powerful systems and people with really shitty systems are the conservative ones as far as upgrades. The vast majority are somewhere in the middle, and generally keep current. If our gross receipts from iOS are any indicator, they’re certainly a large enough group to comprise a market unto themselves, and I’m happy to make things for them.
3 Likes
