Digitakt 1.20 : Bug reports

I post to get confirmation from others before reporting to Elektron:

In 1.20A, if I copy a pattern from a MIDI track to a non-MIDI track, notes are all garbled in the display of the Trig page and when played they are not the right notes.

Can anybody confirm?

3 Likes

Why not just report? No skin of yours or their teeth. :+1:t6:

2 Likes

I had a look at this and can confirm. Good find! Not a very common use case, but it should of course work as expected. Please create a support ticket so that we have the report on file: https://www.elektron.se/customer/tickets/

2 Likes

Not sure if itā€™s a bug and I think itā€™s not relative only to 1.20, but when you are in sampling menu and you choose sample from USB, it turn monitor on automatically but you canā€™t hear only Left or Right channel if you change it to USB L or USB R. Alway both channel are monitored. Itā€™s make the USB sampling unusable.

I have the same problem, but I donā€™t use Ableton. I control hardware synths. Trigs notes flash, but synths donā€™t play.

i still bug with the trig condition; true when 1ST is false, itā€™s dont work in pattern chain, despite update 1.20A.
Anyone else with this problem?

Yes, I have one problem. Trigs flash, but synths donā€™t play.

Another prog. ch. bug report here. Itā€™s long-winded, but Iā€™m pretty sure Iā€™ve tried everythingā€¦ :frowning:

When the scale on the two paterns is set to 3/2, I chain 2 paterns A1 and A2, on track 1 of the two paterns, there are trigs true when 1ST is false (no1st), on the first patern the condition works, I chain the patern2 without stopping reading, the condition true when 1ST is false does not work on the second patern.

the bug is when the previous pattern has a 3/2 scale per track, the next pattern with the NOT1st trig condition, the condition doesnā€™t work.
I found the same bug with differents trig conditions 2: 2 or 2:3 ā€¦ā€¦ā€¦ā€¦

i have the same bug on my digitone.

Inverted behavior of Mute commands when recording in Overbridge, aka playing back a recorded part with a track muted makes ut unmuted and vice versa.
Found with Ableton Live.

Steps to reproduce:
Arm MIDI track with Overbridge VST in arrangement view.
Record part with track muted, then unmute the track.
Confirm Automation line moves from 1 (muted) to 0 (unmuted).
When playing back the recording, the first part of the recording will be un-muted and the second part will be muted instead of the other way around.

On my DT, some 4-bar patterns with swing settings seem to conjure up instances of single pages where swing isnā€™t activated. You canā€™t change it through the quantize or swing settings, through microtiming or even by removing or adding trigs - the only solution is to copy another functioning page of trigs and paste it into the malfunctioning one. I use heavy swing percentages all the time and seem to run into this too often for comfort. Does anyone else get this issue?

Hey man i posted a thread a while back on the same issue, this is what i wrote:

"Hello!
I am remaking mario bros 3 music on the DT which has alot of swing, i have it set to 65% which works well. Until pattern 5, now for some reason I dont understand the swing is only applied to page 1 and 3 while 2 and 4 is all straight notes, i am very confused, did I trigger some setting I dont know about?

Any help greatly appreciated!"

You are not alone! I have no clue what the issue is though

1 Like

Exactly, as far as I can remember itā€™s pages 2 and 4 that are affected.

I just got the same error last session.

Dunno if itā€™s a known one but just came across this:

Yellow trigs will randomly interrupt the playback of a preceding red noteā€™s retrigs value when the retrig rate is 1/16.

e.g: If the red note retrigā€™s Rate is 1/16 and its length is 16.0 (a whole page of of 16 repeats from 1 retrig), then a yellow trig placed later in the page will randomly stop the retrig ā€“ sometimes the retrig will play the whole 16, sometimes it stops at the yellow trig (only plays 8). Totally random.

:red_square: :black_large_square: :black_large_square: :black_large_square: :black_large_square: :black_large_square: :black_large_square: :black_large_square:
:orange_square: :black_large_square: :black_large_square: :black_large_square: :black_large_square: :black_large_square: :black_large_square: :black_large_square:

Red note retrig set to rate: 1/16 and Len: 16.0
Yellow trig lock has nothing p-locked to it

Also:
ā€“ If the retrig rate is less than 1/16, a yellow trig will always interrupt the retrig.
ā€“ If the retrig rate is more than 1/16, a yellow trig will never interrupt the retrig.

Iā€™m on 1.20a, I came across some strange behavior last night and I canā€™t tell if itā€™s always been like this.

The attack and decay parameters on the AMP page seem to be mismatched. For example, with attack and decay both set to 64, the attack stage is much shorter than the decay when listening. When both are set to maximum, the attack stage takes about 2 seconds and the decay stage about 15 seconds to complete. I donā€™t think this is right.

The filter envelope in unaffected

The behavior continues on new projects. I did have a midi loopback cable in, but taking it out and starting a new pattern has no effect.

after saving a sample, screen goes into just-guess-what-the-knobs-do-now mode.

ELEKTRON THANK YOU FOR PUTTING SAMPLE ZOOM INTO DIGITAKT omfg

I believe that is just what they decided were useful maximums for the attack and decay. I have noticed that the attack parameter is a bit odd, like it is logarithmic or something because it is hard to get a slow fade in. I think this is intended behavior. If you want a slow attack that you know will be linear you could use the LFO to volume on the ramp waveform with mode set to HLF so the ramp goes from zero to the max depth and stays there. This is generally a LFO recipe I apply to all sorts of destinations.

the same thing just happened to me when trying to setup mutes before recording a simple thing. after flipping the track mute automation from 1.0 back to 0.0, they eventually just stopped muting altogether. any idea if this has been addressed yet? iā€™m pretty sure iā€™m on firmware 1.20a and latest overbridge on os x.