OT sequencer stops unexpectedly

Any (other) filters on the MIDI monitor?
Since I didn’t see any realtime/clock messages.
Transport is off right?

Clock is the only filter. I had re-enabled transport IN.

I’ll be damned. It just stopped.

Will try 40 next.

Same here. It stops at 42 as well. Had to go to 52 to get it to keep running.

40 still running here.
What was the lowest tempo where you never experienced this?

Or, the highest you did… :wink:

To pick up from an earlier post, what stops you from using OT as master? Is it important to have Pam’s as clock source?

With OT as master, you get the most accuracy, not least for the sampling and playback part.

When running as slave, the OT has to constantly interpolate and adjust for the incoming clock messages. It does this very well, but it’s still much better to use the internal clock.

I only slave to a DAW occasionally, even trying to avoid that.

As you are only sending clock to OT, it’s probably a very easy workaround.

…still running…

Edit: it stopped again after ~ 3h

Yeah, clearly a bug, I can reproduce this.
You’re on 1.40A i assume?

I don’t see anything mentioned in Octatrack OS 1.40A: bug reports - you should post it there, and report via the Support Tickets section on elektron.se

Perhaps some of the old-timers can say if this problem has been around in earlier revisions.

Not necessarily. The slower the clock, the longer the internal sequencer / audio engine has to be running in a kind of free-wheeling mode in between incoming clock messages. I can see this being problematic (not least because of jitter in sampling).

If the (external) clock source is slightly unstable, this is much more noticeable at slower speeds.

Of course it’s all relative, internal (CPU) clock, timer frequencies, interrupts are all factors in this.

At very high clock speeds, you’re more likely to run into problems with merging (or parsing) other messages, like cc and notes etc., due to bandwidth.

1 Like

I already have a support case opened 2 weeks ago.

The lowest tested BPM so far that has not stopped was 52. I’m testing 49 now. 42 definitely stopped.

If I use OT as master I would want the Pam’s midi interface to start it from the OT. I can start Pam’s from Nerdseq (or 1U midi), but I strive to avoid serial, as opposed to parallel wiring. Nerdseq is my main sequencer, and that should be master start/stop.

Oops, there is no Pam’s midi IN expansion :frowning:

1 Like

Okay, I see.
I would try to use Nerdseq’s clock out into Pam’s.
Shouldn’t be a problem to daisy chain a few “analog” clocks.
But I haven’t tried either of those modules.

Stopped on me at 50. Trying 52 again.

I noticed OT’s internal clock is minimum 30 bpm.
I tried 24 bpm and it wouldn’t even start.
My guess is, the closer you get to that minimum, the sooner it will stop.
It stopped much earlier with 32 bpm, than with 40.


I switched to Nerdseq sending clock to Pam’s. Which won’t change this situation obviously. Trying another 40 test just for kicks. Good observation on the minimum.

It appears to me that around 50 is the lower limit. But I a stop at 50, so testing 52 again.

The sysex messages are not related to the NerdSEQ, so you are monitoring the wrong source. However, it looks like with all the tests that this is mainly a problem with the octatrack since it happens also with other gear as it seems.

Correct, nothing to do with Nerdseq, it appears to be a bug in OT.

1 Like

The sequencer eventually stopped on my test unit, and we will run more tests now. I will report the issue to our developers and we should have a fix for the next OS release. Thanks for the report!

Best Regards,

Patrik - Elektron


Apparently confirmed so. Maybe you were the only low tempo user with OT slaved…:content:

1 Like

Pretty sure State Azure has used it like that for years?

Don’t know.
I testing OT MKI slaved by DT at 32 bpm right now. Playing since almost 1h30mn…

1 Like

40 more minutes, give and take :wink:

btw. I tested on mk2, but I guess there should be no difference.