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.
iMPC Fly hardware and BM2
.
Comments
this guy is a moron.
obvs MPC fly isn't being marketed as a universal controller to be used with BM2. its midi messages correspond to the functions within the Akai software.
waste of nine minutes to watch this guy whine.
get a QuNeo instead and quit crying.
...
.
This is now a solved problem. Long discussion on the BM2 forum at
http://www.intua.net/forums/viewtopic.php?f=9&t=3586
culminating in MidiBridge publishing a tutorial and translation map at:
http://audeonic.com/fly_bm2.shtml
.
If you're serious about MIDI you should have it anyway. For this and many other reasons.
Alternatively you can fuss around remapping the Fly's buttons but info on that is hard to come by. And doing so breaks its own App functioning.
MidiBridge is the MIDI equivalent to AudioBus. Which you also have to buy if you want to mix and match Apps. And like AB it's currently the only game in town for what it does, and unlike AB does not require App developer code to use - it's a pure CoreMidi (of all types) app. Even maps an Akia SS25 to VM when connected via its 30 pin adapter, making it useable with any CoreMIDI App, not just those that implemented Akai's API. Also gives you a central goto place for your internal and external MIDI connectivity, much nicer than having to visit each App and delving into their MIDI port assignment submenus to see who they are listening to or talking to. Just let them be visible to MB. Those that understand this and let you do it, that is.
NB: I am not affiliated with MB, I am however a long time MIDI expert and the designer of hardware MIDI routers used on high profile tours in the '90's. MB saved me from having to write my own iOS router, though there are still many Apps with crippled MIDI implementations that are so bad not even MB can fix them. BM2 has flaws - it's not just the Fly's problem.
Forget Akai, NI needs to make a proper IOS version of Maschine that works with their hardware.
dwarman is absolutely correct about MIDI Bridge. It's a very useful app.
.
And so is Intua, by that same reasoning. And Korg. And ... well, you get the idea, almost nobody (in iOS land) does MIDI quite right. BM2 drum pads use note numbers from 0 up, which is totally outside the normal range for almost any other synth, in particular outside the standard drum assignments range as defined by the General MIDI Specification. Akai is at least in the vicinity. AFAIK, only Bismark does the actual GM spec, but that is because it ships with a GM compliant Soundfont. Akai at least allow for pad note number assignment to be changed (on the big MPC, not so clear they do with the Fly), whereas Intua do not.
Same sorry story when it comes to synchronizing sequencers. 30 years ago we had a perfectly functional spec in the MIDI Real Time Messages set - Start, Stop, Continue, Clock, plus MTC and Song Position. You want more control there is MIDI Show Control. Today? Ignored, mostly. Almost everybody seems to use a CC# for Start, no standard assignment. Including players who were around then like Korg. And also many - BM2 included - seem to think that Clock is the driver and so only generate it between Start and Stop. Which is why other sequencers have a problem, since it is supposed to be there all the time so they can lock in their DPLLs to it. If they are doing it right, which some reports of clock jitter seem to indicate they are not.
Then there is this pernicious promiscuous port grabbing thing that the really lazy Apps advertising Core Midi do, then provide no way of overriding it when your MIDI routing actually needs some selectivity. Like the Korg synths - wonderful synths but unusable in concert with anything else, not even each other. Unless you decide which gets which MIDI channel and mute at least half of their combined functionality (muting the synths is the only way to not have them not respond to a MIDI source). iMini is another one. Even Magellan messes this up. Sunrizer did too at first, but recently fixed it so you can turn off the sources not wanted for it.
Why does nobody read the spec any more? Because it is so 80's? Or what? A lot of good work went into it, and a lot of actual implementation and stage-critical honing. Just because we disappeared inside a hunk of plastic does not mean the rules for inter-process musical communication protocols changed. And anybody who lets their broken MIDI out into the real world of MIDI cables is legally not allowed to call it MIDI any more - that domain and trademark is owned by the MMA, and strict compliance with the spec is required. Though so far they are keeping quiet about it.
.
@dwarman I'm definitely feeling the sentiment there.
If you we're in charge of implementing a way to solve all of this via Audiobus as a possible MIDI clock/sync master or whatever you want to call it, what would you do ?
@dwarman: I couldn't agree more!
@DaveMagoo -Unfortunately, and as I think you yourself have mentioned elsewhere, the communication channels is already in place and it is up to the Apps to use it. AudioBus could perhaps provide a centralized distribution point for the Real Time Events, and that might make it easier for those who have a problem, finding that stuff in amidst all the other MIDI complexities. Should AB choose to do this, it really also needs to then advertise IN and Out Virtual MIDI Ports so non-audio Apps can share the goodness (e.g. Genome). Running a pure MIDI sequencer controlling AudioBus synths is not uncommon by now.
To do it properly would require supporting all the Real Time messages (Clock, Start, Stop, Continue, Song Position Pointer, MIDI Time Code), and should probably also supply a matching SMPTE synchronization channel. AB could also do the hard lifting of things like: extracting BPM, re-distributing Clock after slaving a DPLL to the master Clock source (to minimize jitter), and possibly even providing some support APIs (for help mapping timecode stuff into an Apps' internal representation of time). Who is Master should be a user selection.
@Simon - I guess I am. I and my composer buddy got very frustrated with how basic things like MIDI routing were handled back in the late 80's and founded our company Lone Wolf to begin to address the issues. One of our prime strengths was the fact that we were both Data Communication specialists for our day jobs, and I believe this gave us a unique perspective on the connectivity issues.
Hardware and main desktop DAW sequencers have always been OK with the clocking and playback/record head sync, but getting A to talk to B and C in anything but a trivially small MIDI studio was a mess and almost always involved repatching MIDI cables. There were MIDI switch boxes, but invariably exhibited a solipsistic view of the world they were connecting, and had minimal merging capabilities (typically 2 of their 8 ports).
Our home setup was not trivial - we had around 30 MIDI sources and destinations, and also hosted a regular Friday night Jam with several performers all needing to share the resources. I recently came across my binder with all the hard cabled topologies for our songs, interconnect diagrams between three such switch boxes and the outboard gear. Makes me shudder.
So we built the MidiTap networked MIDI router, with tiny fiber-optic network cabling and a master-less peer to peer hardened protocol, and built on top of that a fully soft topology router which can take any channel from any input cable on any box and route it to any combination of channels on any cables on any box, with filtering and transposition on both In and Out ports, and do this for up to 12 peer performers. It was a hit with the pros, got us an AES Tech Award nomination, went on several major tours and into several major studios.
We then learned the hard lesson of price vs market size vs investment in manufacturing - only the pros who knew what it did and felt the pain it solved were interested at the price we could build it for, and the market saturated out much earlier than we expected. And I have parts in my closet to build a bunch of them to this day.
I still rely on my MidiTap network in my studio, even though much reduced in size since those days, and really do not understand how anybody can manage a serious setup without one. Yes, we lived with it when there was no other option, but every day we sad "This sucks. Somebody must be working on it!" until we finally snapped and changed to "Nobody is so I guess it's up to us".
So I have my external MIDI solved. I thought for a while about making a version for iOS but then MidiBridge came along, and it solves most of my new needs. Still a few rough edges, which I have mentioned, but for the most part it works well with well behaved Apps.
Thanks @dwarman I guess I will have to make do for now, I hope the Audiobus team have the ultimate solution around the corner....we will have to just wait and see.
Midi really does seem like the square peg in the round hole on IOS right now.
Thanks again for the insight.