Omniclock (MIDI sync Plugin)

Some research before the OXI arrives, so this may need confirming on the unit — but unless I’m reading it wrong:

The OXI One presents 2 ports over USB (its A/B banks), not 3 — and that seems to hold for the MkII too. The higher “6 port / up to 96 channel” figure is only with the OXI Split 2 attached, and that’s a breakout fanning the One’s multiplexed (not fully discrete) TRS MIDI output into more physical DIN/TRS sockets — added hardware MIDI outputs. The Hapax presents 16 virtual lanes on its USB Device port.

So the question of how they appears to the GridLock II might be a non-question.

Unless I’m missing something, I wouldn’t connect the OXI to the GridLock II USB host ports at all — I can’t see the point.

From basic reading I’d connect a 5-pin MIDI clock output from the GridLock II to the 5-pin input on the OXI and slave it to incoming MIDI clock, then connect the OXI’s USB straight to the PC/Mac so its virtual lanes appear to the DAW directly (bidirectional, but you’d use them as inputs here). That keeps timing on the hardware DIN path and the note/CC data on USB to the computer.

That’s the OXI-over-USB workflow as I understand it: the internal MIDI sequences routed over USB as separate virtual lanes to the Mac/PC, so you can trigger soft synths — bank A to one instrument, bank B to another. The OXI really just needs a good external clock, right?

Again — apologies if I’m missing something.

No the Oxi one shows 3 channels -A B C. I will double check tomorrow

1 Like

Three Ports on Oxi MKII (48 MIDI channels) which relate to A B C on the Oxi

I only really use it for sequencing hardware hence why I was wondering if it could show up in the Gridlock II for sequencing hardware (also Hapax)

1 Like

Correct - confirmed when OXI One mk2 is connected via USB to an H12MIDI Pro as well.

Just playing with the Cirklon to check the concept. Virtual lanes appear as both input and output to the DAW via direct USB connection to the Mac (same as the OXI and Hapax, I assume). With GridLock II in the system, this direct connection lets me use the Cirklon / OXI / Hapax (clocked via 5-pin from the GridLock) as DAW inputs already, capture or route that data, then send it back out to any hardware via the GridLock’s TX ports — which is where the precision event timing is delivered.

What I mean is — I’m not seeing any advantage to connecting the Cirklon / OXI / Hapax via USB directly to the GridLock II, when you can already access the sequencing data as DAW track inputs via the direct connection.

In your screen I can see the Waldorf Iridium as a MIDI destination — if that’s connected USB-direct to the Mac, that’s the one thing I’d change: drop the Iridium’s direct USB and run it off the GridLock’s 5-pin TX instead, so it picks up the precision timing.

1 Like

In this screen you can see I’ve created two hardware “instruments” in GridLock II — Iridium and Sequential Pro 3 — both receiving their data from GridLock, not via the standard DAW-USB signal path.

These can still receive live/thru performance data in real time from the Cirklon / OXI / Hapax when it’s slaved to the DAW — but that real-time thru data will only be as tight as the Cirklon / OXI / Hapax are capable of generating it internally, then getting it to the DAW inputs via that USB path.

So if you’re round-tripping live thru sequenced data back out to the Iridium via USB-direct, you’re stacking USB wobble on both legs — once getting into the DAW, again getting back out. Running the Iridium off GridLock’s TX cleans up the output leg, since it’s corrected before it leaves the TX port. The live input leg to the DAW is still only as tight as the sequencer’s own USB path — GridLock can’t correct sloppy input on the fly — but at least you’re not adding a second helping of source / macOS USB jitter on the way out.

And in practice the input wobble doesn’t really matter: you capture the hardware sequencer’s part, quantise it in the DAW if it’s rubbery, and from then on it plays back out through GridLock’s TX with the timing cleaned up on the way in and the precision delivered on the way out. The only time the sequencer’s internal USB jitter and any added macOS USB jitter actually reaches your hardware is real-time live thru. Slave the Cirklon properly. Capture sequence data. Quantise. Out via GridLock to Iridium etc.

Again — a million ways to run a studio. This is only how I would do this. Let me know if I’m missing something.

Blockquote

I only really use it for sequencing hardware hence why I was wondering if it could show up in the Gridlock II for sequencing hardware (also Hapax)

Blockquote

Again — help me understand better if you can. The Cirklon already has 5 x 5-pin MIDI outs with low jitter, which is exactly why people love it. If I’m driving hardware from a Cirklon I’d use those ports directly — that’s the best performance you’ll get. The USB lanes into the Mac as inputs are great for triggering soft synths, where the data has to reach the computer anyway. But using the Mac/PC as a router to send it back out to hardware sort of defeats the whole reason for having a Cirklon in the first place, right? You’d be taking its tight direct output and pushing it through a messy USB round-trip to get to the same synths it could drive directly.

Same goes for the OXI / Hapax — if the end goal is sequencing hardware, the sequencer’s own DIN out, clocked tight by the GridLock, is almost always the better path than a USB round-trip. The GridLock’s job is keeping that sequencer locked, not being the thing you route the sequencer data through.

PS: Just had a thought — is it because the OXI / Hapax have limited direct 5-pin outs? The Cirklon has 5 DINs so you’d never need USB to reach hardware — but if the OXI/Hapax are short on physical outs, then using their virtual USB lanes to get to the DAW and routing back out to hardware (via USB direct to the receiving devices, or via a MIOxl or equivalent) makes sense from a connection-count point of view — but you’re going to be a long way from what those direct 5-pin MIDI outs (only referring to the Cirklon, as I haven’t checked the OXI/Hapax jitter specs) can deliver.

And the Iridium isnt a cheap box - it deserves better than that !!! :slight_smile:

Addendum:

Morbid curiosity, but an interesting test all the same, as it shows the contrast between the Cirklon’s discrete 5-pin DIN ports and two outgoing USB lanes converted directly via a CME H4MIDI WC — so no Mac/PC/DAW in the signal path at all.

Cirklon — Internal Sync / Master, 100.0 BPM 7 × identical tracks, 16th steps, all active Direct 5-pin DIN outs 1 through 5 USB outs 1 and 2 → CME H4MIDI WC DIN out 1 and 2.

Same sequencer, same data — the only variable is the output path.

The Cirklon’s native 5-pin DIN is roughly 31× tighter on jitter and push-pull than its own USB output hosted and converted back to DIN via CME H4MIDI WC, and holds inter-port skew to 66–129 µs versus ~1600 µs on the USB path — so the ports also stay far better aligned with each other. This measures the whole USB output path as a single chain — the Cirklon’s USB-MIDI output plus the CME’s hosting and conversion.

4 Likes

Yes you guessed correctly the main reason I asked was due to the limited number of physical MIDI outs however with some planning I don’t think that is too big a deal as I have both sequencers hooked up and the Hapax has 3 MIDI out.

Noted on the main importance being clock in and not the actual sequencer data which of course makes sense. I guess I was thinking mainly along the lines of a USB cable doing everything for convenience but clearly analogue clock always wins as shown in your Cirklon test data - very interesting to see the DIN vs USB performance which is quite considerable!!! Many thanks for providing this test.

If the Gridlock sent Clock out to the hardware directly instead of the Cirklon (use it for sequencer data only) would that be even tighter? Just a thought out of curiosity despite Cirklon being very tight as is! Cheers!

Great question — usually, though not always, externally syncing any hardware drum machine or sequencer introduces some degradation in tempo stability. How little or how much comes down entirely to the device’s design and the priority its sync engine is given.

For that reason alone it’s important to feed the hardware the most stable external tempo-sync you can — it gives any device the best possible conditions to hit its own optimum performance.

And to be clear, none of this is about good versus bad.

The point of putting real wire-level numbers on the table is so broad claims like “hardware-grade sync” without the hardware can be weighed against what actually comes out the other end. The data just differentiates the claim from the reality — everyone can then decide what their own setup needs with confidence.

Again — I’m not grifting for sales and I’m not trolling; the price difference alone should make that clear. After 35 years in this game, with so much misinformation online these days, sometimes it’s worth showing more detail and less spin. If this is too much - let me know.

Both sets of today’s test results are MIDI clock generated from Ableton Live on an identical system — only the output path differs.

Mac Studio M4 Max | Sequoia | Ableton Live 12.4.1 | 100.00 BPM | MIDI Clock out — 24 PPQ

Table 1 — Omniclock × 8 → mioXL → 8 × 5-pin DIN → Analyser
Table 2 — GridLock II → 12 × 5-pin DIN → Analyser

3 Likes

1 Like

3 Likes

@ innerclock

Are you able to me decipher whats going on with instant start?

Interesting comparison. Do you have a table that showsresults for Ableton on that same system without Omniclock or GridLock II?

You mean the MIOxl ???

So even using the mioxl to route the clock from the inner clock, still impacts the timing that much?

But would you even need a mioxl if you had the gridlock ? Or can the gridlock route midi the same as the mioxl does?

Believe it would also replace MioXL as has similar routing capabilities

It’s a little disappointing to see a thread that was started specifically to discuss Omniclock gradually become a vehicle for demonstrating the value proposition of a competing product.

We have no issue whatsoever with people measuring timing performance. In fact, we welcome it. Timing matters, and objective measurements are useful. What seems odd is using an Omniclock thread primarily to reinforce why a hardware solution costing roughly 50x more is supposedly justified, rather than evaluating Omniclock on its own merits and intended use case.

The interesting thing is that the measurements being presented actually reinforce one of the points we’ve made from the beginning: there is a critical difference between theoretical maximum timing precision and musically meaningful timing precision.

To put this into context, we’re sharing measurements from an original Roland TR-909, arguably one of the most important drum machines ever made and a benchmark sound source for house and techno music.

What These Results Show

The key takeaway is that one of the most iconic and influential rhythm machines ever produced exhibits timing movement measured in milliseconds, not microseconds. (This is the same for almost every other legendary drum machine/sampler)

The TR-909 recording shows:

  • Up to 5.175 ms peak-to-peak timing variation in straight mode.
  • Up to 5.227 ms peak-to-peak variation with swing enabled.
  • Repeated excursions of several milliseconds from nominal timing.

Yet nobody would seriously argue that the TR-909 fails musically because of this. In fact, entire genres were built on it.

If Omniclock—at its most extreme—exhibits timing characteristics that are still roughly twice as tight as the natural jitter of a benchmark TR-909, then from a practical musical perspective it is already matching or exceeding the timing stability of the very hardware machines that define the sound of electronic music. Producers have happily used these classic instruments for decades precisely because those slight variations are part of a usable musical result.

Our position has never been that timing accuracy is irrelevant. Our position is that there is a point where further improvements become increasingly difficult to perceive in real-world musical situations.

Some users absolutely want the maximum measurable precision available and are happy to pay for it. That’s entirely valid. But the data from the TR-909 suggests that great musical results have never depended on achieving timing accuracy down to the microsecond level.

Our goal with Omniclock has never been to win a race for the smallest possible number on a graph. It’s to provide stable, reliable synchronization that exceeds the timing consistency of the instruments people actually use to make music.

Our focus remains on giving musicians a practical, affordable tool that solves real synchronization problems and lets them get on with making music.

8 Likes

Yes, that would demonstrate the difference OmniClock makes, right? At least on that specific interface, but I can’t I say whether or not that is a particularly stable and tight interface.

I think it’s fair. We are inundated with vibe coded apps and plugins now. Who knows what will be relevant in software in 8-12 months. Yes it is a lot less expensive for software but bad plugin purchases add up greatly over time.

The gridlock is F’n expensive and for that reason I probably won’t be able to get one anytime soon, but if you build your studio around a timing clock it has to be rock solid and updated for years and years. Innerclock has delivered on that.

Maybe a Mod can chuck the Innerclock Gridlock II info into its own thread? Lots of great information and both products deserve its own thread. Shall I open one to make the mods life easier?

Edit: made its own thread

4 Likes