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.
Since updating to firmware 1.10A, the sequencer on my Digitakt II has been acting unpredictably.
Initially, I noticed that certain sequences would contain flashing red trigs after restarting the DT2 or copying patterns. These trigs didn’t play any sound. When I manually pressed the affected trig, it became active and could be removed afterward. Only after “cleaning up” the sequencer manually would the sequences remain stable and unchanged.
Now, things have gotten worse. There seem to be strange interactions between multiple trigs. For example, when I edit a single trig with P-Locks, other trigs in the sequence are sometimes altered as well—even though I haven’t touched them. I’m not using the new “Hold Track to P-Lock all Trigs” feature, so this shouldn’t be happening. It’s as if the DT2 is unintentionally applying automation or recording parameter changes across multiple trigs without recording mode being enabled.
The issue first appeared after I tried out the new “P-Lock all” and “Track Swap” features introduced in the update.
Has anyone else experienced similar behavior? Thanks for your help.
I’m having difficulty moving samples from the Drive:Recorded area, into a folder I created in that area.
Per the manual, I select a few samples (by pressing the yes button, which puts check mark next to them), press the right arrow, select Move Selected by pressing Yes button, I get a dialogue box that says I have a number of samples selected “choose folder”.
I press yes to exit the dialogue box, press the left button to get back to the list of files and folders, press the up button to get to the folder I want to move to, then press the right button, then select “move here” then press yes, and get an error message saying “0 files have been moved, and 3 errors”
Hey, you may want to try moving them one at a time just in case a problem with one sample is causing all 3 to fail. The other thing I would do is try 1-3 totally unrelated samples. You could try existing ones or just record a couple of beeps from your phone ringtone or whatever, it’s just a test so it doesn’t matter what you use.
If it fails with these other circumstances as well, the only other thing I might suggest is trying it in a new project as a test, also just in case there is a problem with your project that has those files in it.
If all roads lead to failure, I would submit a bug report directly to elektron user care and give them the steps that you followed to reproduce the issue. I think that if it’s a bug which consistently does what you’re describing and can be validated, they’ll probably want to know about it.
Dont know if its mentioned before (iam on latest firmware):
On sampling, sometimes FUNC+YES doesnt work a second time especially if you went out of the sampling page and going back again. You have to switch the modes (play once only when FUNC+YES are hold, play once till the end regardless if FUNC+YES isnt hold the whole time, loop, endless loop, …) to get it working again.
not sure if this is a bug, and it doesnt bug me personally, but when I go to the delay-page, i cant finetune the feedback parameter to all single values between 0 - 198.
by going as sensitive as possible, starting at 0, it goes: 0, 1, 3, 4, 6, 7, 9, 10, 12 …
so however i turn the knob, and from wherever I start, the values 2,5,8,11 are not accesible for me. maybe my encoder D is a bit loose? when changing to the AMP or FLTR page though, I can access all values by finetuning, so I dont think its a problem with the encoder (+ my unit is almost brand new).
I am just wondering if this is the same behaviour for other DT2-users… and if there may even be a reason for that, which I dont know about?
Nope, that’s just the UI design: there are 127 values (for MIDI control), and they’ve placed “100” in the center in order to make it clear that that’s the unity gain (100%) for feedback setting. On this control, in particular, it’s important to signal that feedback might get out of control.