Not sure if this has already been posted…
When I do Reverse Loop or Forward Loop with a sample the envelope doesn’t really respond as it did in 1.04. The loop points in my previous projects are all of a sudden very clicky when it cycles either manually or via LFO.
Am I just imagining that it was smooth before or is this a 1.06 bug?
This may be the same issue as Ymsey posted above…?
There’s some weird stuff going on when using the yellow trigless trigs in my patterns. These trigs have no param locks on them - they’re new, clean trigs – but they screw things up if they follow an existing note trig that contains param-locks. It seems that the trigless trigs keep the settings of the preceding param-locked note trig, rather than ‘letting go’ of the temporary changes. It’s much easier to show in a video… (please excuse the unsync’d audio/video and my garbled terminology!)
(send to support)
hello guys, I’m new here, and my only experience with de DT is 1.6,
I found a lot of bugs, this automation problemb Garf just talk about, the CC strange behaviour if you do not put off the CC pots on filter page after automation; sometimes my unquantized trigs live recording are not rec…
anyway, tell me if it was so buggy in 1.4 ? I mean, I know about midi crach etc, but for 1.6, one year old start production machine, i found it very buggy, and it’s annoying, because i like it sound…
the yellow triggers, are for the automations, have you not automated something?
nothing automated. new “clean” trigs, as mentioned.
I haven’t found 1.06 to be any buggier than 1.04, and I do prefer the encoder sensitivity adjustments and other improvements.
Though I’ll admit I am very gentle with the DT - I don’t ask much of it other than as a sampler, drum machine, and basic MIDI sequencer. Occasional parameter locks and conditional trigs. Rarely do I use trigless trigs as I don’t really use long samples.
Any heavy lifting MIDI wise I use a proper event-based sequencer.
I had this same issue,
Worked on a track, resampled some hi-hats and kicks trough a pedal. -> named them, assigned them to a track, saved everything correct.
Came back an hour later to see that the samples were not only missing from the pattern, + the project list(now there was just a ----- where the sample used to be (named correctly). But also in my +drive in the section where you find the “recorded” samples they wore gone.
Strange thing is that not all samples were gone, 3 of 4 were missing.
I can manage to re-resample those drums, but i don’t think this is normal behaviour so thought i’d share it here.
It’s so cold in the uk , the coldest country on the planet , the bestest cold in the history of the universe.
An early March firmware update would melt our hearts , and the snow.
Come on elektron !!! , it’s spring time.
Boing.
Ok, new bug here. It’s about unquantized live recording mode
Sometimes a double trig on a kick is not record
so aonnying
I Could write it in step mode (first kick on the grid, and the next one in -1/32, but it should works with the live recorde mode…
Do you guys have this one ?
I experience pretty frequent freeze when boot up startup menue, is that a known bug?
What OS are you on? I’m on 1.06 and no troubles here. Though I live record mine via Keystep or Launchpad pro instead of the track buttons so that could be the difference.
so am I the only one who encouter the issue ?
I’ve had that happen occasionally, with the opening logo animation freezing halfway through.
Rather than trying to power-cycle the unit, I walked away and let it sit for a bit, then it cleared and I haven’t seen it since.
Hi DataStrain,
you right, I never have this problem with external keyboard, but only with the trig button, witch it’s weird because, when the bug happen, the missing trig not in the grid is send by MIDI out (i record on MIDI out my trig).
Elektron support are nice, but sometime i wish they could read what i write, because they act like they don’t want understand what I told them…
bug confirmed with support, no date for a fix.
I had this too, but after some experiences about i found out that it only happen when you record a close trig (less than 1/2 step) to a previously recorded one, even on the previous cycle of the pattern. For me recording fast double trigs in the same shot works.
But yes it’s an issue that new trigs can replace close one, and messing up your groove.
Could u confirm if i’m right?
I already post a ticket bout this, u can too.
Peace
Hello Ymsey,
Yes I get the same bug. I was thinging that my trig problem was only with the trig button but i get the same with external keyboard now.
It 's exactly what you said, when two or three trig are to close, they are not record in the grid.
For me it’s a hudge bug, I’m already unhappy with that unquantized mode that it’s not a real on, I mean I’d like a very precise unquantized mode, but If we can not record in live mode, something we can create with the grid in step mode, it’s very a hudge bug.
Cool that you creat a ticket, if we are a lot to ask fot this bug, it could be on the top list
I have to send them a video of this bug
midi cc bug on midi channels .
i changed settings for the knobs cc , eg. send on 11,12,13,14,15 etc instead of default of 70,71,72 etc
the data was sent out as expected to ipad/aum
when i reloaded the pattern to default , the values on digitakt were displaying 70,71,72
but the data is still being sent on the previous midi cc. , 11,12,13,14
expected - it sends midi cc data on the channels shown.
Not sure if this is a bug or how to stop it from happening. When i switch from a patter to the next the samples from the previous pattern keep playing until the sample is over while the new pattern is playing. Can anyone tell me what im doing wrong here?
@Dayoneneo Seems normal to me.
To avoid such behavior, just place a trig on the first step of next pattern.
If you don’t want a sound to be triggered there, just plock amp vol to 0.
You can also use trig condition 1st if you still want the sample from this second pattern to continue from last step to first one…