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
@SevenSystems up and running ! And I think it's smoother to use !
The timeline view seems much more fluid to my iPad pro 12.9" 1st gen just after loading a new song.
But then, and I think it's about the IOS bug throwing error messages, it became a bit slower (not like crazy, but I do notice the difference.)
@crony thanks for the feedback... let me know if there's anything suspicious going on and it will be investigated 🙂
So from now on, all updates will be named after places in Ireland? I hope the Ballykissangel update will be as pretty as Assumpta.. and AU..😁
Haha, nice that you saw it 😁
I wanted to start with this release already, but after spending 3 hours with waiting for a beachballing Mac and broken Apple servers and 8 Gigabytes of downloads, I postponed it for next time 😉
I can almost certainly say though that the first town that takes the cake is Ballinaboola 👌😊😇
Thanks for the update @SevenSystems.
The jump when locking keyboard bug seems to be sorted.
I am still seeing occasional instances of partial keys though.
edit: removed giant pics now that SS has seen my post.Thanks again!
Such a brilliant app.
@blakkaz glad to know the problem is sorted.
Yeah, you will still see that particularly with very narrow keys, as one key always has to be a whole number of pixels wide currently, so there will always be an error. That's essentially unavoidable. The only solution would be to either leave blank space at the left and right sides (even worse), or make the border between keys a pixel thicker or thinner sometimes (looks crappy).
It would in theory be possible to make the keys fractional width so that they fit exactly, but that would then need antialiasing and make it significantly slower, which is not worth it imo.
I really would not call this update mundane.
This is a significant update that will add spice to our music
Full time signature support is a first for ios and the new swing engine is as good as it gets
exciting stuff
Thank you
Thanks for the kind words! And sorry for saying "mundane"... nowadays I have a feeling that any update that isn't AUv3 is mundane
(sorry!)
The only developer we have to chide into not trolling himself.
Too funny, Canadian or British I assume?
I'd like to chime in with praise for @SevenSystems too. I'm super late to the party just picking up Xequence a couple of days ago. So far I'm finding the app to be very intuitive with a smooth workflow, despite being very full featured. For anyone who wants a modular workflow rather than working inside a DAW who doesn't already have Xequence, get it!
@SevenSystems : I seem to recall another dev on this forum put out a request for a Roli to develop MPE for their app, and got one. Your prog is important to a lot of people here - worth setting up a crowdfund somewhere and giving it a shout out here, to raise the dosh for a decent comp to develop on? Just a thought.
That might be a good idea for the future! However, before that I'd probably set up a crowdfund for a new Mac Mini, because this 2012 model now takes 5-10 minutes to launch Xcode, 30 minutes to launch a single simulator, and then anything from 10 seconds to 10 minutes for compiling a project. So, first things first!
@SevenSystems : yeah, um, that’s what I meant. Whatever computer you need (I was just referring to the Roli/MPE thing as an example of people on this forum being willing to help devs with whatever they need to get the job done. A MacMini? Sure, why not? Can’t hurt to try, right?
+1 for a crowdfund
@SevenSystems I think I may have found a bug with this release (maybe it was there before ?)
On this screenshot, I have 2 tracks using ISEM synth, I also have a program change on the first bar.
The PC is not played as I start the loop at bar 2, but if I mute/unmute the track with the PC it reloads the sound of ISEM synth of this PC.
I'm trying other sounds, and mute/unmute these two tracks, but everytime I do this, the PC set into X2 is reloaded...
Am I missing something ?
Thanks
@crony, you're right, program changes aren't sent when the transport is set to "Play" (controllers, on the other hand, are). But they do get sent when you mute/unmute a track, because that is considered a song change and triggers sending of both controllers and programs.
Thanks for letting me know, I'll investigate this. The thing is -- I'm not sure if it is even desirable to send program changes when you hit play? It might actually take synths some time to process the program change (even if it's the same program as before), so you might get a glitch when hitting Play?
I think that was my reasoning when I left out program changes when hitting Play (they are sent in all other relevant situations: After loading a project, when the song position is changed, when tracks are muted/soloed, and when they are created / deleted / moved etc.)
@SevenSystems in my mind, I thought the PC was loading as a midi note is played. I mean while it's been "played" while the timeline is "passing" on it.
That's why I have set a false first bar, with all program changes, on first loading, then I play from bar 2, then it never load any PC again, except if during a break I load some other PC's...
@crony no, Xequence's handling of program changes (and controllers, and notes) is much more sophisticated -- it will actually "chase" the nearest previous event (program change, controller, or note) for each situation and send that whenever the song position is changed, the song itself is changed in any way, etc.
There's no need for the playhead to actually pass the program change. (of course, it will also send when exactly that happens, but you do not have to force it).
But there's definitely some inconsistency between the backchasing of controllers and program changes, which I will investigate!
EDIT: It might actually be a good idea to make chasing of controllers and program changes optional... note chasing can currently already be toggled in settings.
Will keep that in mind!
I guess so, but, to me, it seems a bit confusing if you'd integrate it as I fail to understand why would I need to load a PC in an other case than playhead playing it ? ( even for a CC )
@crony that's a bit difficult to explain and I might need a diagram for that. I'll get back to this thread tomorrow. Bedtime 🙂
Sure
would that make sense to increase the size of the midi pre buffer ?
Another question for the breakfast
I'm saying that because I'm already to the max, and it's much better, but after some time, I feel a little drift between my iPads...
It's okay for a 5 min song, but I guess it won't work for an hour or more of continuously playing...
Maybe an other way would be to have X2 being midi clock slaved ? (in that case I would have one X2 as a master clock.
@crony: the drift thing is an interesting observation. So you have multiple iPads "synced" (it isn't true sync, but more on that later) via Ableton Link, and they start exactly in sync, but then the longer they run (without any interference, starting / stopping etc.), they start to drift apart slightly?
It's not entirely impossible. Let me explain:
Ableton Link does NOT actually sync all peers to a common clock (unlike MIDI sync, which does). All Link does is tell all peers when exactly to start and at how many Beats Per Minute they should run.
However, what constitutes a "minute" is entirely up to the individual peers to measure.
Sure, it's internationally agreed on to be some kind of multiple of the wavelength of light. But I imagine that the internal clocks in iOS devices might be inaccurate enough to drift a few milliseconds per hour.
So regarding your last question -- yes, MIDI sync would definitely solve this problem as it actually provides a common clock for all peers. HOWEVER, unfortunately currently Xequence can only SEND that clock, but not slave (sync) to it. So you're out of luck in that regard.
UPDATE: I researched a bit more into this, and iOS device clocks indeed seem to be inaccurate enough for this problem to occur. See this post with a similar problem (and no replies 😂)
https://forums.developer.apple.com/thread/97131
And here's a good explanation about why back chasing program changes is important (from our competitors, but they're right this time 😁)
https://steinberg.help/cubase_pro_artist/v9/en/cubase_nuendo/topics/playback/playback_chase_c.html
@SevenSystems yep, globally same use case, same issue...
)
Would it be possible to consider a X2 slave midi clock feature at some point ? (I'll be generous for the Crowdfund
But I also notice less drifting while increasing the midi pre buffer.
Would that make sense to have it increased ? (more than the actual 500ms I've set ?)
I guess it would be a temporary workaround as it would inexorably drift after some time but might catch some time ? (going to 20 minutes at least would be a good start for me, to organise my tracks with start/stop at some point...
An other way would have to be able to set a midi control to start/stop in X2 without stoping Link...
Like this I could stop some iPads at some point, then put them back in sync with a play...(control midi assigned)
That would mean also no Link stop if loading a new song into X2.
Ok I understand for the PC, totally makes sense...
@SevenSystems Another argument for Xequence 2 slaving - just sayin 😉
@crony @gregsmith yes I totally understand the desirability for MIDI sync slave, and I'm considering it. It might not be that hard after all, did some research a few days ago.
@crony the buffer size shouldn't really matter... I'm surprised it does for you. Sorry I can't accomodate the other feature ideas right now, it's just a very special use case and live use -- as you know
-- is not Xequence's primary target scenario... but I'm still totally amazed at how you bend it to fit your situation! 
I know I know, no worry, my live is far from finished so no hurry...
Finger crossed for midi sync slave...
@SevenSystems I wonder if having some iPads at 44100 Hz and some at 48 kHz might have an impact on the timing...
I'm testing all @48 kHz (as I can't put the ipad pro 11 to 44100 Hz...)
Problem is it takes more CPU on my 1st gen iPad pro...Oh my...
No, the sampling rate has no effect on Xequence's MIDI timing.
@SevenSystems even on Link ? (Sorry to insist, but massive thanks for killing false believes for stupid people like me, I really hope it doesn't...)