BomeBox MIDI Jitter

So I've been trying to narrow down the source of jitter, sometimes massively unacceptable levels (read: unplayable) in my rig after the introduction of a new sequencer. (You might think it's the new sequencer, but it was always there - I just compensated.  Now I'm running parallel sequencers and really need to get this to work.)

I'm still trying to narrow things down, so please bear with me.

[Sequencer (Sync Master)]->[Parallel Sequencer (Sync Slave)] *ie No BomeBox

Rock freakin solid. No jitter that I can detect (info gleaned from watching Tempo on the receiving sequencer - no software measuring)

[Sequencer (Sync Master)]->BomeBoxDIN->[Parallel Sequencer (Sync Slave)]  Some Jitter

[Sequencer (Sync Master)]->MIDISport 4x4 ->BomeBoxUSB->MIDISport (different channel)->[Parallel Seq] Yields massive jitter.

Plugging anything else into the MIDISport and creating separate routes yields completely wild miscommunication that is too severe to be called "jitter", but chances are it's basically just that. (Although SequencerStop messages don't seem to get thru.  heh)

I've been trying to narrow down the culprits, and although it's looking like the MIDISport is a likely suspect, it seems anything USB via the BomeBox is a bust. The BomeBox itself isn't looking too innocent.  I had a USB Hub in there, but in trying to deal with this issue I first took that out of the mix.

What do you think I'm overlooking? Should I go with a better USB MIDI Interface? Right now, I only have two major streams of data that need to be processed via MTPro scripts, so theoretically I could just get a second BomeBox to process the second stream, and only use the BomeBox DIN connections, which seem the most resilient.  Unfortunately those streams communicate between the two sequencers (different data - I can detail that for edification in case anyone wants to delve into the setup, but using Thru boxes and Mergers to narrow the In/Out data scares the heck out me because: reasons)

Or am I, as an old person, shaking my fist at the USB MIDI kids to get off my lawn? (read: completely misinterpreting what the abilities are)

Wouldn't it be sexy if there was a BomeBox that was 8x8 MIDI DIN?  Routing and complex scripting!  Or do I just miss my JLCooper MSB+ Rev2 like the good ol'days?

Hi, thank you for the report — and my sympathy for the annoyance!

We have done extensive latency and jitter tests, and while USB is inherently worse than MIDI-DIN (due to its 1ms-scheduling), it stays +/- 1 millisecond.

Also, we have never observed miscommunication when using multi-DIN interfaces! Jitter is bad enough, missing messages is an absolute show stopper (literally).

However, as you pointed out, your tests cannot really tell us the culprit. I don’t fully understand your setup for detecting jitter, and what “massive” jitter means (in milliseconds). It also depends a lot on how much other MIDI data you’re streaming over the wire, and what kind of messages.

Which firmware version of the BomeBox are you using? Which devices/software are exactly the Sequencer and the Parallel Sequencer?

Would you mind doing some more tests for us to narrow down the problem?
1) Use the MIDISport only on Sync Master side, and BomeBox DIN OUT for Parallel Seq
2) Use the MIDISport only on Parallel Seq side, and BomeBox DIN IN for Sync Master
3) Use different ports on MIDISport: Sync Master on MIDI IN 1, Parallel Seq on MIDI OUT 2
4) if you can at all, borrow a different USB to MIDI DIN adapter and try with it.
4) try with a hub

Selectively remove one or more options out of the MIDI signal path:
1) run your setup with only timing messages, no other MIDI data (if that still allows you to evaluate jitter)
2) no MIDI Translator project, just plain MIDI router
3) any other simplification you can think of

We will also do some new tests how our MIDISport 4×4 “behaves”.

Thanks a lot!
Florian

Such an immediate response.
Florian: most Forum based Support systems require extreme patience. Honestly, I’m still waiting to hear about an issue I posted before this on another forum – and yet you answer in hours! Thank you!

I’m going to run through the scenarios today.

If acceptable, I’m using a variety of tempos from 80-160bpm and just watching what the receiving units want to set themselves at when set to Sync Slave.

“Rock Freakin Solid” = Usually exactly correct, with some variation upon changing tempos, and maybe a minor variation of .1bpm within the first few bars.

“Some Jitter” = Usually correct bpm, but wavering +/- .1bpm

I think I was experiencing at least one scenario where the bpm would vary at least +/- 1 (not point one) bpm, which is noticeable (I think…?)

“Massive Jitter” is greater than this, and noticeable.

“Wild miscommunication” is usually that receiving devices never receive SequencerOff.

I’ve been running these tests with either no Translator Project, or one simple Translator Project with no rules: just input, variables, outputting a slightly different MIDI Message. Routing is done in the BomeBox [MIDI Routes] section (and not done with Presets)

Primary Sequencer: Squarp Pyramid
Secondary Sequencer: Elektron Octatrack
Alternate Receiving Synth: EMu XL1 (rompler), EMu Orbit V2 (rompler); both using Beats/SuperBeats mode alternating with just triggering a kick drum patch triggered by MIDI Note On from Pyramid
*Note: Orbit V2 has a bit of a more resilient OS but doesn’t not indicate the Ext MIDI Tempo, but using the Beats mode can listen for jitter issues.

Will construct a .doc for the testing scenarios you mentioned.

(You answered me so quickly I felt bad not following up ASAP, but my weekend was scheduled for non-music stuff)

I spent a lot of time formatting my results, and for some reasons [TAB] doesn’t work on this visual editor, so I’m attaching a PDF. Hopefully this is readable.

Firmware: 1.2.1 (MT-BBOX10-0101-19973)

I spent a lot of time formatting my results, and for some reasons [TAB] doesn’t work on this visual editor, so I’m attaching a PDF. Hopefully this is readable.

Firmware: 1.2.1 (MT-BBOX10-0101-19973)

Thank you for the thorough tests. Comparing the 4×4 with the UM-ONE indicates to me that the 4×4 is the culprit, in particular when using its MIDI IN. Those weird delays for START and STOP also only happened when using a MIDI IN of the MIDISport. Whoops.
The simple answer to me is: replace the MIDISport 4×4 (or get it fixed). I’m interested to measure our MIDISport, but will take some days before I can get to it. However, the level of jitter still seems too high to me, but I need to look at this from a more “scientific” point of view. Will come.

Not sure what’s happening when playing to the Emu using BomeBox DIN to BomeBox DIN. It cannot be worse than using USB, and with the Octatrack it is (relatively) stable.

I’ll follow up with some more calculations.

Thank you for your quick responses and patience! 🙂

The 4×4 is definitely a culprit, but the UM-ONE is not without it’s issues. Even going DIN/DIN I was getting variations of -.3 to +.3, or .6BPM which is noticeable. Isn’t that something like a 288ms variation?

Plus, this is a more ‘sterile’ environment: I don’t even have any data or Translators running, let alone using a USB Hub.

What is a reasonable expectation with regards to jitter should I have?
And is my assumption correct that actually adding data into that stream and Translators will increase this?

The scientist in me needs to look get some more hard data than observing a tempo display. Let’s see how much I can gather…

How much can we trust the results?
In general, looking at a display and manually counting and writing down what you see is error prone and is not suitable for long-term tests to really get meaningful statistics. Maybe you’ve observed those 5 outliers that randomly happen once per hour on average?
On the other hand, the test result with a direct connection from A to B (without BomeBox) was rock solid, so we know that the BomeBox does add jitter.

Why does the BomeBox add jitter at all?
The BomeBox is highly optimized for fast throughput (it uses a chip set usually found in network routers). But because it also does a lot (e.g. the entire MIDI Translator Pro translation engine), it requires an operating system “under the hood”. We use embedded Linux, tuned for realtime operation. But still, using an OS will always cause a little jitter, because the OS will switch tasks on its own terms.

Our own, informal, latency tests indicated +/-30us jitter on MIDI-DIN with standard deviation 20us (us=microsecond) for the time it takes from sending a byte into the BomeBox DIN IN and getting it back on the DIN OUT port (loopback testing). We were very happy with that result — note that MIDI DIN inherently sends the MIDI stream at a rate of 320us per byte. Also compare to USB with +/-500us jitter each direction.

Now, how much jitter, in microseconds, have you observed with those tempo changes?
I.e. we need to calculate the tempo differences in terms of jitter of the MIDI messages.
The MIDI Timing Clock message is sent 24 times per beat. Doing the math, the clock messages are sent every 2,500,000/tempo_in_bpm microseconds. So at tempo 80, the clock message is sent every 31250us. A .1 deviation yields 39us difference (tempo 80.1bpm –> 31211us). Given that we have observed +/-30us jitter, a 0.1 tempo jitter is, unfortunately, expected. I would have expected more tempo jitter at tempo 160, though.

In conclusion, though, 0.1bpm jitter at tempo 80 is expected when using the BomeBox DIN ports. I would still hope that we can improve BomeBox timing with a future firmware upgrade.

PS: I am puzzled about the low jitter of the UM-ONE. Maybe my math is not correct? Usually, USB Input is polled once per millisecond, hence +/-500us jitter. With that, you should much heavier jitter in bpm (in the range of +/-1.5bpm) at 80bpm.

USB-MIDI is bad, but if my calculations (in my other response) are not entirely wrong, 0.3bpm difference is just +/-116us per MIDI Timing clock message.

Also note that jitter from a stable clock will not change the average tempo. It’s just that the tempo oscillates a bit, with center at the actual tempo from the source. From my musical experience, I doubt that you can hear such quick tempo differences of +/-1bpm, but then I have never run, say, a rhythmic drum track with an oscillating tempo with +/-1bpm. On Windows, many sequencers operate on a 1ms resolution, which gives +/-1.5bpm jitter at 80bpm! I guess, it also depends on how quick the receiver changes the tempo if the incoming timing clock messages jitter. My take is that some averaging should occur.

And yes, unfortunately, adding (a lot of) MIDI data to the stream will add jitter to the Timing Clock messages. But, again, they will always recover eventually (and not drift).

maybe the good performance of the USB-ONE can be explained by some averaging occurring in the receiving sequencer, and because USB has very regular jitter?

I swear I must come up with these bizarre configurations and subsequent problems just because I like learning stuff!

I’m going to have to digest that big post. heh heh

I’m totes fine with .1BPM variations, and even more. But if I can actually get a bead on where it’s coming from, I can adjust on other sides with workarounds. I started this thread when I was experiencing the bizarre “many beats behind” scenarios of using the 4×4 INs. Since then I have been trying to draw a MIDI Routing diagram that will get my data in/out of the BomeBox with the least amount of jitter.

But I can deal if I can isolate and get an idea where it’s coming from and/or how much to expect. It still seems kind of random to me. I know how much I should expect, now. This is many steps forward for me.

As for sciencey measuring the jitter: Is there a box I can just stick in the chain that would log the MIDI data – no processor overhead, but just log the data to a .txt file or even dump it onto a screen? I mean, I can always pump the data into the laptop and use MIDIOx or something, but then that introduces a new source of possible jitter.

THANK YOU for doing the math for me! I get confused when changing BPM and converting to ms.

This is indeed observed behaviour, but please keep in mind that when I would note that the variations would occur x times per y measures, it wasn’t just running for 16measures. I would be running each test for probably a minute or two, at first justing watching how fast it changed to get an indicator of how much writing I’d have to do, then I would watch it for awhile to note the variation, then I would count the variations as a separate exercise. Definitely not scientific. Sorry.

And of course at [Sequencer Start] there is initial tempo fluctuation. This data was discarded.

The fluctuations in Tempo in the most glaring examples occured every measure for periods of time.

Note: Going [SQRP]->[DIN];[UMONE]->[OT] at 80BPM the fluctuation was -.2/+1.1BPM, which is a variation of 1.3BPM, which is in your expected range, no? And yes: the other way around was more stable and less-than-expected jitter. Once again, I didn’t take initial data, but let the sequencer run for a bit before making my observations. Got any housekeeping routines in that BomeBox firmware that’s cleaning anything up from the USB input side or something or did I just get lucky in that sample?

I am truly excited about your prompt responses, and the major amounts of information. I like learning stuff, even if there are things I need to re-learn because I’m old and forgetful. 🙂

I think I’m going to have to keep the following in mind, pls correct me if I’m making incorrect assumptions:
– BomeBox DIN will be my primary connection, because of both observed data and personal superstition
– I may also use an UM-ONE to get a second data path thru the Translator however I may just add another BomeBox
– I’m going to fantasize about an 8×8 Rackmountable BomeBox MIDI Router/Translator SuperToy
– If the DIN connections still seem the most stable down the road, I might just buy another Box to deal with the data coming the other way; it’s about the same price as trying another USB MIDI Interface
– I set up this configuration because originally I had the OT as Sync Master, but experienced jitter. This was also before this whole hullabaloo, so I’m wondering what configuration I dismissed. I think I can test a workaround so I only have one data path that requires the BomeBox, but I’ll miss the option for realtime routing. (Via the BomeBox, I can turn channels on and off on the EMu Romplers via SysEx…and each of them is 16 channel multi-timbral, so my layering options aren’t avail in that config. I might be able to workaround by editing my patches and dedicating more voices to each patch and moving some patches around)

I’ve only had the Pyramid for a little more than a week and I’m still using pen&paper to visualize my MIDI Routings before updating my scripts & sequences.

The funnier part is that I usually program my sequences with randomisations to try to make them seem less ‘regular’. Really: this question didn’t start because of 1bpm, and I can’t hear variations that low unless, as you noted, it’s a rhythmic track. The initial hardware configuration included a USB Hub (DLink 7 port powered) into the Box with the 4×4 connected to the romplers, 2xUMONEs (Pyramid & OT), a Nektar Controller, and a Prophet 12. I think it’s safe to assume that this, although theoretically delicious, is unmanageable.

well thanks for the understanding! I don’t doubt your observations, but some numbers just don’t match theory. For example, given that jitter stays in the same ballpark (for microseconds), then the jitter in bpm should be higher at higher bpm’s. Also, it cannot be that the negative jitter is less than the positive jitter (on average), because you cannot bend time (if you found out how, please let me know!).
But all in all, it’s a good exercise! Maybe also something like the E-RM devices (friends of Bome) could help you:
https://www.e-rm.de/
But even the smaller E-RM device retails for just a little less than the BomeBox, so maybe using a second BomeBox for the return path is more attractive in your scenario.

And also, maybe you can configure the Octatrack’s averaging for incoming tempo detection?

Feel free to doubt my observations and make suggestions! I admittedly overlook sometimes the most obvious things.

Such as, as I noted before, I just tried sync’ing everything the other way: with the OT as Master and the Pyramid as Slave via the BomeBox DIN only (no Translator).

Rock solid, with maybe a .1-.2BPM variation.

I dismissed this configuration awhile ago because I’m superstitious against the OT, although mine was made before they started having their current…um…’hardware and OS issues’ (and I’m running one of the more resilient OS)

I have to rethink this config, because the translated OT CC data needs to be merged with Note data from the Pyramid and I’ve been at this too long today for my brain to function.

as for equal positive/negative jitter values: wouldn’t that average out over the long run if it is a regular type of ‘thing’ that is affecting the timing? I think I failed to mention that in some of the tests, the most extreme values displayed less often – my observations are definitely NOT an average. It could be possible that extreme values in the one direction might be for several sequential clock ticks and thereby trigger a tempo change on the receiving unit, whereas the same values in the other direction (positive v negating) might be individual clock ticks which would not be recognised by the receiving device, but if an accurate measurement were made of each specific clock value, it would average out…?

Isn’t like almost 3am in Germany?

Configure OT averaging for incoming tempo detection: LOLOLOLOL
Wait…there’s like a bazillion things it does that I don’t use…maybe? (but probably not)

Just to add someone else’s unscientific subjective experience to this thread – I had similar issues, at that time using a midisport 2×2 anniversary edition, and a roland um-1.

If I used my korg electribe emx, plugged in via the midisport to send clock data to a nord lead 3 using the roland um-1, it was basically pointless. Similarly to the OP, I experienced either midi jitter, or possibly lost timing messages(?!) resulting in an unstable clock as far as the nord was concerned. I was also sending this from the nord’s midi thru port, into a tempo-synced delay. This was unusable. The tempo readout from the nord was more erratic than any jitter i’ve ever been presented with should have caused.

So, I read this thread, switched round the midisport 2×2 with the roland um-1, so the emx was sending clock via the um-1, and it was being forwarded to the nord via the midisport…

Et voila. No more problem.

This was being done all via a d-link 7-port usb hub, connected to a bomebox which was running no translators.

Hi Pete,
that’s a very interesting observation! If I may recapitulate to see if I get it right (ignoring the USB hub for now)?

Scenario 1: “Jitter”
EMX MIDI OUT -> MIDISport MIDI IN -> BomeBox -> UM-1 OUT -> Nord

Scenario 2: “No/Less Jitter”
EMX MIDI OUT -> UM-1 IN -> BomeBox -> MIDISport MIDI OUT -> Nord

Now this looks like either the UM-1 being jittery on the OUT port, or the MIDISport jittery on the IN port (or both). Assuming you’ve used the same USB ports. I cannot say what or if the BomeBox has any influence here.

Would be interesting to find out how it works if you only use one MIDI interface?
A) EMX MIDI OUT -> MIDISport MIDI IN -> BomeBox -> MIDISport MIDI OUT -> Nord
B) EMX MIDI OUT -> UM-1 IN -> BomeBox -> UM-1 OUT -> Nord

(you’ll need to add a corresponding loopback route in the BOmeBox web config for that to work)

But it’s good to know that sometimes exchanging USB-MIDI interfaces can make a big difference.

Thanks for reporting!

I was intrigued and did some more extensive latency/jitter tests. It turns out that there are systematic timing differences for USB INPUT vs. USB OUTPUT.
For USB INPUT, all our tested USB/MIDI-DIN interfaces have approx. 1ms average latency and +/-0.5ms jitter (as expected).
For USB OUTPUT, average latency and jitter is much lower. Some devices had an occasional 10ms delay (once every 2 minutes, but not if USB INPUT and OUTPUT were both used). With other ones such as the ESI M4U XT 4×4, I have not witnessed such occasional outliers.

Interesting to note is that the M-Audio MIDIMan MIDISport 4×4 Anniversary Edition has consistently more latency and jitter than all other tested interfaces (by approx.200us), but still OK for performance.

These tests are somewhat artificial — results can be different if you’re using more USB devices and/or running higher MIDI traffic. That’s why I don’t publish concrete numbers and the whole list of tested devices.

Florian: Thanks for the followup.
I gave up, honestly. Apologies that I didn’t followup and let this issue just die in some morbid hellhole of shattered glass with the broken remains of my MIDISport lying panting for its final breath listening to the expressions of my abject rage before fading into oblivion.

The issues with Jitter are to get realtime playing IN to my sequencer, which is a situation that noticeable Jitter causes me anxiety…because once mis-timing issues are introduced at the beginning of a project, they become unrecoverable with any reasonable doses of anti-anxiety medications (quantising? Pshaw!).

I’ve simplified my rig until such time as I invest in a (better) different USB MIDI Interface (or at least one that is supported by their own manufacturer) or if I want to invest in a second BomeBox to handle a different data stream. I’ll scope the Forums to see if you list the Interfaces you’ve tested, but I’ll note the ESI M4U with a hope that someone has mentioned the MIDITech devices also.

I’m also still not comfortable with USB MIDI. [Old man yells: “Keep it DIN and git offa mah lawn!”]

(Yes, I’m back whoring here on the forums trying to resolve a new project!)

The good parts: Once I re-did the rig and put the Box in a different place for a simplified purpose, I forgot all about it – it just did its thing and I didn’t even think about it again until lately since I want to try something new/different with a different data stream. heh Kind of a let down to use the Box ONLY to translate data from my sequencer (Pyramid) to the Octatrack (and not some full-fledged MIDI Router), but that’s worth the price of admission for me right now.

For now, I’m still just tickled that the Box is a major value for what I’m having it do AND ESPECIALLY the support y’all give! (Seriously, the best support. Period.)