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 Store

Audiobus is the app that makes the rest of your setup better.

Let’s talk about midi sequencer timing

Our very helpful member @xor put together a project in AUM to test the accuracy of AU midi sequencers. Now @xor is not claiming that this is super scientific in any way but it is interesting to see the initial results. It may help developers hunt down where timing appears to be off.

On the session I have saved I have the following AU sequencers (their note numbers at the front of their name):

1 Atom2
2 Snakebud = late (0011)
3 Drambo
4 Rozeta Cells
5 Riffer = early (0992)
6 Octachron
36 EG Pulse = late (0011, 1003)
44 DrumComputer
48 Digistix

In my testing it looks Snakebud and EG Pulse play late and Riffer plays before the beat (measured in milliseconds).

Try it at home! You may have other sequencers or get different results.

Thank you @xor for this cool utility.

«134567

Comments

  • edited July 2021

    BTW we’re using Atom2 as the yardstick due to @blueveek building that one out of pure tungsten.

  • The best tool I found to look at midi event timing (not absolute but timing but just timing accuracy) is @blueveek ’s MIDI Monitor, specifically the “time” column. This column is actually the offset with respect to the current audio frame of the midi event. If a stream has all 0’s for time that is good evidence of bad timing. Just take your sample rate (48KHz) / buffer size (64, 256, 2048, …) = frames per second * tempo (120, 45, … bpm) / 60 = frames per beat. It’s unlikely that will be a whole number. It makes sense for bar 1, beat 1 to be at the very beginning of a frame (time 0). If you have 93.75 frames per beat then a note-on event at bar 1, beat 2 should be 3/4’s of the way through the audio frame. If MIDI monitor shows 0 then you know it’s wrong. Unfortunately it doesn’t tell you enough to know if it’s before or after the beat. I wrote a simplistic Mozaic script that uses the system time (in ms) to give a gross approximation of when the events are occurring with respect to the metronome. I really wish Mozaic gave insight into the audio timing and the actual relationship with the audio frames but we make do with what we’re given.

    StepBud, like SnakeBud is consistently late. I put this together when I started trying to sequence Atom with StepBud and it went horribly wrong and wanted to understand why.

    Hmm, I seem to recall Riffer oscillating between playing early/late depending on where, in the audio frame, the beat fell.

  • I got kind of obsessed about this at one point. All I remember is Rozeta/Bram is rock solid and Drambo is for the most part but some apps seem to drift after a couple of cycles when using Drambo as the host.

  • @gusgranite said:
    Our very helpful member @xor put together a project in AUM to test the accuracy of AU midi sequencers. Now @xor is not claiming that this is super scientific in any way but it is interesting to see the initial results. It may help developers hunt down where timing appears to be off.

    On the session I have saved I have the following AU sequencers (their note numbers at the front of their name):

    1 Atom2
    2 Snakebud = late (0011)
    3 Drambo
    4 Rozeta Cells
    5 Riffer = early (0992)
    6 Octachron
    36 EG Pulse = late (0011, 1003)
    44 DrumComputer
    48 Digistix

    In my testing it looks Snakebud and EG Pulse play late and Riffer plays before the beat (measured in milliseconds).

    Try it at home! You may have other sequencers or get different results.

    Thank you @xor for this cool utility.

    I recommend testing with different buffer sizes. It has come to light that some sequencers (and other midi apps) fire off events only when the audio buffer is processed. BlueVerk and a couple of others have documented this.

    So, it would be good to know for these sequencers if they are subject to this issue.

  • @espiegel123 said:

    @gusgranite said:
    Our very helpful member @xor put together a project in AUM to test the accuracy of AU midi sequencers. Now @xor is not claiming that this is super scientific in any way but it is interesting to see the initial results. It may help developers hunt down where timing appears to be off.

    On the session I have saved I have the following AU sequencers (their note numbers at the front of their name):

    1 Atom2
    2 Snakebud = late (0011)
    3 Drambo
    4 Rozeta Cells
    5 Riffer = early (0992)
    6 Octachron
    36 EG Pulse = late (0011, 1003)
    44 DrumComputer
    48 Digistix

    In my testing it looks Snakebud and EG Pulse play late and Riffer plays before the beat (measured in milliseconds).

    Try it at home! You may have other sequencers or get different results.

    Thank you @xor for this cool utility.

    I recommend testing with different buffer sizes. It has come to light that some sequencers (and other midi apps) fire off events only when the audio buffer is processed. BlueVerk and a couple of others have documented this.

    So, it would be good to know for these sequencers if they are subject to this issue.

    Do you mean changing the buffer size in AUM?

  • @gusgranite said:

    @espiegel123 said:

    @gusgranite said:
    Our very helpful member @xor put together a project in AUM to test the accuracy of AU midi sequencers. Now @xor is not claiming that this is super scientific in any way but it is interesting to see the initial results. It may help developers hunt down where timing appears to be off.

    On the session I have saved I have the following AU sequencers (their note numbers at the front of their name):

    1 Atom2
    2 Snakebud = late (0011)
    3 Drambo
    4 Rozeta Cells
    5 Riffer = early (0992)
    6 Octachron
    36 EG Pulse = late (0011, 1003)
    44 DrumComputer
    48 Digistix

    In my testing it looks Snakebud and EG Pulse play late and Riffer plays before the beat (measured in milliseconds).

    Try it at home! You may have other sequencers or get different results.

    Thank you @xor for this cool utility.

    I recommend testing with different buffer sizes. It has come to light that some sequencers (and other midi apps) fire off events only when the audio buffer is processed. BlueVerk and a couple of others have documented this.

    So, it would be good to know for these sequencers if they are subject to this issue.

    Do you mean changing the buffer size in AUM?

    He does.

    An app isn’t likely to be sample accurate at one buffer size and not at others. A large buffer size will make the bad timing worse and easier to spot and a small buffer size will make it less noticeable. An app that has sample accurate timing will be just as solid at 64 byte buffers as 2048 byte buffers assuming the cpu can keep up.

  • @xor said:

    @gusgranite said:

    @espiegel123 said:

    @gusgranite said:
    Our very helpful member @xor put together a project in AUM to test the accuracy of AU midi sequencers. Now @xor is not claiming that this is super scientific in any way but it is interesting to see the initial results. It may help developers hunt down where timing appears to be off.

    On the session I have saved I have the following AU sequencers (their note numbers at the front of their name):

    1 Atom2
    2 Snakebud = late (0011)
    3 Drambo
    4 Rozeta Cells
    5 Riffer = early (0992)
    6 Octachron
    36 EG Pulse = late (0011, 1003)
    44 DrumComputer
    48 Digistix

    In my testing it looks Snakebud and EG Pulse play late and Riffer plays before the beat (measured in milliseconds).

    Try it at home! You may have other sequencers or get different results.

    Thank you @xor for this cool utility.

    I recommend testing with different buffer sizes. It has come to light that some sequencers (and other midi apps) fire off events only when the audio buffer is processed. BlueVerk and a couple of others have documented this.

    So, it would be good to know for these sequencers if they are subject to this issue.

    Do you mean changing the buffer size in AUM?

    He does.

    An app isn’t likely to be sample accurate at one buffer size and not at others. A large buffer size will make the bad timing worse and easier to spot and a small buffer size will make it less noticeable. An app that has sample accurate timing will be just as solid at 64 byte buffers as 2048 byte buffers assuming the cpu can keep up.

    Right. At the highest buffer size it appears to be the same apps but with larger gaps.

  • @BroCoast said:
    I got kind of obsessed about this at one point. All I remember is Rozeta/Bram is rock solid and Drambo is for the most part but some apps seem to drift after a couple of cycles when using Drambo as the host.

    I've seen Drambo throw the very occasional hissy fit (no plugins loaded) but not been able to pin it down. Digistix can have a wobble as well. The rest have been rock solid in my tests. I can't work out how to program Cykle and I don't own StepPolyArpUnit so maybe someone else will test those.

  • _ki_ki
    edited July 2021

    Hi @gusgranite, nice idea.

    I checked some more AU midi generators if they use sample-offset in MIDI Monitor. Here the complete list including the ones you already tested (in italics).

    With sample-offset

    • Aphelian
    • Atom
    • Atom 2
    • Autony
    • Cality
    • cycle
    • DigiKeys
    • DigiStix
    • Drambo
    • DrumComputer
    • Fugue Maschine
    • Ioniarics
    • LK (only for the note-on, the Note-Off don‘t use sample-offset)
    • midiGATE (tested with X0X input)
    • MiRack
    • Mozaic
    • Octachron
    • Poly 2 (only for the note-on, the Note-Off don‘t use sample-offset)
    • Pure Acid (used as midi sequencer loaded in midi slot)
    • QuanitChord (tested with X0X input)
    • Rozeta Arp
    • Rozeta Bassline
    • Rozeta Cells
    • Rozeta Collider
    • Rozeta Particles
    • Rozeta Rhythm
    • Rozeta X0X
    • StepPolyArp Unit
    • StreamByter

    Without sample-offset

    Midi generators that don‘t set the sample-offset will produce sync-issues.

    • ArpBud 2
    • Axon 2 (used as midi sequencer loaded in midi slot)
    • BeatHawk (used as midi sequencer loaded in midi slot)
    • ChordBud 2
    • EG Pulse
    • Hammerhead (used as midi sequencer loaded in midi slot)
    • Helium
    • KB-1 (for ARP feature)
    • MidiEcho (tested with X0X input)
    • Photon
    • Physicles Bouncy
    • Physicles Gravity
    • PlayBeat (sending to AUM destination, plugin doesn‘t offer direct midi out)
    • Riffer (sending to AUM destination, plugin doesn‘t offer direct midi out)
    • Ruismaker Noir (used as midi sequencer loaded in midi slot)
    • RhythmBud
    • SnakeBud
    • StepBud
  • @gusgranite said:

    @BroCoast said:
    I got kind of obsessed about this at one point. All I remember is Rozeta/Bram is rock solid and Drambo is for the most part but some apps seem to drift after a couple of cycles when using Drambo as the host.

    I've seen Drambo throw the very occasional hissy fit (no plugins loaded) but not been able to pin it down. Digistix can have a wobble as well. The rest have been rock solid in my tests. I can't work out how to program Cykle and I don't own StepPolyArpUnit so maybe someone else will test those.

    At least one of the preset kick samples in digisticks has a bit of silence at the beginning if I remember correctly.

  • @jolico said:

    @gusgranite said:

    @BroCoast said:
    I got kind of obsessed about this at one point. All I remember is Rozeta/Bram is rock solid and Drambo is for the most part but some apps seem to drift after a couple of cycles when using Drambo as the host.

    I've seen Drambo throw the very occasional hissy fit (no plugins loaded) but not been able to pin it down. Digistix can have a wobble as well. The rest have been rock solid in my tests. I can't work out how to program Cykle and I don't own StepPolyArpUnit so maybe someone else will test those.

    At least one of the preset kick samples in digisticks has a bit of silence at the beginning if I remember correctly.

    Isn’t this just midi out though?

  • @_ki said:
    Hi @gusgranite, nice idea.

    I checked some more AU midi generators if they use sample-offset in MIDI Monitor. Here the complete list including the ones you already tested (in italics).

    With sample-offset

    • Aphelian
    • Atom
    • Atom 2
    • Autony
    • Cality
    • cycle
    • DigiKeys
    • DigiStix
    • Drambo
    • DrumComputer
    • Fugue Maschine
    • Ioniarics
    • LK (only for the note-on, the Note-Off don‘t use sample-offset)
    • midiGATE (tested with X0X input)
    • MiRack
    • Mozaic
    • Octachron
    • Poly 2 (only for the note-on, the Note-Off don‘t use sample-offset)
    • Pure Acid (used as midi sequencer loaded in midi slot)
    • QuanitChord (tested with X0X input)
    • Rozeta Arp
    • Rozeta Bassline
    • Rozeta Cells
    • Rozeta Collider
    • Rozeta Particles
    • Rozeta Rhythm
    • Rozeta X0X
    • StepPolyArp Unit
    • StreamByter

    Without sample-offset

    Midi generators that don‘t set the sample-offset will produce sync-issues.

    • ArpBud 2
    • Axon 2 (used as midi sequencer loaded in midi slot)
    • BeatHawk (used as midi sequencer loaded in midi slot)
    • ChordBud 2
    • EG Pulse
    • Hammerhead (used as midi sequencer loaded in midi slot)
    • Helium
    • KB-1 (for ARP feature)
    • MidiEcho (tested with X0X input)
    • Photon
    • Physicles Bouncy
    • Physicles Gravity
    • PlayBeat (sending to AUM destination, plugin doesn‘t offer direct midi out)
    • Riffer (sending to AUM destination, plugin doesn‘t offer direct midi out)
    • Ruismaker Noir (used as midi sequencer loaded in midi slot)
    • RhythmBud
    • SnakeBud
    • StepBud

    Wow. Awesome work!

  • Interesting stuff, thanks for taking the time to compile these lists. I had been wondering if Helium had been changed to set sample offset when the no quantize option was added but clearly not.

  • OK, I have two questions, then:

    1. Does it really matter? Is it really noticeable in a bad way or is this the midi equivalent of super squeaky anti-aliasing arguments that have very little bearing on our audible reality?
    2. If it does matter, what do developers need to know?
  • 1) Imo it matters a lot. Both midi timing and anti-aliasing are very difficult to disregard once you’re able to pick it up / hear it. It’s a little bit like most producers on compression... First couple of years you overuse it because your ears not trained just yet to hear it, once you realise it you’ll join ‘anti-loudness war’ camp (unless there are bills to pay :))
    2) I think we need stronger standards... current shift should improve things, but it will cut both ways... some restrictions will help, others will create other difficulties.

  • @gusgranite said:

    @jolico said:

    @gusgranite said:

    @BroCoast said:
    I got kind of obsessed about this at one point. All I remember is Rozeta/Bram is rock solid and Drambo is for the most part but some apps seem to drift after a couple of cycles when using Drambo as the host.

    I've seen Drambo throw the very occasional hissy fit (no plugins loaded) but not been able to pin it down. Digistix can have a wobble as well. The rest have been rock solid in my tests. I can't work out how to program Cykle and I don't own StepPolyArpUnit so maybe someone else will test those.

    At least one of the preset kick samples in digisticks has a bit of silence at the beginning if I remember correctly.

    Isn’t this just midi out though?

    Should be, but it’s good to keep this in mind if someone wants to test with the internal sounds, also when triggering digisticks from another sequencer.

  • edited July 2021

    I'll double-check why HH and Noir are on the list. They should obviously be just as tight as all my other MIDI apps.

  • edited July 2021

    Interesting read, and great work @_ki !!

    I previously attempted to explain (visually) how plugins that do not use MIDI offset can have 'acceptable' timing at very low buffer settings, but as the buffer - and therefore block size - increases, the timing gets worse and worse.

    You can read it here:
    https://forum.audiob.us/discussion/comment/972988/#Comment_972988

    If you want to try this for yourself...
    1. pick any app that doesn't use MIDI offset (eg Helium or ANY of the 'bud' apps)
    2. sequence a continuous series of 16th notes
    3. Set the buffer to 2048
    4. Increase the tempo until you hear the timing fall apart (try 200bpm+)

  • _ki_ki
    edited July 2021

    @tk32 Your example setup using a no-sample-offset midi generator with large buffer and changing the tempo shows very well that the rhythm isn‘t kept by the plugin, the series of notes starts to stumble for higher tempi.

    .

    Another approach to show the problem is to emphase the non synchronous interplay.

    An example session contains a plugin able to play two short notes/clicks at the same time, regularly fed by two midi generators (one of them with sample-offset, the other without):

    • As sound generator use the free Plectrum AU with 75% feedback setting for short clicks
    • As sample-offset midi generator use Rozeta X0X with just a bass drum every beat. Attention: Disable the „Simulate 808 timing“ in the X0X midi setup dialog.
    • As comparison try Helium or StepBud (which both don‘t use sample-offset) playing a 1 bar loop with an 1/8th C#4 note on each beat. C#4 because X0X sends C#2 for its kick

    For 120bpm and 256 byte sample buffer this sound good - both clicks sound at the same time.
    But when switching to 2048 byte sample buffer, you‘ll hear double clicks/flams for several of the beats played

  • (when using X0X for such tests, make sure you disable "808 timing" which intentionally introcuces timing offsets...)

  • _ki_ki
    edited July 2021

    @brambos said:
    (when using X0X for such tests, make sure you disable "808 timing" which intentionally introcuces timing offsets...)

    Ohhhh - i hope i didn‘t shoot myself in the knee :#

    .

    .

    (Edit:) Luckily the ‚effect‘ is still audible with disabled „808 timing“.
    I‘ll update the above setup instructions

  • Updates for Noir and HH are on the way. MIDI output should be sample accurate now (MIDI input and internal sequencer already were)

  • @brambos said:
    Updates for Noir and HH are on the way. MIDI output should be sample accurate now (MIDI input and internal sequencer already were)

    Yeeeeah it's a Hot Hammerhead Summer, power is restored.

  • @brambos said:
    Updates for Noir and HH are on the way. MIDI output should be sample accurate now (MIDI input and internal sequencer already were)

    You rule! 🖖

  • Wow thanks for not only testing but sharing the results @gusgranite & @_ki

  • @brambos said:
    Updates for Noir and HH are on the way. MIDI output should be sample accurate now (MIDI input and internal sequencer already were)

    Oh heck yea.

  • 👍🏼 Thanks a lot for the quick updates - i just verified the fixed Noir timing :)

    I‘ll post an updated list after the Hammerhead update landed.

  • @_ki said:
    👍🏼 Thanks a lot for the quick updates - i just verified the fixed Noir timing :)

    I‘ll post an updated list after the Hammerhead update landed.

    Gave me an opportunity to refactor my MIDI Output code and make it reusable across all (future) apps. Win win! B)

  • @brambos said:

    Gave me an opportunity to refactor my MIDI Output code and make it reusable across all (future) apps. Win win! B)

    That code could likely do well as 'Open Source' so we'd finally get rid of the sloppy midi-timing in way, way too many apps to mention :sunglasses:

  • @Samu said:

    @brambos said:

    Gave me an opportunity to refactor my MIDI Output code and make it reusable across all (future) apps. Win win! B)

    That code could likely do well as 'Open Source' so we'd finally get rid of the sloppy midi-timing in way, way too many apps to mention :sunglasses:

    FWIW, the sequencer code for (sample accurate) MIDI output as used in cykle is on my Github: https://github.com/cornedriesprong/CPSequencer/

Sign In or Register to comment.