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
You know, if I didn't spend 90% of development time nowadays dealing with broken Xcode versions, downloading 7 gigabytes of Xcode updates PER DAY, which then cease working again 3 days later because Apple messes up EVERY Xcode (and iOS) update nowadays, then yeah, it would all go a bit faster probably
Seriously, no idea what's going on in Cupertino, but they seemingly have completely lost control of their software and QA processes.
That would sort it out beautifully. As many modular X2 timelines as you want, all syncing to the same timeline inside AUM with MultiTrack recorder handling the audio duties. Done.
Well, almost. There would just be one small feature request (already made) for MTR needed.
You really gotta wonder. My son’s fiancé owned an Apple Watch for a total of 4.5 hours today. No combination of moves would get it past the catch-22 of needing to update the watch in order to pair it to the phone, but needing to pair it to the phone to update the watch. And, the Phone needed to have its OS updated ... to a version not supported on the iPhone 6 apparently.
The first time user experience used to be the thing that impressed me the most about Apple products. Now they can’t even get that right.
Steve Job’s death? Or legalization of weed in California? Probably both.
😂
Agreed, Apple have slowly gone downhill. Lots of odd decisions made.
Yeah it sounds like a cliche, but it's definitely true. It's the typical "no vision" or "no bigger picture" syndrome. Steve "Hitler" Jobs knew exactly what he wanted, had a vision for what the PURPOSE of Apple products would be, and then with his near-pathological perfectionism, made damn sure that they actually WORKED for that purpose (and to be honest, I think he was like me in that regard: he primarily wanted a great product for HIMSELF too! So that made him even more motivated to get them right. Same as with Xequence...)
Tim Cook is all about making the shareholders happy. That's fine, I'm sure he's a good accountant, but unfortunately, he simply doesn't have a broader picture or vision for Apple's PURPOSE, beyond the shareholders.
Yeah, has been said a million times already, but it bears repeating.
And all this political agenda pushing is also new since Cook. Anyway...
Will wait until I get another 50 Gigs of data allowance for the next month and then download the then-current Xcode version. Maybe it'll work long enough for me to upload the update
Just to clarify, and so you don't think I come to this problem/approach afresh, I have been trying to solve it for years, with the tools available. Just so you understand my dedication on having it solved, at all:
https://forum.audiob.us/discussion/15761/modstep-midi-pitch-wheel-not-responding
EDIT: You need to scroll that thread, and there were a few threads from that same time, but this was the one I posted my attempts in as images. At the time, Modstep (this was before Xequence) was the closest contender to being able to solve the non-DAW situation. Enter Xequence and the hopes rose to new levels, at the same time as ModStep updates started to not happen. This is possibly the reason why so many people have put their hopes on to Xequence. This is the reason why I have persisted on trying to find a workable route forwards with Xequence. This is also why I'm disappointed in your aim to turning Xequence into a NanoStudio2 (without Obsidian and Slate) instead of making Xequence fully into what it could be ("the most usable midi sequencer on iOS"), which would be an USP (Unique Selling Point) of its own, enabling people to do what they wish without being confined to a sandbox (NS2, Gadget, Garageband etc).
Just to so you understand. I'm not being annoying because I love being annoying.
@hellquist I don't take any kind of constructive feedback or criticism as annoyingness, don't worry
I originally started Xequence as a hobby project for myself so that I would have a good sequencer for Gadget. I really only put it on the App Store "just for fun" back then and was very surprised to see that it actually get some traction. Only then did I start adding features according to user requests (I myself would never have added Ableton Link or Audiobus support for example, because for my very conservative and simplistic way of working, I don't need either).
So, nowadays, I mostly consider Xequence "feature complete" for my own use, so most of the features I add are user requests, and of course, bugfixes. So believe me that I do listen carefully to all feedback and try to sort it into a roadmap that can be implemented in a sensible and -- most importantly -- stable manner. I develop software like NASA develops spacecraft. First priority: STABILITY
So it might take a bit more time until a feature arrives, but when it does, you can be damn sure it works 
And as mentioned earlier, Xequence 2 has a double life anyway and actually IS already very similar to NS2, but the audio features are cleanly separated from the sequencer and hidden behind a switch (in code), so nobody has to be afraid of interference there -- as long as that switch is disabled, Xequence stays true to its pure and focused sequencer personality
(when I make music nowadays, I make it completely "in the box" in Xequence 2, including all sounds, effects and mastering. Not even AUs. The modular synth can really do anything anyway if I'm not too lazy to wire something up, and as all FX modules are available both as inserts AND as modules inside the modular, I don't think there's a lot of stuff that can't be done inside that box
) But for my conservative 4/4 EDM, I don't need anything fancy anyway 
)
Hehe, aye, and reading that post of mine I realise two things doesn't come through:
In fact, those two things might have been why I pestered you in the first place.
Anyways, I respect your point of view and your route for your business. Just wanted to make clear that even though I'm in here on/off (as regularly as my music-making) I'm not coming from nowhere to complain about a new problem.
I also understand/appreciate you do not wish to be a part of the solution to that problem, hehe.
Peace, and do keep up the good work.
Thanks a lot. I didn't mean to say that none of the "Missing Links" you've pointed out will ever come to Xequence -- it just might take some time, and some more monitoring of the situation and where the iOS music making landscape is going.
And as I said, I appreciate open and constructive feedback like this and also like discussing things as they are.
Xequence AU MIDI Track (Piano Roll + Timeline) would be soooooo cool.
+1
Is this a thing @j_liljedahl ?
Or is there a way that AUM could sync to midi song position pointer and midi beat clock as @wim found?
MMC is just a "transport remote control". You can start, stop, record, etc. AUM does not support MIDI clock slaving or MIDI song position pointer. It's not trivial to add, since AUM is an audio host and not a MIDI sequencer, the tiniest amount of jitter or instability in the clock would be clearly heard in any FilePlayers etc. MIDI clock was designed for MIDI sequencing with modest requirement for clock resolution. There's a reason so few audio DAWs supports slaving to MIDI clock.
But it supports slaving to Link.
So ... if it could just support SPP and rely on Link for the rest? I think I know the answer, but I just gotta try.
Another valid question though: why the flying f*** doesn't Ableton Link support some kind of song position API after all these years and all the hype and at version three? 😬
Are you saying I need to start hassling Ableton now? 😉
I don't know
But I thought it was just an obvious thing to add, after all it seems to be the most used sync technology nowadays, and it's the only missing piece to make it complete really...
You're totally right @SevenSystems.
On the other hand, I've been listening to host developers resisting MIDI Clock for 20 years now, not wanting to support it because it's inadequate and antiquated. Meanwhile, MIDI remains the only viable standard that works with everything, and hardware has just rolled along with it. They've proclaimed it's death is imminent since the last century, but nothing has come along to replace it.
It's never going to change. I give up.
But! if some brilliant developer who has a standalone app that's best in class for midi sequencing and two outstanding AU midi control surface apps, decided to port a subset of his outstanding piano roll/timeline midi sequencing app to AU midi, maybe I can someday come back to the quest for a modular "best in class" approach.
Yes I understand
not to get too philosophical or off-topic now, but I want to say something more generic here:
A protocol that deals with solving some kind of problem cannot really be "outdated" unless the problem drastically changes. There's a reason why MIDI is still around in its absolutely original 1983 form almost 40 years later -- it is well-designed and the problems it tries to solve are essentially unchanged. There is no need for something more "modern" because MIDI is not "antiquated".
Yes, maybe nowadays' XML crowd, where to store the number 1234, 500 kilobytes of bracket bullshit are needed, would say that MIDI's enormously optimized use of bandwidth is "antiquated". But even then, sending the same information over MIDI as over, say, XML, is still 1000 times more efficient even nowadays, and if you send 1000s of notes or controllers at the same time, even with today's hardware you would notice.
With that off the table: MIDI sync is also quite well designed, and well-specified! (something that cannot always be said about Ableton Link, for example). The MIDI spec is extremely clear and goes into insane detail for the tiniest things, because it was designed in a different time -- when things (specifications, software, cars, etc.) where built for the future, not for the shareholders! (do I sound like anticapitalista now? I amn't!)
The same can be said, for example, of the C programming language. It's also essentially unchanged since around 1980 or earlier.
I mean, it's just ridiculous how a "modern" programming language like Swift has now seen like, what, 5 iterations in 5 years? That's just insane. It doesn't show that the language is "modern" or "current" -- it just means that no thinking-ahead has been put into it, and its designers keep adding and changing stuff because they didn't have a coherent vision from the start.
Wow, that was a lovely post!
Does link keep track of the full timeline though? Couldn't a "linked" app join in whenever on the timeline? The only thing guaranteed (today) is that it will join/leave at a given quantum cycle, no?
Yes that's the thing that I was wondering why it is still the case. Ableton could "easily" add absolute timeline synchronisation. They clearly intend to replace MIDI sync with it, so why do they hold off on this single thing that's missing?
For similar reasons that no other app developer apparently wishes to include external midi sync in their apps, which would negate the need for host sync, I would guess. If all the apps we use today had an option to enable external sync source we as users would also be a lot better off, with a plethora of options and a possibility to create our own workflows. To me that should also be done "easily", so clearly I'm missing a vital point somewhere, as they/you all seem unwilling to do so.
I liked your post @SevenSystems ... mainly because I agree with it 100%. Funny how convinced the most talented developers have been, since I got involved in computer based music 20 years ago, that it would be a waste of time to support midi clock because surely would die soon.
But, I'm really wondering about this thought that SPP and Link could somehow be used together. Is it even practical to think of having Link handle the synchronization and SPP handle positioning at some level (probably no more granular than the lowest Link beat I'm guessing, though)?
My intuition tells me that would be impractical to do well. But in my IT Systems and (minimal) development career, I've found that reaching for whatever gets the job done can often be good enough.
Trouble is, great developers hate to do anything halfway, and none really like the idea of needing to slave to something else. Lost cause I think.
Yeah, the vital point is that slaving is much harder than "mastering"... it's the same in the software world as in real life
It's always easier to have control of things than to be controlled by others (and play well with them). Sounds mundane, but it's true and perfectly applicable to software and protocols as well.
@wim... I see no reason why Ableton Link shouldn't have another mechanism "ABLSetSongPosition(beats)", and some notification to receive that position. All the other synchronisation stuff can stay the same really. There might be some edge cases, like when several peers send different song positions at the same time etc., but I'm not the one who has to think about them right now
It sounds like this isn’t going to get solved then.
Next opportunity I can see is when someone makes a piano roll that’s au and also has a clip arranger, like a midi versh of 4pockets multitrack. Maybe that’s what atom will become.
Until then we’ll have to keep within cpu limitations which isn’t the end of the world.
Hehe, aye, and also I too liked your post above, it wasn't there when I typed my first Link question post (2 comments ago I'd say) as we probably were typing at the same time. Good stuff.
But I'm also thinking like this: if an app generates midi clock in itself, that is probably done via a function/class (or whatever the relevant coding language calls it). It generates something, which in turn outputs something (time) based on reasons, which is then used elsewhere in the app, right?
What if one added another function (EDIT: that would be optional, used at the discretion of the end-user), that skipped the generation part, took the incoming generated equivalent something (time) along with reasons, and still created an output like in the first function?
The main difference would be that you wouldn't be able to affect, or perhaps do quality control of the input. Trust me though, market forces would do that. If it becomes known that a sync generating app does a crappy job of keeping sync (and on this very messageboard there are people who would show graphs of where the problem comes from, in detail) it would live a short life indeed, so we could try another sync generating app. Rince, repeat until we flock around the ones we like/agree with, which in time become the standard apps for that task, all whilst using our current existing favourite apps to solve the various little problems we would like to solve. In sync.
If the app devs followed the same midi standard (and most of the reputable app devs probably would), the absurdity of that idea kind of escapes me, and I am stuck wondering why it doesn't happen.
@hellquist, I don't think apps which generate bad MIDI clock would be penalized by users. At least one totally mainstream DAW app is known to generate bad MIDI clock. Are users leaving it in droves because of it? No
On the "coding" topic: yes, that is the way that it would work IF Xequence supported slaving to MIDI sync. i.e. it would use a clock signal -- either its internal one or an external one -- to advance its song pointer during playback.
However, currently its "clock" is very naive -- it just uses the "wall clock", i.e. totally common time. That's one of the design compromises decided very early during its development. And one of the reasons why I keep saying that Xequence "has not been designed for slaving". But it's nothing that can't be changed of course.
But other than that, your idea is totally right and that's how it would be normally designed.
What about ApeMatrix? Is it a viable alternative to AUM in this situation? I don’t have it.
It says it does ‘precise midi clock in/out’
Tempo and Start/Stop only. No timeline positioning.
Audiobus 3 has transport controls and fast switching between apps. Without it you would have to tap Record in AUM, switch to Xequence and tap Record on that too. This is explained in the manual - see Example Setups -> Using Xequence + Audiobus + AUM together
http://seven.systems/xequence2/en/manual/