Hi, I’ve been trying to find out what the OT’s MIDI clock output resolution is.
Internet searches etc. have come up blank.
Does anyone know off-hand?
This is related to a comment on another forum made by Mr. Roger Linn.
Someone asked whether Tempest should be clock master or OT.
Roger said that the master, should be the unit with highest resolution.
OK, so he’s talking about the sequencers’ internal timing resolution, not MIDI clock.
Here’s the statement from Roger (which is a tad confusing as-written):
“Also, in general it makes more sense to sync the lower-resolution device to the higher-resolution device. Given that Tempest’s internal resolution is 192 parts per quarter note and Octatrack is a simple step sequencer with only 64 steps per pattern, why would you prefer to slave Tempest to Octatrack?”
I may be missing something, but since MIDI clock (as Peter says) is 24 per quarter note, surely it’s timing accuracy that we’re after, rather than resolution on the wire…?
If I understand correctly, the thread that you referred to on another forum is about problems in slaving the DSI Tempest to another instrument using MIDI clock.
If we assume that the OT generates its output MIDI clock signal as a subdivision of its high-resolution internal clock, then its step sequence resolution is irrelevant to the issue.
The relevant issues would be the stability of the OT’s outgoing MIDI clock messages, and the performance of the Tempest in responding to incoming MIDI clock messages.
That statement is confusing and misguided. Most modern devices, including all Elektron boxes as well as the Tempest, always run on their own internal clock, even when they are “slaved” to an external master clock.
What these devices do is that they derive their tempo from the MIDI clock messages coming in instead of using those clock messages to advance their internal sequencer like older or simpler devices do.
This is also why the clock jitter I reported has no real impact on the tightness of the slaved Elektron box.
1 Like
The reason I’m mentioning it, is that you’d think that Roger Linn would know what he’s talking about with this stuff.
Maybe he had an off-day. 
1 Like
Well, Roger Linn certainly is a brilliant instrument designer who has designed some very nice instruments with extremely good workflows, and I am more than happy to assume he was misquoted, but this statement really does not make any sense at all unless you assume the old “every MIDI clock message advances the internal sequencer” model.
And yeah, the Elektron boxes are 64-step step sequencers, but with the possibility to offset each step at 1/384th resolution and the ability for not repeats within each step.
yeah, but that’s 1/384h per bar or 1/96th per quarter note i.e. 96ppqn on sequencer resolution, so half that quoted by Linn for the other device
but yeah, as for why Linn would present the logic in the manner he has is a little odd
In terms of just clock and transport I don’t get any point, unless he’s meaning that the finer resolution of the 192ppqn sequencer could be used to trigger note events more ‘accurately’ (albeit not such that the receiving seq could store them at that resolution) then maybe that’s the point - so there’s some logic in there I guess, albeit quoted in a rather curt style
1 Like
In terms of measurable accuracy:
http://www.innerclocksystems.com/New%20ICS%20Litmus.html
OT does well in this test, and I always use it as master.
T - it’s a direct quote from the man himself. It’s on the link I posted above. …and yes, it’s the real Roger Linn.
The Tempest is most certainly the more accurate box if you want to capture a finger-drumming performance.
This however is entirely unrelated to how well these boxes perform as MIDI clock master or slave.
Do not get me started on the inner clock people. I consider their results meaningless since they don’t provide any clear instructions on how to replicate their results.
Sync’ing a lower clock resolution to a higher one make sense to me. Not sure why anyone would feel otherwise. I have been following the DSI thread as well. The only issue I have not determined is if in fact mocro tuning is lost on the OT when slaved. The OT os still running it’s own internal clock so I would like a rep from Elektron to provide some insoght into this discussion because I feel there is some misinformation being spread around the net;) Hell I may be one of those people!
Cheers;)
LucidSFX
You probably are. MIDI clock has the same resolution no matter what the master device is. The internal resolution of the sequencer doesn’t necessarily affect the accuracy of the output MIDI clock.
The issues in this case are the accuracy of the MIDI clock output and the response of the slave to MIDI clock.
1 Like
pretty simple to replicate the innerclock tests, attach a hacked midi cable to the device with a jack on the other end, record the pulses. in the same way as you would replicate the Bedford level experiment
Sure, the physical part is simple. My issue is that they don’t give any information on how they analyze these recordings.
If you’re looking at clock, you want to be looking at both accuracy and stability. Accuracy is how well the clock matches the set tempo over a longer time, stability is the amount of jitter between pulses, also measured over a longer number of pulses.
If you try to measure jitter over a shorter time period (e.g. only 4 pulses instead of something like four beats which makes 96 MIDI Clock messages total), then you can easily end up with a jitter value that badly underrepresent the jitter that’s actually in the signal.
1 Like
oh yep but the analysis is even easier, just zoom in fully in a sample editor counting the samples between clocks over a period eg 1 bar… i did this test of my 808, MD and mpc using trigger outs and midi successfully. the method was explained in the old forum here or on elektron users. any variation in samples between the midi clock pulses indicates clock timing anomalies jitter or slop. in some cases ie the md internal sequencer, creates it’s own swing when running by it’s own midi clock depending on which steps/tracks are activated. another eg. the mpc2000 has a rhythmic variation to and fro (rushing/dragging) but it is very consistent. the actual midi clock output of all these machines is solid but as with all serial ports, any additional midi data beyond just midiclock may introduce midi timing issues down the line. the OT for example is very tight, it has to be as it’s a sampler which has a lot of time based effects and functions however when it’s overloaded using all the tracks & midi sometimes there’s an occasional glitch in the timebase somewhere, i can hear that easily. i dont know why the midiclock was not put on its own wire in the midi standard, theres an unused wire anyway and that would allow for a prioritised clock channel and eliminated all these issues with midi chaining etc.
2 Likes