Check out this excellent interpretation of Muse’s Bliss using iOS apps (and of course Audiobus).

Audiobus Launch on December 10th

We’re going to launch Audiobus on Monday, December 10th 2012.
It will cost 9.99 US$ and it’s going to be available for the iPad, iPhone and iPod Touch on iOS 5.0 and later.

Supported apps at launch will be, in alphabetical order:

Funkbox (input slot)
JamUp XT (effects slot)
JamUp Pro XT (effects slot)
Loopy (input and output slot)
Loopy HD (input and output slot)
MultiTrack DAW (output slot)
NLog MIDI Synth (input, effects and output slot)
NLog Synth PRO (input, effects and output slot)
Rebirth for iPad (input slot)
SoundPrism Pro (input slot)
Sunrizer Synth for iPad (input slot)

We’re expecting Thumbjam and Drumjam to be available shortly after launch since they’re currently waiting to be reviewed by Apple App Review.

Moog and Wavemachine Labs have been working on making Animoog and Auria, respectively, compatible with Audiobus but implementation is not yet complete for either of them.

We’ll be starting a limited second wave of Audiobus apps – limited so we can rapidly respond to any potential remaining issues – by giving another 25 developers access to the SDK. These developers will be selected from the list of developers who have expressed interest in acquiring access to the SDK – currently that’s a list more than 700 750 entries strong.

After a sufficient amount of apps from the second wave of developers have been approved by App Review and feedback is favorable, we’re going to make the SDK public. This is going to happen in the next months.

For those asking themselves how long it takes a developer to implement Audiobus support into their app: It depends on the complexity of the app and level of integration. The fastest teams have done it in one day. Testing and submission to App Review is typically the most time-consuming part.

We’re currently finalizing the manual and we’re going to post videos demonstrating the less obvious features of Audiobus over the course of this week to shorten the wait.

Results of radical design can’t be planned for in advance.

Apple was right. I was wrong. 

Roughly a year ago I wrote this blog entry about how it is impossible for developers to get a definite answer from Apple App Review before starting development of a planned feature or app.

As a developer it would be so cool to figure out if App Review would be ok with a certain way of implementing a feature or something that an app does before sinking weeks or months of development time into its creation just to have it denied by Apple App Review.

Only it won’t work.

Not because Apple is never going to open up their App Review Team to developers’ requests for communication but because results of the development process of apps are impossible to predict with absolute certainty. If we can’t predict the way we’re going to implement certain features, how would Apple App Review be able to give us a carte blanche for it. You want an example? I’ll give you an example. It’s going to be about Audiobus.

In a previous post Michael demonstrated the concept about inserting a slide-in menu into apps to switch between them and to trigger functions in apps running in the background from an app running in the foreground. He called it the “Connection-Panel”. Both of us thought the idea was very neat. Other developers thought so as well. But from previous experience I know that what developers think can be very different from what users think. So I asked a few iPad musicians on Reddit about it.

Some of them said that they didn’t like the new notification menu in iOS 5 and compared our super neat connection-panel to it. How could they?

It forced us to re-think the implementation. We tried to go for a very subtle way to implement a means to control apps running in the background. The less screen real estate it consumed, the better. Now one of our users says that he hates it already. He even posted a video about how to disable the iOS 5 notification thing that slides out from the top of the screen completely.

So we came up with a slightly different solution:

We’re going to keep the Connection-Panel. But we’re going to make it optional in case you have a second iOS device that the Audiobus app is running on. If that’s the case, the Connection-Panel is going to be disabled in all apps and they will be able to be remote controlled by Audiobus running on the other device. To make it clear, here’s how the currently preferred solution looks like.

For users running Audiobus on one iOS device:

  • Use the Connection-Panel to switch between apps and trigger functions.

For users running Audiobus on more than one device:

  • No interface at all in apps that you want to play in.
  • All of the interface on a second device.

Is Apple going to let us do that? We don’t really know. It’s likely they will. Would we have been able to ask them before we started the implementation and got feedback from users? Before even announcing what we would be doing to the public? What if we come up with an issue while development is almost finished?

They couldn’t have given us a carte blanche because we wouldn’t have know what ask for.

Apple is doing the right thing by not even offering one.