I use my DT as a master midi clock for my rig. Is it possible to reset the clock and send a reset message without stopping and restarting the clock? I can’t find this in the manual so unlikely it’s possible, but I live in hope 
What exactly do you mean when you say resetting an restarting? For a device that is listening to the clock messages, both would look the same.
As far as I know all Elektron devices send constant midi clock as soon as you turn them on. And then a start and stop.
Edit: of course only when activated in the settings.
That’s not actually true for the Digitone. Whenever you start the transport the clock is reset, so that the beats are aligned with the transport start message.
Other units might also work the same but I only tested the Digitone.
Interesting you should say this has been tested …
it strikes me as an odd thing to do (i.e. what you say Elektron are actually doing, resetting the clock)
firstly because there’s possibly devices up and downstream creating or using clock
and also, for the default tempo there’s only ~20ms between clock messages which strikes me as accurate enough to let it just go on as was
what was the test you used to determine this out of interest ?
do you mean the clock(i.e. the actual clock messages) (or the sequence) ? it’s possible to pause transport with/without the seq resetting
Maybe it is a little bit of both I have the feeling the MIDI clock is constant and when you press play it will take the next clock signal and start off. I believe this is how it is because when I clock the Arps of a System 8 or Virus TI there is no hiccup or anything. Also if you latch them they might be off sync because they keep going although you started at a different time on the DT or DN.
Another example is that with Ableton the Virus TI needs a bar or 2 to lock in - probably because MIDI clock is starting when you start Ableton while with DT or DN it works amazingly well and stable.
With all that said ,I will not put my hand in the fire for it 
I hokked up my oscilloscope that can do serial decoding to the MIDI out and looked at the signal.
The first beat clock message after a transport start message always appears “too soon” compared to the previous beat clock message, but then all the subsequent beat clock messages after first “early” one are correctly timed after the “early” one.
If you have a device that is following the Digitone’s clock and can react fast to MIDI clock changes then you can see it without an oscilloscope.
When you start the transport, the follower device will display a wrong tempo for a blink of time.
This is normally fine but my BOSS RC-500 wants to timestretch recorded loops to the external MIDI clock. You can hear the artifact caused by the clock being reset and the looper trying to timestretch for a split second and then eventually stabilizing.
2 Likes
I actually wrote to Elektron, asking for a mode that you describe, where the clock is never reset and play messages are delayed until the next beat clock message is about to be sent. This was a few months ago. No reply so far.
I found a screenshot from when I investigated!
If you don’t know how serial communication looks on a signal level, it’s fine.
Just look at the evenly spaced pulses, and then around the middle you can see two pulses really close to each other.
Those two pulses are a transport start message and then a beat clock message.
You can also see that the beat clock message after the transport start is too early, but then the subsequent messages are timed evenly again.
From what can I see, it looks like the clock is reset, so that it starts when the start button was pressed.
2 Likes
interesting, I wouldn’t have anticipated this at all … I can see some of the logic of trying to keep things ‘tight’ with the user input - but if you’re a device a bit further down it’s going to be a bit jittery for a moment
I imagined that the user transport input would ‘quantise(delay a bit)’ to preserve the clock ‘flow’ - but I suppose at low tempos it could feel laggy which might be an issue too
good to know, glad I asked and I’d assume most recent Elektrons were working like this 
At 20 BPM the worst case lag would be 120 milliseconds. At 60 BPM it would be ablut 41 milliseconds, at 120 BPM it would be about 21 milliseconds.
I would would expect that if someone enables “quantized transport start/stop”, they are aware what that means.
I wonder what the Digitone does if it receives an external clock but it is still set to send transport messages. (I such mode would exist at all)