Powered by Squarespace
« Yamaha Visual Performer Demo | Main | Sonic Touch #16: PPG WaveGenerator »

MIDI Jitter on iOS

As more musicians start taking iOS seriously, the expectations for apps become increasingly serious too. A thread on KVR laments MIDI timing and jitter issues with apps. Kevin McCoy replied with a great video documenting his own struggles.

This guy has a lot of gear, he is used to trying to keep his timings and track delays tight in his rig, so it is worth hearing him out.



A damning example of iOS failing to live up to the needs of serious musicians! I immediately set out to do my own tests. I noticed he's using Animoog for iPhone on his iPad, so I started there. I had the same results at even 60 BPM with Animoog for iPhone.

The recorded notes should be on the lines, or at least consistently distant from the lines. These are all over the fucking place!

Update: I got in touch with Amos, Moog Product Development Specialist, and showed him this article. He is on the case!

That is some terrible jitter. I switched over to Animoog for iPad, running a similar patch, to compare results.

Much more consistent!

At this point I should probably detail my MIDI setup. From my PC I'm going out via USB to my keyboard, then out of my keyboard's secondary MIDI DINs, into an M-Audio Uno USB-MIDI adapter, into a camera connection kit, connected to the iPad. Far from ideal, this is a sloppy mess. Some amount of jitter is unavoidable with any external MIDI hardware, but these results from the iPad version of Animoog are something I think most people could live with. To test this further I did the same tests with Magellan and BassLine, both at 60, 120 and 160BPM.

Magellan for iPad

Finger's BassLine

Once again, excellent results from both! I was beginning to think the problem may be related iPhone apps running on iPads, so I tried another test with Sunrizer XS.

Everything looks good in Sunrizer XS too!

I'd be interested in hearing from other people and, if at all possible, similarly documented screenshots of recordings. It looks like this is just a bug with the iPhone version of Animoog, but that doesn't explain the issues experienced by the original thread author.

Reader Comments (32)

Not saying it is one way or the other, but that didn't look like a very conclusive test he is doing. Referring to it as an ios problem after testing just one app.(made for the iphone on an ipad)
Tim is on the right track toward a proper conclusion.

October 12, 2012 | Unregistered CommenterAnonymouse

I share the same frustration as Kevin McCoy has..My main controllers are both Korg pa-800 & M3 boards..Timing jitter has been problematic for quite a while now.Yes for pads and leads, no problem but start a drum pattern on I pad2, and it will never sync up fully via I-Rig interface w/ any of my Korgs, (which have great drum patterns). Slaving the korgs to say Thumjamb, the sync might last a lil longer than the reverse. Perhaps its the I-Rig interface? Its the only interface i own. What wont sync well : Alchemy, Garageband, Sampletank. Basically all pattern based apps..

October 12, 2012 | Unregistered CommenterChezzdog

doubt it's got much to do with ios (as the later tests showed). midi has always been lame. i used to record midi parts off sound modules triggered from cubase (before software instruments) into protools, and they were all over the place. usually about 20-30 ms off the grid, and not even consistently so. when time-stamping came along, it got better, but only if you were using compliant equipment.

October 12, 2012 | Unregistered Commenterswarmboy

Agree with vid, gave up with timing on iPad with Alchemy and all pattern based apps. A mess. Alessis io dock with latest firmware.

October 12, 2012 | Unregistered CommenterWoodsdenis

in the vid ableton and animoog were both set at 120bpm for the first sequence. in the second sequence only ableton was changed to 150 bpm...?
i've noticed in the past that ableton was unable to correctly read the bpm from imported ios loops...which apps i imported from, i don't recall. but, clearly there is a clock mismatch somewhere...perhaps in the different pulses per quarter note timing of the various apps.

October 12, 2012 | Unregistered Commentera1

p.s. for reference
http://www.sweetwater.com/expert-center/glossary/t--PPQN
and
http://home.roadrunner.com/~jgglatt/tech/midifile/ppqn.htm
my understanding is that they (ppqn) are not necessarily standardized between apps/programs...hence perhaps, the difference

October 12, 2012 | Unregistered Commentera1

A ha.. Rock solid ppqn is what's lacking in the protocol ..no reason sync should act as jittery as Michael j fox off his meds...

October 12, 2012 | Unregistered CommenterChezzdog

Thanks for the post, Tim. I did a similar test and posted my results back on the thread with images: http://bit.ly/RUlyKw

This clearly shows that it is not just one app, although results do vary somewhat across applications. I found PPG Wavegenerator to have the biggest latency and the worst jitter (although damn, it sounds great!)

Matching the BPM between the app and Ableton was irrelevant - no change in results. I am not worried about "syncing" LFOs and delays and such at this point, I'm talking about something much more fundamental: playing notes reasonably within time.

October 12, 2012 | Unregistered CommenterKevin McCoy

My best guess would be a buffer size issue with Animoog for iPhone. For an iOS audio engine, the individual buffers are usually 256, 512, or 1024 samples (at 44.1khz). This can insert a bit of delay between when a MIDI command is received, and when it's possible to start generating audio (plus, there seems to be at least one buffer worth of pipeline delay).

If Animoog is using the larger buffer size (which would lower the CPU demand), you'll get more jitter. Most apps shoot for 256 samples, but maybe Animoog is using larger chunks.

.... oooh. Just had an idea for a decent experiment. Be back in a bit....

October 12, 2012 | Unregistered CommenterFessaboy

Here's an interesting article someone linked to over on Reddit. This is a bit dated, but they did some extensive tests on clock stability. For the most part the results are great, I'm floored by how well WIST performed. There are some MIDI interfaces that just couldn't keep it together though!

http://www.innerclocksystems.com/New%20ICS%20iLitmus.html

October 12, 2012 | Registered CommenterTim Webb

I guess I don't see why the audio buffer size should impact jitter, unless it is doing something goofy like defining note length based on absolute buffer size... IE, sounds cannot begin or end mid-buffer. In this hypothetical and ridiculous scenario, you could only have note lengths of 256, 512, 768, 1024, etc. I say ridiculous, but you know what - if you look at my tests on the KVR post, you can see that it seems like the notes get further away from the beat in intervals and then reset to come back into time after 3 or 4 notes, which would suggest exactly this scenario. Goodness I hope that's not the case, or we are stuck...

Although that would theoretically explain why lower latency correlates with less deviation in timing...

A buffer is just a set of x samples, right? The values of the samples should be able to be freely arranged within the buffer.

What I'm trying to say is that buffer size shouldn't affect jitter unless there is something unique about the way that note on/off is handled in iOS. My buffer size in Ableton doesn't affect jitter with VST softsynths - the notes are just more or less consistently delayed by x milliseconds, and if you drag them back in time they will all line up more or less perfectly on the grid.

October 12, 2012 | Unregistered CommenterKevin McCoy

I was using drumbox sync'ed up to ableton via wifi midi and it was abysmal. hooking it up using a usb midi e-mu midi 1x1 through a 2x2 midiman got things much better ! but still not perfect for sure

October 13, 2012 | Unregistered Commenterbruno

Brainiac all you need to, I rather not sync or swim for a basic lock down on 4 on the floor, solid as a rock. That's why I won't bounce for a dollar app / nor a 20 dollar app until this basic timing issue is resolved. I'm not a DAW user. A hardware user only..our cocks might be old, yet we are steadfast & strong...

October 13, 2012 | Unregistered CommenterChezzdog

30 year old digital communications protocol fail. I'm ready for midihd already http://www.midi.org/aboutus/news/hd.php

October 13, 2012 | Unregistered CommenterWill

how does this play out with virtual midi?

October 13, 2012 | Unregistered CommenterRMG

SingleCell over on KVR hit the nail on the head, IMO. The way audio is processed on iOS is in buffers; chunks of 256/512/1024 samples (and possibly higher). If an app has the MIDI events in advance (sequenced track, or timestamped events sent ahead of time by something like WIST), there's complete freedom as to when to start and stop notes, and timing can be very tight.

For data that's sent live, though -- it's sort of like catching a bus. If a passenger shows up while the bus is at the station, he gets on. If the bus has already left, you've got to wait until the next one. (And this would apply to something like Audiobus -- I'm sure the team is thinking very carefully about the schedules for the buffers, so that everyone can get on at the same time, and the audio from different apps remains in sync.)

Smaller buffers get you lower wait times, because they come more frequently -- but this increases the CPU demand (which means fewer apps running at the same time, and less complicated patches and audio processing).

I'm poking around with some experiments -- running Genome to drive different apps with virtual MIDI, to check for lag. This should minimize any communication latency, and isolate what happens with audio buffer sizing. I'll probably tweak one of my development apps to have very large buffers, to see if that causes jitter behavior (I expect it will). With luck, I'll grind through that in the next few days.

October 13, 2012 | Unregistered CommenterFessaboy

The look ahead problem is one of the reasons Matt hasn't added midi to NanoStudio. It needs to be a bus stop (great analogy by the way) and it wasn't designed that way to begin with.

October 13, 2012 | Unregistered CommenterWill

Thanks for getting in touch with Amos from Moog. I will go wild with applause if someone can fix this. I also contacted Wolfgang, the designer of PPG Wavegenerator and he is promising improved interapp MIDI performance whenever the next update is out.

Right now interapp MIDI from say, littlemidi to Sunrizer, Animoog, or any other synth app is also rotten and sloppy.

Tim, I'd be interested to see your results in images for 120/160 bpm to see if there is a difference in CCK vs. iRig. I think the reason yours appear to line up nice is that you posted the 80 bpm images, no? I'll bet you would see similar results to mine if you upped the BPM to make the scale of sixteenth notes a little finer and the buffer-induced "bus stop" latency more apparent.

Will, that's an interesting point about Nanostudio. The in-app timing in Nanostudio is great. Whatever timing and note mechanisms are at work in Nanostudio, iMS-20, iElectribe, FunkBox, and others is great and doesn't "make the notes wait for the bus to come"... But only for notes generated within the app, it's a different story for input from other sequencer apps or external MIDI.

October 14, 2012 | Unregistered CommenterKevin McCoy

Sure! I'll be doing some more testing tomorrow with Virtual MIDI, so while I'm at it I'll redo the original tests at 160 to take some screens of those. I'm afraid I don't remember what BPM the article shots were at.

October 14, 2012 | Registered CommenterTim Webb

perhaps a way to differentiate between audio buffer problems and midi specific problems...plus, a jitter reduction feature (!?)
https://itunes.apple.com/us/app/midivision/id405828617?mt=8

October 15, 2012 | Unregistered Commentera1

Hmmm, I hadn't seen that MidiVision. I note that it is from the same guys that do MIDI Bridge and FreEWI. I'm not sure how running an app in middle of other apps would improve things, but that might be worth exploring.

I did a lot of testing this morning and will be reporting tomorrow with some conclusions, pictures and sound clips!

October 15, 2012 | Registered CommenterTim Webb

Tim -

All the combinations you tried delivered 'excellent results', except the stupid one - running an iPhone app in compatibility mode.

So why are you calling this "A damning example of iOS failing to live up to the needs of serious musicians!"?

October 15, 2012 | Unregistered Commenterstubbs

I have heard, but not tested, that Ableton Live 8 doesn't sync as well as earlier versions, so it "may" not be the best DAW for testing purposes.

October 15, 2012 | Unregistered CommenterScott M2

I'm not.... That video is from Kevin. I'm disputing it. With Science!

October 15, 2012 | Registered CommenterTim Webb

Stubbs: read the results of my test on KVR, in which I only use iPad native apps - still crap timing. Even if Tim says he is disputing me, we are all aiming for the same thing which is being able to use iOS apps as synth modules in a DAW environ with MIDI. We have several people reporting the same issues as me and only Tim saying that it was fine for him, so that's why I am interested to see his results at other BPMs where the problem would become more visible if it exists.

Scott M2 - this is not about sync, it is about note jitter. MIDI clock/sync and MIDI note on/off are different animals. You don't have to tell a synth what BPM you are going to be sending notes at to get it to play them in time, you just send the note message and it plays it. From Ableton to my MIDI interface is fine as I mention in the video - rock solid timing when I run MIDI out to my "real" hardware synths with the exact same setup.

So, for future reference - the problem is absolutely not Ableton (Tim's "good" results are Ableton too AFAIK). If it helps to clarify, I tried with internal iPad native MIDI apps, and a different sequencer on PC (Seq24) with the same lackluster results.

In summary, we have successfully diagnosed the problem as being either iRig, iOS, or individual apps - and I repeat, it is *not* only iPhone apps running on iPad that see this problem. Every single synth app I have experiences it to a less or greater degree, which appears to correlate to the size of the audio buffer requested by the app. Maybe I should make a video that is easier to understand :)

October 15, 2012 | Unregistered CommenterKevin McCoy

Dispute may have been a harsher word than I intended. I just wanted to distance myself from being the guy attributed to the video! There are some very heavy remarks in there, and I am disputing those more than Kevin personally. And yes, I use Ableton Live 8.

October 15, 2012 | Registered CommenterTim Webb

Another interesting reference:
http://www.soundonsound.com/sos/dec07/articles/cubasetech_1207.htm

See the section "Live MIDI Buffering Jitter" and the graphic there - guess this problem is *not* unique to iOS. A solution is likely to ask app developers to include an option to switch between two modes:

1: sound is generated with as little latency as possible at the expense of suffering from some jitter, the noticeable effects of will diminish with lower buffer sizes, hence incrementally smaller note shifting
2: an extra midi buffer is added up front so that note durations and placement are as consistent as possible (no jitter), but overall latency increases a bit (can be compensated for with track delay setting in DAW)

Right now I suspect we only have number 1.

October 16, 2012 | Unregistered CommenterKevin McCoy

Vince Clarke swore for a decade he'd never use midi because the timing just sucked compared to CV. This isn't an iOS specific issue.

http://www.gearslutz.com/board/electronic-music-instruments-electronic-music-production/395869-midi-timing.html

October 16, 2012 | Unregistered CommenterWill

if you have ever sequenced with an atari ...then rest of the midi world just suxxxxx ;)

October 16, 2012 | Unregistered Commenterbresk

I'm finding midi timing and playback on my first gen ipad to be fairly solid, I use it as a controller and sound module most of the time. I'll try a few tests though just to see, but I'm not getting anything as bad as the video, bpm's I use vary between 85-174. I'll test a few drum apps, as I mainly use them on the ipad and bounce a wav into my daw.

Using ipad 1, alesis iodock with usb midi into a mbp and audio into a saffire pro 24 dsp, firewire version, host is logic 9.1.7. Only jitter I encounter of late, happens with the metronome in magellan when I'm recording, can throw me at times. 

Funnily enough, one of the most solid midi timing platforms I've come across was the really old atari st/ste, I've kept both of mine and will one day dust them off and see if they work still, if they do set up a mini studio with just a sampler and synth.

October 16, 2012 | Unregistered Commentermister-rz

God damn it bresk, you beat me to it.

October 16, 2012 | Unregistered Commentermister-rz

Following up a bit here since I see my app MidiVision is mentioned wrt to jitter delay, so please accept this plug for my app for what it is. MidiBridge has the same feature except the user can specify the latency to add in milliseconds.

It is especially useful when driving an app from a physical port since events are timestamped (usually) by the physical device. MidiBridge (and MidiVision with a fixed delay) will then look at the timestamp of the message and schedule it into the future so the receiving app gets it when it should relatively speaking. I find this to be very useful when driving from a sequencer as it smooths things out at the expense of a little latency but in this case it doesn't matter.

I guess this is Kevin's 'mode 2' above

October 16, 2012 | Unregistered Commenteraudeonic
Comments for this entry have been disabled. Additional comments may not be added to this entry at this time.