This all points to them only starting sample playback at the start of an audio processing block.
Systems like this typically process audio in chunks - often a nice round number like 32, 128, 192 etc.
If the block size is sufficiently small, it is easier to just make sequencer events that fall in the block occur at the start, because the error is not audible. This approach will result in all the artefacts you are seeing here.
I think I have seen similar inconsistencies on other Elektron gear. Would be interesting to see if the issue disappears after a couple of bars.
Edit, we have to trigger tracks on our Elektrons to start processing, so the issue might be related to dsp processing being stopped when the sequencer is stopped.
Ok last thing I’m going to post for at least a few days about this topic, I’m getting tired of tests I want to go make some music. But I didn’t want to leave people with the impression that if you ‘just’ set the correct BPM the alignment issues would go away.
Here are some long range tests.
First some internally clocked by the DT2 at 180 and 300 and then some clocked via Overbridge at 180 and 300
These first two could be that the clock of ableton and the clock of the DT2 don’t ‘agree’ on what exactly 180 and 300BPM is, further testing needed, it could just keep slipping to the left in regular stair steps the further into the track you get.
I don’t know how to explain these.
There was also a variation in ‘weighting’ for the slices that could be accessed speedily from a CF card, or something along those lines
I can’t recall all the deets, but there did seem to be a bias baked in which would seem to point to a timing prioritisation towards the basic beats (or is it that other commands are scheduled outside those etc)
So there can be all manner of algorithms at play which attempt to spin all the plates such that the net user experience is optimised
Everything is simple conceptually from the outside, so we anticipate perfection, but there’s inevitably some stuff happening we can’t foresee
Some of this investigating can reveal weaknesses in algorithms, so it’s good to check and report it methodically
So 112.5 and 180 are ‘perfect’
So extending the @3headedmonkey calculations
We get
48,000.0/112.5 * 96/60 => 682.6666666666666
48,000.0/180 * 96/60 => 426.6666666666667
… hmmm
I’ve downloaded “ColdFire® Family Programmer’s Reference Manual” (CFPRM.pdf), “MCF5441x Reference Manual” (MCF54418RM_refmanual.pdf) and the “MCF5441x ColdFire Microprocessor Data Sheet” (MCF54418.pdf) from nxp.com, based on one of the Digitakt (OG) hardware teardowns (GitHub - lomn/Tearing-down-the-elektron-digitakt-for-funzies: Tearing down the elektron digitakt for funzies) that mentioned the Coldfire MCF54415.
Hope that helps 
edit: also, Digitakt II PCB: Digitakt II PCB
The findings you all share here regarding this issue (especially @ripsaw) are awesome 
. Who needs netflix when there is elektronauts 
Can’t wait to know how this will end! 
this isn’t desirable like gritty old sampler resolution is desirable? seems like a color if it’s never the same. I’m thinking this clock division thing that’s messing up timing at certain tempos is also the reason for DN2 tuning to be trash in certain areas. i swear it gets better or worse in different master tune areas, 430, 450. it sounds like bad math. it might be the sound of perfect math idk
