Thank you.
This Reddit post helped as well - https://www.reddit.com/r/Reaper/comments/ednykb/external_timecode_sync_spp_reaper_as_slave_issues/
1 Like
There could be many reasons the clock is drifting or not working properly,
And people have have different setups computers etc
My suggestion is to try everything before you rush out and buy an Expensive external clock.
It could be conflicting midi settings, or audio latency, daw settings, soundcard settings
Could even be your computer etc
1 Like
Yes I’m with you there but I’ve been battling this for a while and have tried to optimise my PC, use different MIDI setups, etc. for fair few hours and time’s not free. I’m definitely at the point where around £150-£200 to maintain my sanity is worth it!
Or at least now I know there’s likely not to be an easy fix on my PC so I’m going to try and just run them independently (with only start synchronised with a note on command) to at least try and get some solid music recorded for now before spending any more cash.
2 Likes
I’m using pc also.
I’m using overbridge clock from A4 then sending it via midi cable to Octatrack.
Overbridge clock is super tight, after that it could only be audio latency or daw settings.
That’s all I can suggest, but good luck it can be frustrating
Thanks for that tip, I haven’t used the overbridge clock and also have an A4 so I’ll give that a go as a last resource before I go into manual mode!
1 Like
This is a horrid problem! I used to struggle with this a huge amount (specifically REAPER and MIDI clock sync with the Octatrack).
Getting an Expert Sleepers USAMO definitely helped a lot but I found it was still a bit temperamental. It’s good once it’s locked in but starting and stopping in REAPER was a bit hit and miss I found.
The USAMO with Ableton Live worked a lot better for me, but actually what’s really sorted my problems out once and for all is moving to Mac from a Windows PC.
MIDI sync from a USB interface which supports USB timestamping (I have an Edirol UM-880) on OSX is so good that actually there’s no real need for me to use the USAMO.
Obviously this isn’t necessarily the cheapest advice but I wish someone had told me this years ago and I would have bought a Mac and saved myself years of tearing my hair out…
3 Likes
Glad we’ve got a little support group going on this. I thought I was the only person suffering this pain 
Not knowing it was such a problem with the hardware is worse though as the fixes I tried were unlikely to solve it. I’ll try Dan’s option as a last resort and then see if I can get any joy with letting them running independently. Even if they drift after a while at least I can have a rock solid inspired minute or two to chop up!
1 Like
I’m going to give the Overbridge clock a try tonight before I let them run free and unsynced. Can I check something - are you using a Mk1 or Mk2 A4 (I know they improved the USB so not sure if that’s a factor and I have a Mk1) and which DAW are you using?
I’m assuming you’re using the DAW as a slave and one of the problems might be that Reaper doesn’t seem to work very well as a sync slave.
A number of things to unpack here…
BPM display is a form of frequency estimator: using the incoming clock periods to estimate the frequency. There is a tradeoff between responsiveness to tempo changes, vs. smoothness of the estimation. Elektron has always chosen to be responsive, and this appears as small variations in the displayed BPM.
In short - the internal clock follower is probably a phase locked loop (PLL), and tracking the incoming clocks closely, and with good or great accuracy. It is the BPM value estimation - which doesn’t run the sequencer (the clock PLL does) that is looking jittery.
Nerd alert: BPM is reciprocal of clock period - and scaled large, because “minute” - that conversion is going to make tiny adjustments in the clock look big: 120.0 to 121.0 is caused by just 172µs change in a single MIDI clock. That’s 1/5 of a ms! It looks bad, but it doesn’t perceptually change the timing - esp. as it averages out over the course of less than a measure.
As @sezare56 said, it is normal. Don’t look at the Octotrack’s display, and just listen - you’ll never hear those 1 bpm variations - because over the course of measure they are smoothed out.
Since this is the generally most stable and workable set up (DAW master, external device slave) - it is worth trying this approach again with a careful test (again - don’t look at the OT’s BPM display).
You can’t really extrapolate from that article’s situation to this. The source of the jitter it investigated is expressly about the timing issues between incoming MIDI notes, and buffered audio generation in the computer. It doesn’t even apply to incoming MIDI clocks (as clock following isn’t generally tied to audio buffer generation in DAWs.) The comments provide some info, but nothing as rigorous and well framed as the article itself.
In short, I don’t think you can simply condemn USB based MIDI as a whole from that article.
This is a bit off the mark: USB doesn’t buffer at all. It is computer operating systems (including the operating systems of instruments like the Octatrack) that buffer.
Audio buffering is usually a visible setting in DAWs. In an instrument, we can assume it is low. Think of it as sending the next 256 samples (5ms worth) just as the last few samples are playing. This means that computer is ahead/behind that much when sending/receiving. The results are smooth, just offset. This matters nothing for playback alone - but when combining with live performance, the buffer size limits the responsiveness.
MIDI input buffering on most OSes is, by default, 1ms’s worth. Many OSes provide higher speed access, though not all audio software makes use of it. Modern Mac OS X is provides much higher resolution for MIDI (see below).
Recently, I did a long and careful analysis of sync an Reaper for this forum: Exporting or capturing Digitakt MIDI tracks?
tl;dr:
- Reaper quantizes incoming MIDI to the audio buffer size. Use as low an audio buffer as you can, preferably 128 or lower.
- The same tests with Ableton shows that it doesn’t link the two, and MIDI is always processed at a high timing resolution.
Another thing to note from that analysis is that on modern Mac OS X - incoming USB MIDI is generally captured with < ±0.1ms. or better accuracy (and 98% at < ±0.3ms). That is well below perceptual thresholds in almost all musical situations.
7 Likes
Thanks, that’s all really good stuff to know. I do think it was jittery although can’t discount the possibility that the fluctuating display was affecting my judgement on this.
I was noticing the problem on patterns in the Octatrack not sounding as ‘solid’ as they did when it wasn’t synced from the DAW but I’ll do some proper testing and compare audio files.
One things that was definitely all over the place was the arpeggiator on my synced Keystep. This is taking sync from my DAW and then sending MIDI to the Octatrack > A4 > synth MIDI chain via the DAW and you could hear it had v.bad timing but maybe Reaper clock to Keystep isn’t the culprit there.
(EDIT: changed ‘drifting’ to ‘jittery’ as that’s a better description)
I’m not condemning it from that article, I just shared the link because it goes more in depth than I had time to. The inherent timing problems of MIDI over USB are really well established (and aren’t the only thing that causes timing problems in a multitasking OS, but it’s one of the most consistent). MIDI timestamping can help but it’s not part of the MIDI standard and only a few recent interfaces support it under a few OS versions.
There’s actually SO MUCH discussion of it online it can be hard to sift through and find a good, terse explanation. Here’s a good one from Colin Fraser that gets copied and pasted everywhere (first response):
Basically, if you transmit MIDI over USB there’s pretty much a hard minimum of 1ms jitter (not counting other timing errors introduced by your operating system that can easily bring it up to 5ms or more) whereas a good hardware sequencer like an Octatrack or one of the better MPCs will have less than 0.5ms of jitter. That said, 1ms of jitter isn’t really that terrible and if that was the only factor involved it would be fine for most purposes. It’s when you throw a multitasking operating system and they way it handles CPU scheduling for USB data transfer that you get real problems.
Latency is a whole other thing, MIDI as audio will still have latency, but the timing will be as close to sample accurate as your hardware can get.
Hey sorry didn’t see your reply, how did you go?
I’m using ableton master, the A4 overbridge plugin runs along side of ableton with its own clock output as you will see at the top of the plugin…
This is how I’m doing the clock as I said earlier I don’t have any problems this way and have seen other people say the same thing.
I’m not familiar with reaper but it works perfectly with ableton.
You might be having trouble with latency if still not right?
If so how are you getting audio into your daw?
Well if you are using a laptop with 4gb ram and it’s overheating you probably would get jitter,
I imagine that everything will jitter too
Pretty sure midi is just a pulse and some data it’s not laser accurate but completely usable
Timing problems inherent to multitasking operating systems and MIDI over USB have been well established for a couple decades now, if it doesn’t bother you that’s fine, if it does bother you there are solutions.
Using Overbridge seems to be a good one, Elektron doesn’t appear to have implemented clock and MIDI transfer via Overbridge as a class compliant MIDI device so it doesn’t experience the timing problems that are inherent to class compliant MIDI devices.
Before Overbridge was a thing, Elektron was selling the TM-1 Turbo MIDI interface that was specifically brought to market to mitigate the timing problems of MIDI over USB (and gracefully handle unusually large MIDI data streams from all of the control data the Octatrack can produce) because Elektron recognized that the timing of MIDI over USB and USB MIDI interfaces was problematic. I assume they rolled that protocol into Overbridge, too.
Solutions to what ? It doesn’t bother me because there is no problem,
I’m not making a compromise of any type, I use it everyday.
I wouldn’t put up with a compromise either
I’m the one that suggested using overbridge clock, but I don’t remember having midi clock issues before overbridge anyhow and I’ve had a few synths for years.
1 Like
That’s technically incorrect.
The only thing that’s special about the TM-1: it can negotiate a faster transfer rate with a turbo midi capable device (done via exchanging special sysex messages). This comes in handy when you need to transfer large amounts of (MIDI) data, but it doesn’t help with the intrinsic timing issues of USB which stems from USB data frames and interface polling intervals on the OS level.
From a technical point of view the unavoidable MIDI jitter isn’t large (as @mzero already pointed out). But this requires multiple components to perform well together which is not always the case (OS, driver, host hardware, client hardware & software).
3 Likes
No probs I haven’t had a chance to give it a try yet but I’ll have a go tomorrow and let you know how I get on.
1 Like
The write up there has some problems. It compares worst case USB MIDI to a theoretically ideal conditions for DIN MIDI - and it doesn’t even bother to compute the same metrics for DIN MIDI for actual comparison.
But, the bigger problem is that it doesn’t consider how MIDI clock is received, and used: Anything receiving MIDI clock is smoothing and averaging the computed rate (and it’s inverse, tempo) over some period, at least an eighth note, perhaps as long as a half note. That means it doesn’t matter that the instantaneous tempo of a clock is high or low - as long as the average is constant - which in the very case described, it is: 125ms for six clocks, which is a 1/16 note - and is exactly 120bpm.
As for HW being more accurate than PCs - that generalization doesn’t hold… Both can be all over the map. I was measuring the DIN24 output on our beloved Elektrons the other day… the jitter is crazy huge, though the running average over the course of an 1/4 note - is, as you’d want - dead on.
Hello,
Sorry to bump a year later in the conversation.
I ve read it all, and I wonder if you tried to use the non native reaper clocks made by reaper users:
REAPER | Resources.
These are JSFX (for reaper) that generates midi clocks. You have to install them, set one of them on a track. Then you go to the routing options of the track an open the midi out port. It won’t be as good as an usamo or ERM-multiclock but it might solve some of the issues of the native reaper clock.
Cheers
2 Likes