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
As promised, here the updated list:
With sample-offset
Without sample-offset
Midi generators that don‘t set the sample-offset will produce sync-issues.
@_ki Nice list!
Now who take on the challenge and bug the crap out of the developers with apps are on the 'sync issues' list?
The only app left on my iPad from 'sync-issues' list is BeatHawk which I only use as stand-alone and export when needed...
Cheers!
Wow, thanks for putting in the work hopefully the developers will see this and add the correct code, it’s free on github thanks to @cp3
Agreed. I just sent a pm to one of them letting them know about this thread, the issue, and the solution.
@Audiomodern @cem_olcay @ElliottGarage @4Pockets @4pockets_paul
Hey developers. How can I write this to not come off like a jerk… Some forum members have put in some work to discover a midi sync issue with some apps. All of these apps appear not to have sample offset or sample accurate timing. I’m not a developer or coder but I feel like this thread should be brought to your attention. In an effort to help developers and work towards the mutual goal of creating a better app for everyone to enjoy, forum members have tested and outlined a midi sync issue. Thanks to @_ki for providing the tests and information and thanks to @cp3 for providing his code for sample offset/sample accurate timing on GitHub. The problem, and the solution is provided in this thread. I am politely suggesting you take a look, and hopefully consider an update. I love all the apps listed, but this seems like a simple fix that could make a great app even better. Please don’t hate me, lol. Thanks.
I had already PM’d them all as a heads up 🙂
Cheers, I did to one of them. Said they would look into. So we shall see, don’t know much code but it seems like all the pieces are available.
Timing issues with sequencers aren’t uniform...
A - sequencer uses internal sounds on it‘s timeline
B - midi is sent to another sound source
B1 - within a DAW/device, using virtual (software) midi protocol, timestamped or not
B2 - external destination, using USB midi, timestamped or not
B3 - external destination, using midi DIN connectors, afaik no timestamps here
Recently I had a stunning case B3 experience with an MPC Studio driving an external drum box.
Dragged notes on screen (sequencer running) and timing was similar to touching a vinyl record player...
(maybe lack of CPU power, maybe interrupt handling screwed the note sending, dunno...)
Helium just got a MIDI timing update
Cool - but when checking the updated Helium, i noticed that for each bar-start a 0 sample offset is used (which is not correct).
=> The updated version produces an audible offset every bar when used in my above Rozeta XoX / Plectrum test session and 2048 samples. To verify that it doesn‘t depend on the BPM, i also checked the occurance of that error with 101bpm.
.
@4Pockets @4pockets_paul Heliums timing has gotten better, but its still not working correctly.
I attached the AUM session for easier debugging. Plectrum is a free on the app store. MIDI Monitor isn‘t, but its the only AUv3 midi monitor showing the sample offset.
To hear the error, set AUMs samplerate to 2048. The double click/flam occurs on bar start and at the same time the sample-offset send by Helium is zero. Change the MIDI monitors input to XoX and notice that it doesn‘t use a zero sample offset except for the first note after pressing start.
After further investigation i found out that sample-offset zero is set for the note right on the start of the loop. If the loop-length is two bars, the double/click flam due to sample-offet zero happens every two bars, on each loop restart.
And here is an audiobus preset for the SyncTest - like with the AUM session, you need to set buffers to 2048
http://preset.audiob.us/VYy2S9BY0wmLDqc
PS: Can someone inform Paul that the problem isn‘t fully fixed and that this thread has some more info and test sessions. I don‘t have his direct email and the 4pockets site is currently in maintainance mode.
Just keeping this one live.
@cem_olcay @ElliottGarage @Audiomodern would love to get your feedback?
The seq in SKIIID has timing/sync issues as well.
@0tolerance4silence Hmm, i don‘t see any midi output from SKIID, maybe you meant that the internal sound sequencer is not tight ? Does it also depend on buffer size (larger buffers, more jitter) ?
Yes, it applies to its internal playback. The timing is ok-ish, but it’s late by one buffer length against the host. Also - probably related - some trigs are inconsistent. E.g. if you create an ‘init’ sound, copy that step to all steps and place trigs for every step. The second step will choke every time. Changing pattern length can introduce timing and sync inconsistencies as well.
Dope
Yea, glad you did, I think it’s important and the solution is available… yes I’m just a consumer but it should at least be “on the list” imho.
Don’t wanna come off rude or unappreciative I love those developers and want to see their apps at the level they could be at.
I tried using Riffer in a track last night but it drifts so I have record it’s midi into Atom2 and quantize it. That’s not good for a midi sequencer… I really hope the developers take this seriously.
Sometimes it’s a host issue in the way that an auv3 will sync with it.
Eg. Some apps will drift in Drambo or other host apps but stay consistent with AUM.
I don’t think that’s the case here because of the tests we’ve done.
OK, a month later. How we looking?
No real change since august:
Update: The looping problem of Helium‘s was fixed, also added Zoa and a list of midi generators i couldn‘t test
With sample-offset
.
Without sample-offset
Midi generators that don‘t set the sample-offset will produce sync-issues.
.
Unknown
Could not check these midi apps as i don‘t own them. But the devs already offer AUv3 midi apps with correct sample-offset, so it’s likely they also support it.
Fantastic 👏👏👏 And I saw that is not the only useful code you’re sharing on github.
@cem_olcay @ElliottGarage @Audiomodern 🙏
+1
I hate to bug you guys, I know all of you are busy, but this seems like a must do, no brainer, slam dunk, must have, simple fix. The midi timing is so important for apps. This fix is of the utmost importance for your apps, for your customers, and therefore the music we create. I think most would agree, we need this. I’m not a coder, but the tests, the issue, and the fix are all provided in this thread. I have massive respect for all 3 developers, and I would truly appreciate it if each of you @cem_olcay @ElliottGarage @Audiomodern would add sample-offset to ensure midi out timing accuracy.
As you can see from the above tests, thanks to @_ki the results are in, the issue is real, the fix is readily available for free on GitHub thanks to @cp3 please see above. If you could please at your earliest convenience implement the”sample accurate” midi out many of us would be forever grateful.
Thanks to @gusgranite for keeping this thread alive. I f think it is very important as well. its funny I was just thinking about this thread only a day or 2 ago, and thought I wonder if those developers have seen this yet.
Thanks @cp3 for sharing this code on GitHub
@gusgranite if this don’t work what’s next dm’s
No! We call the MIDI Police!
😂
There is no next on my part. Once a bug has been reported I need to respect the developer’s decision and prioritization. And maybe offer gentle reminders at a future date 😉
Lol. I heard about them.
Yea I know. I have no doubt they are very busy and I truly respect each and every developer mentioned. It’s just something that seems best for all involved, and I want to at least try to encourage them/convince them… I guess that what we are doing now. Lol. Just hope they hear, then head the call.