Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
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.
Comments
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.
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.
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.
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
Without sample-offset
Midi generators that don‘t set the sample-offset will produce sync-issues.
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?
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) 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.
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.
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.
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+)
@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):
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...)
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)
Yeeeeah it's a Hot Hammerhead Summer, power is restored.
You rule! 🖖
Wow thanks for not only testing but sharing the results @gusgranite & @_ki
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.
Gave me an opportunity to refactor my MIDI Output code and make it reusable across all (future) apps. Win win!
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
FWIW, the sequencer code for (sample accurate) MIDI output as used in cykle is on my Github: https://github.com/cornedriesprong/CPSequencer/