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
I can confirm that it works exactly as I hoped it would!
I can confirm that it works exactly as I hoped it would!
Oh my, the goodness that just dropped in the latest beta is blowing my mind.
Good updates cheers @Michael looking forward to seeing some videos and updated manual to see how to use all this new functionality.
Amazing. Does the Virtual MIDI bridge mean that we can map midi transport start-stop commands from connected hardware?
No, you can already do that - the bridge is used for interacting with other apps via Core MIDI (like Touch OSC or MIDI Designer, for MIDI control, or apps like GarageBand which don't support any other MIDI standard)
Just wait until you see the next one (currently under beta review)!
Thinking about it again I realize that I’m barking up the wrong tree.
Dude, not sure my heart can take it.
Between the virtual MIDI and manual bindings and the AU presets, my brain is just humming with the possibilities. Superb.
Bing bing bing
I very much like Michael's specific 'flavour' of MIDI implementation (seen in Loopy, SampleBot and now AB3). Conceptually clean, incredibly flexible and very powerful
I'm still checking back against your file, but I think this is the happiest you've ever been on record
Spot on. Got so excited that the thread got unpinned from the notice board!
Yeah the Bus has definitely been moving up a few gears, lots of great updates recently
@Michael With virtual MIDI, I can now reduce the number of AB3 lanes in each preset by using MidiFire or MidiFlow to "aggregate" the incoming controllers that I use. I have noted that presets now launch much faster when I launch them from my controller. This leads to a question: what has the greatest impact on how fast a preset loads? Is it the number of controllers or lanes? the number of AUv3s I have loaded overall?
You know you can assign more than one input per lane, right?
@wim Yessir! I've been breaking my controllers across different lanes so that I can assign to different AU receivers (and control via the mixer). I realize that my question confuses the point about lanes vs controllers. I meant that as two separate questions in terms of impact on preset loading. I assume that the number of lanes doesn't have an impact, but shouldn't assume, right?
I should note that I'm probably extreme in how I use controllers. I use up to six different Bluetooth controllers and 1 USB MIDI controller.
Too good
@Michael is there a reason the virtual midi out port is now not showing under the midi receiver in the midi chain? I was using the virtual midi option there with AU midi sender apps at the start of the chain to get round the midi recording issue in NS2 among other uses it was quite handy.
I used to have circuit in the output of 3 midi lanes but now I don’t see that option anymore in the latest beta. Not sure if related but I can’t seem to find a way to reconnect it.
The newest beta has just dropped. All back to normal here.
I have to fight the urge to mess with it instead of going to bed. No choice though, tomorrow’s the tax return day. Gotta be fresh, Goodnight!
Well, you were correct! I had kinda expected previous and next presets (it's exactly what I was expecting), but the MIDI clock was a surprise. My question about preset loading performance above is even more pertinent now as optimizing against "lag" could make scenes work, in addition to the fab setlist-maker we already have here.
Exactly what I noticed today as well while testing. I hope they come back cause I had a pretty nice Cubasis setup rocking.
Wow. I am just on the verge of making the move from cuff links to buttons.
It's not what it appears based on the description. Four of the six controllers can fit in the front pocket of my jeans and you'd never notice as I walked by.
I, who always have much, far too much, to say, say nothing
Thank you!
I've never really profiled it much, so I'm not sure. Lane count shouldn't matter so much as total number of AUs/apps to load. What have you found to be the slowest-loading things?
I think you meant this for the Observations thread?
@Michael
Hey, I have a report back on the 'range' functionality that was recently added to a recent TestFlight version of the AB3 app.
The current implementation is sort of conceptually 'backwards' compared to what I expected from this -- I'll try to explain:
The expected behaviour that I spoke about before was to reduce the amount of parameter range movement on the software side for the same input on the hardware side. For example in AUM if I map it like this:
Then the full throw of the hardware fader will go from -inf dB at a CC value of 0 up to -0.6 dB at a CC value of 127. . As I'm working with AudioBus in performance, it's not really useful in this case to be able to take the faders above 0 dB, likewise there's no clear zero point on this (and many other) MIDI controllers and the throw of the faders is also pretty short on this pad controller (Akai Pro MPD32):
This is much preferable in a practical sense (in my opinion) to the current implementation where it is essentially only reacting to a subset of the available range on the hardware controller but still covering the entire range of the actual parameter (so the mixer fader is still hitting max -- a value range waaayyyy beyond what will ever be useful in a performance). Another way to think of it I guess is that I want to EXTEND the range of the control, so that to max out the parameter I'd actually need to send a CC value of something achievable like 180 or some such.
The functionality described above can be achieved by reducing the range on the hardware controller, but I don't think that's preferable as it explicitly binds a hardware preset to a software preset rather than allowing a generic hardware preset to control any software mapping. It also significantly reduces the resolution of that CC compared to the other way around, which actually increases the resolution by squeezing the 128 CC levels into a smaller parameter range.
There are probably loads of creative applications of the current method and they'd probably work well side by side, but the functionality I'm describing here (in relation to AUM's implementation) is what I was describing before and for me is a 'core' feature for performance control.
Hope that's understandable enough! The MIDI functionality is absolutely phenomenal and I'm working heavily with it every day in performance prep at the moment -- hopefully I can provide plenty of useful and constructive feedback!