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.
Comments
No, that's not a valid assumption exactly. The vice-versa part isn't automatic. It does open the doors though.
Yes. Even without specifically the M1 chip.
Not really. They said that they would make it so that iOS apps can run on MacOS - without modification. And they have. Developers don't have to modify their apps for them to run, though perhaps they will need to modify them to work well with non touch screens or if unforeseen bugs are introduced. In fact, they will need to do something to opt-out from having them available on the new Macs.
That doesn't mean it's a two-way street at this point though.
But it opens the door, and Apple seems to be good about that. They added mouse support when there was resistance. Then the AMK with the trackpad and full iPad/laptop conversion. I’m typing this on my 11” iPad with the AMK and it’s a convertible laptop.
So......
You have two arguments against it as I see it. One is just resistance to change. THe other is the risk of cannibalization. But the cannibaliztion argument has often proven to be unfounded, and the first objection is of no concern.
But I have no idea. I just would like these things, as many others would. And that’s the thing.
Not sure how devs are gonna feel about their 5.99 being desktop compatible.
I just hope $29.99 iOS DAWs arent gonna become $199.99 iOS and Desktop DAWs
edit: or worse yet...subscription based to cover all bases
Huh? I have no arguments against it. I'm just responding to inaccurate assumptions and trying to clarify what it does and doesn't mean.
Yes, I think it puts developers in a difficult spot the way Apple is going about it in the short term. But as a consumer, I think it's great. Not something that I care about because it has no benefit to me, but definitely a good thing.
Or, did you mean "you" in a generic sense?
No not you. I was being general.
I suppose FabFilter will opt-out
Hadn't thought of that.
That brings up an interesting point: further de-motivation for desktop developers to bring anything out on iOS.
If I recall correctly, the only resistance to putting a mouse on i(pad)OS was internal to Apple. Basically, they finally gave in to a use case that was driven by users.
Apple has a different vision for iPads than they do for computers. To meet their goals, iPads need to be much more power efficient than even the new MacBook Air. Up to a point, Apple is more likely to use their new tech differently in the iPad than they are in a computer. Putting lots of RAM in a tablet is unlikely until they can get much more efficient RAM. It takes a bunch of power to run RAM. The hardware design of the iPad is to try and keep it light and mobile to pretty crazy extremes. They really can't do that and build hardware that can support things like what we expect from Logic today. This will get more and more possible over time, but I think it's still a bit early. Even GarageBand on iOS doesn't really keep up with the macOS version on a low-end laptop.
The software side of things also makes it hard. Apple wants iOS and iPadOS to be really user easy and pretty secure. That conflicts with the way people want to be able to use applications like Logic and hardware like the new MOTU interface that I have that is much faster with MOTU's drivers on my Mac than it is using the stock USB drivers on my iPad. That's why people from the Mac side of things are so afraid of the often predicted "dumbing down" of macOS to iOS. I don't think that is going to happen any time soon either.
Very wise!
Not sure it would neccesarily affect as dramatically as peeps may imagine. I doubt you'll be able to use iOS plugin apps (like FabFilter stuff) inside Logic, Live, Cubase or ProTools, etc. So I don't perceive an issue there, myself. You'll still need the full blown, paid up MAC versions for that level of integration, I would've thought? However, I can imagine many devs might need to re-think their pricing models for DAW-like apps. For example, Gadget or Zenbeats on a MAC might be chin-scratchers for those devs and a re-think of their pricing structure, could be in order. I paid the bux for Gadget on my Mac, but now, might be somewhat obsolete because the Mac version gives little extra to the iOS version. But M1 could well be a boon for other devs with their quirky, unique apps and that suddenly have a much broader appeal beyond iOS without changing an iota of code.
Early days, with a lot of negatives and positives yet to be realised. Exciting development none the less.
My understanding is iOS AUv3’s will work inside DAWs. I believe that’s been backed up by at least one developer comment.
After all, AUv3’s are actually separate programs that are just instantiated by a host. I know enough about AU development to know that most of the code is already shareable between Mac and iOS versions of a plugin. Apple’s own AUv3 example project illustrates this clearly.
That’s been my experience. AUv3s should be transferable with little to no adjustment other than the UI, barring inexplicable issues caused by lack of documentation...
Crikey! Tin of worms awaits, if correct. I'm sure there'll be plenty of devs that jump straight in, even if it's not from the popular devs straight away. A new Mac is at least 6-12 months away for me so plenty of time to see how this pans out over the coming 12 months or so. I watch on with keen interest.
It could imagine it might be a little disappointing at first. You might have an app available, then not.
I could see a period of adjustment. As long as there’s incentive, there could be more options
Devs don’t have to jump straight in. They will be thrown in the pool unless they go to the trouble to opt-out.
Importantly, however: This will only be relevant for musicians who buy a brand spankin’ new Mac and who also use a Mac for music production. That seems like a really small slice of the music app buying public. Prolly not gonna be a real big deal except for those inevitable one-star reviewers who’ll get pissed off if a dev opts out or if their app isn’t perfect on MacOS.
I’m not sure I understand. No apps are going away. If you have an app today, you’ll still have it in the future.
Maybe meaning that a developer will forget to opt out, you download it, and then the developer opts out after realizing the significance. Then if you have to update, erase your Mac, or possibly even migrate to a new Mac depending on how Apple will handle backup and restore for the iOS apps on a Mac.
I hadn’t thought about that possibility. Sounds like a can of worms. If it’s possible to buy an app based on it being available in both, then that’s taken away ... messy.
With touchscreen this new MBP could be the iPad I was always waiting for
I'm fairly sure they won't allow that.
You want messy? How about I don't really want to use the App Store at all and I only do on iOS because I've got no choice. I decide I want to make AU's for macOS and release them on my own store or through KVR or something similar. Then, I make them available on iOS and don't do the opt out. Then the user gets two ways to buy them on macOS. One will work well and one may be a disaster (it hasn't been tested after all ). The developer ends up getting hit with refunds for something they didn't even intend to sell.
Totally depends on how an AU has been implemented. It's not really that standardised and the devils are in the details... For example, it's possible to have an AU that works fine in one host on iOS, but not on another, largely due to lack of standardisation and (imho) shockingly bad developer documentation. And there are a lot more DAWs on the desktop...
I think all you can safely say right now is that some iOS AUv3s might work inside some DAWs
Don’t let Apple’s names add to any confusion.
The M1 will just be called an A14Z or similar when they stick it in the iPad Pro. If there are any differences they’ll be minor.
There’s a reason Apple have only picked off the slowest Macs for the first wave of the transition; they’re the Macs for which the iPad Chip is perfect. The A12Z already stomped over the Intel i5s. And that’s also probably why the M1 maxes out at 16Gb. It’s “just” the iPad chip.
It will be interesting to see how much they can make the chips scale for the more powerful Macs.
It will also be interesting to see if any of the next iPad Pro’s get 8Gb RAM.
I wouldn’t be in the slightest bit surprised if the chips in the MacBook Air and the next iPad Pro’s are identical. Other than the name.
What’s the point of being able to run AUV3 in Macs if you can’t use them in a DAW?. Makes no sense. AUV3 plugins will be just like AU plugins, I’m not even considering other scenarios.
As to how it’ll affect the audio iOS devs and community... I guess the first question is. Why did these devs choose to develop for iOS instead of desktop?. I do fear this will bring more boring apps. My favorite apps are the ones that make good use of the touchscreen, like Samplr, they make no sense with a mouse, so I guess the devs won’t put that much effort and time for an app that only covers a part of the market.
My other big question... piracy. That’s a defining factor for the app world in iOS. As much as I hate the closed AppStore ecosystem, it is a good defense for devs. That coupled with the low price tags, provides some equilibrium that seems to keep these devs going (although barely in most cases).
What percentage of Waves Platinum users actually bought it?. You know the answer... that means high prices to cover the losses and an unrealistic and deformed market. I’m afraid it might engulf iOS devs.
Lastly, if AUV3 plugins can run on Macs, won’t AU plugins eventually run on iOS?. It makes sense after all, if they’re compatible, they are compatible both ways. That means all the big players and a radically different scenario, meaning the same scenario as desktop. Boring.
[...]
AUv3 do run in some macOS DAWs. I'd guess that iOS AUv3 will be able to run in some macOS DAWs. But, some DAWs on macOS will only run AU's that can be loaded and run in the DAW process. iOS AUv3's can't do that and so won't run in those DAWs.
Apple won't allow 3rd party in process AUv3 or v2 AU's to be loaded onto iOS. So, you can't go that way even though old style AU's do work on iOS. I'm pretty sure all of the Apple supplied iOS AU's are still v2 in process types.
Allowing iOS AUv3 on macOS is going to get confusing for users. But, if Apple is going to allow iOS DAWs to run on macOS, then they pretty much have to have iOS AUv3's there too.
The only part I really have a problem with is that Apple defaulted to putting iOS applications on macOS. It should have been strictly opt-in.
Well, perhaps you could be completely correct. However, I could imagine plenty of uses where it’s just plain handy to have non AUv3 iOS apps running on your Mac. AudioShare for starters. Utility apps. Chord, Arp and controller apps could be handy. Or even DAWs such as NS2 (just as one example) could be useful on a Mac - start a song on ur iPad, finish it on ur Mac, then import directly into a native Mac power DAW of choice. Perhaps your bargain-basement iOS Plugins can be coded to only run on iOS DAWs on your Mac - still handy to take your iOS work and conveniently export stems, etc. reckon the use-cases are fairly broad, myself. Boring for some, perhaps, but useful for others maybe? I’m so intrigued by the possibilities.
That said, I would love it if I could run FabFilter & Brambos plug-ins in Live or Logic, etc. but I won’t be holding my breath for this. Fingers crossed.
Lumafusion does.
I will mix in to the "opt-in vs opt-out" debate. I understand it's annoying for developers. They need to either take some action and be the "party-poopers" or opt-in and then need to test and support other set of (quite different) devices.
But from Apple's point of view it makes complete sense. Keep in mind, Apple's biggest success story is the introduction of App store and they are very well aware of this fact. App store for Mac never lived up to the expectations and this is the big chance to change it. Also, they need to have some extra selling point for new ARM Macs and having access to the biggest App store is definitely a strong one.
Obviously, making it opt-out means much much more apps to be available from launch. Maybe not working 100% fine, but they'll be available. Maybe they'll need to refund a lot of apps, but still it's not comparable to the risk of launching App store with iOS apps and only a few dozens of developers would decide to opt-in. There is a huge difference in telling "we have tens (hundreds) of thousands new apps available for you" than telling "we have some few apps ported from iOS".
Of course, this opens completely new set of problems. It's a bold move, but I believe if they communicate it well ("don't expect everything working flawlessly from day 1") and if they'll be generous in refunding problematic app purchases and dealing with developer's issues, it could be another big success for Apple.
Let's see what the future holds...
The big issue here is that whenever Apple introduce a problem they rarely have to deal with it themselves. That burden tends to be on their app maker community.
I’ve taken some for the team in the past. This time others can do it, and when I see them all happy and cheering I’ll likely get on board too.
/\ exactly this.
I work in FE, and supporting Macs in the corporate environment is riddled with fudge moves name by them and then we fight the fires..