I’d have to look for where it’s discussed, but several times it’s come up that there is an additional 1-2ms? Something like that, which is missing from the beginning of direct sampling or maybe it’s just resampling. Just wondering if perhaps you’re missing a ms off the front of your sample and it’s showing up as a loop which doesn’t loop at the correct bpm.
Anyways I don’t know if you’d call it a bug or what, but I might have seen it added to the change log for fixes in one of the recent FW updates, I’ll take a look real quick.
Didn’t see the fix in the change log but here’s one of the related posts.
No worries man! If you want to do a little extra work, you could try something like:
load the break
repitch to 88bpm
change the length / scale menu settings for the pattern to add an extra step to your pattern (making it an odd length) and then shift the entire pattern over one step to the right (I think this is func plus the right arrow, but I’d have to confirm).
resample a longer portion than what you actually need so there’s a blank step at the very beginning and then some extra at the end.
manually find the start and end points.
Kinda sucks and I’ve never tried it so I can’t be 100 about it working like I think it will, but if it does then it should cut whatever erroneous amount (1-2ms) that it might be truncating, out of the silent step at the beginning, and then it should be real easy to know precisely when the end of the loop comes up, because it will go back to the silent step before any more audio plays.
Like I said, it’s some extra work and kinda sucks but I can’t imagine that it’s gonna be cool working with breaks that don’t quite loop right so might be worth trying.
Midi track bug found.
The new update brough setting Plocks for all trigs on the track, but this doesn’t work for midi tracks. If you hold trig+page and set trigs, it will work for that page, but trig+trk doesn’t actually do anything. Same for clearing Plocks, you have to go through page by page, but can’t use the new function to clear a parameter for all trigs in the sequence.
The length of the recording could be slightly incorrect when using the R.LEN parameter in the SAMPLING menu to record a set number of steps at the current BPM.
any news on this one? having the same issue here. don’t know how to reproduce it but seems like the last pattern i worked on after switchung DT off changes trigs after switching on again. often only the blinking trigs appear without influencing the sequence at all but sometimes intended trigs get lost. might contact support soon.
I asked the support about this and they say, this “behavior is currently working as intended. Copying the SRC page from one machine type to another can be problematic, as the parameters often differ between machines.”
The strange thing is, that it has been possible before (e.g. OS 1.03) and it would just replace all the parameters including the loaded machine (which is great IMO).
But it’s not possible with the 1.10/1.10A OS Update anymore.
So I asked for a feature request (if it’s not a bug).
You got a ‘like’ from me for identifying the issue. I’d seen weirdness (both pages you mention) but I hadn’t exhaustively diagnosed the problems.
I can see the difficulty Elektron support raise (AMP and SRC) in that some of those 8 encoders map to different underlying values in differing modes (diff. machine for SRC, diff. mode for AMP). … BUT … as you suggest, you would have thought that elektron could have come up with something better.
Hi! I’ve just found that Digitakt II (probably also Digitakt 1) don’t read correctly mp3s.
It infact don’t take account for the gap present at the start of every mp3 file: this means that if i chop a 4 bar loop at a certain bpm in a DAW it will not be in time on Digitakt II, expecially if i try to use the Grid machine.
This is really frustrating because if Digitakt II was able to read the metadata with the exact value of this initial silence gap, the file would result in a perfect 4 bars sample.