Digitone / Digitone Keys 1.21 : bug reports

Check arp length on the right hand side of the arp set up page. And check note length on the trig page, and if amp length is set to infinate on amp page???

1 Like

Arp length is 3. There isnā€™t any trig, Iā€™m playing this live. And amp length is not infinte.

The problem here is that the behaviour should be the same when using the digitone builtin keys and when using an external midi keyboard. And it is, except from time to time when pressing a key in the external keyboard, DN gets stuck playing only one note, until another key is pressed (or the key is released).

This is a video showing the issue: https://mega.nz/#!k9NDUKzZ!VDEa6TGUOdsEK4TcjIS3PQscOV5-ZCH7R5x2jjXOs6M

I noticed something that can be annoying, especially with pads.

When switching from one PTN to another that has a different instrument on one of the TRK (i.e. Switching from PTN1 with a pad on TRK4 to PTN2 with a bell on TRK4), if the instrument on the first PTN has a long release, and the note length is the whole pattern (i.e The same note during the whole PTN to give an ambiance), when switched to the second pattern, for the first note, we still hear the instrument of the previous pattern.

I think it has something to do with the voices used by the instrument on the first pattern that are still not faded out completely.

I hope this was cleared, itā€™s a bit tricky to explain.

@ph0enix This isnā€™t a bug, itā€™s even something interesting for transitions.
If you want to kill the sound when switching to a new pattern, you can add a trig with condition set to FIRST and VOL to 0 :slight_smile:

1 Like

@LyingDalai thanks for the hint, it actually work!

I agree this can be cool in some cases, but what makes me see it as a bug is that in my opinion, if the instrument doesnā€™t exist in the pattern, logically, it shouldnā€™t be heard and especially not override another instrument using its TRIGs.

1 Like

ā€œBugā€ is a term reserved for something that doesnā€™t work as intended, so it is not really appropriate in such case, IMO.

2 Likes

Same LFO bug here reported since the other Bug topics.
LFO is stuck on 120bpm even though is set to be synced with the actual bpm.
This is a know bug since 3 updates already!
Power Chord cycle solves the problem sometimes.
Iā€™ll try the workaround mentioned in this topic of syncing all the 4 tracks LFOā€™s (but this really sucks)

1 Like

Hi five

I think you are the first naut to get back with the syncing of all 4 LFOs working solution as a confirmed work arround. Itā€™s a strong indicator for dev I think. Make sure to ticket though, this forum is for us end usersā€¦

1 Like

The best workaround I found so far is to lock voices to tracks that use synced LFOā€™s. The LFOā€™s seem to be locked to voices which would explain why they act the way they do (although that doesnā€™t explain it completely). But it is pretty buggy and certainly doesnā€™t seem to be by design how it works now. A
So if you have a track that needs only 3 voices for example, lock 3 voices to it in the unison settings. This way the LFOā€™s stay in sync.

Cheers

Correct. How many voices does your bell in the next pattern uses? Lock that number within the voice menu. If there is no sound on step one of the new pattern place a note with zero volume.

Hello,

I canā€™t seem to find anybody addressing the issue on the online community and yet here is an issue I am having.

When I am sending clock to the digitone with my digitakt, I have issue with the Digitoneā€™s sequencer.

Basically one of the main issue I struggle with right now is that any trig I enter in one of the DTā€™s track will be reflected on all the existing patterns for that specific track. So for example on Pattern #1 Track 1 if I add a trig on steps 1, 2, 3, 4, all of the patterns will now have these trigs added for Track 1.
There is also an issue when I copy a Pattern to a new location, if I press play on the Digitakt, it deletes the Pattern I just pasted. Even if I just saved it to this new pattern location.

Note that the issue persists when I unplug the midi cable going for DT to DN. It still acts weird like described above.

But if I untick ā€œsend clockā€ in the DT then the issue stops.

I created a fresh program in DT and to make sure it wasnt anything about my current settings and ticking/unticking the ā€œsend clockā€ setting in DT seems to be triggering the issue.

Kind of weird? Is this some weird midi feedback situation I canā€™t wrap my head around?

Hoping this will speak to someone out there. Sending clock to the DN from the DT is pretty common so I donā€™t get it.

Thank you

Seems like if you only press ā€œstopā€ once on the DT it leaves the DN sort of hanging in a weird zone and thatā€™s the issue. Double pressing ā€œstopā€ and everything seems fine on the DNā€™s end.

1 Like

Two potential bugs?

  1. When live recording, what sometimes happens is one of the trigs in the sequence will not register a note length, so I have to manually do that after the fact. It happens to one trig (never more) nearly every time I use live record. A bit annoying!
  2. Yellow trigs seem to have no effect on arp tracks? So if I have 16 step sequence with an arp triggering on step 1 and a yellow trig on step 8, the parameters I lock on the yellow trig arenā€™t audible.
3 Likes

On the keys - it seems as though some parameters and/or knobs are not scaled correctly for one another. For example, trying to set the value of Ratio B in either Default mode of the 8 encoders or on the synth page is very hard. Even moving the knob ultra slow (two different knobs in those scenarios) can still make it hard to hone on an exact value.

In another example, I have amp attack and release times in the User settings for the 8 encoders and attack time (first knob) works fast but well whereas release time (second knob) requires multiple turns to get the same distance. Not that Iā€™m only talking about non-pushed in in these cases. When pushing the knobs in they certainly span larger ranges quicker as you would expect.

This is a brand new Keys - is this a hardware issue or a software issue?

4 Likes

I donā€™t think its your unitā€¦ mines the same. Iā€™ve noticed it setting destinations for the Mod wheel - you have to be very gentle and precise with the knob, otherwise it speeds about the parameter list.

Let Elektron know. Iā€™m sure itā€™s a software issue, and hopefully fixable in a firmware update.

Good to know - Iā€™ve reported it via a ticket. Hopefully they can fix this easy enough - none of my other machines have this type of issue, the knobs have always been pristine.

Yep, me too- way more sensitive than my other boxes. Iā€™ll open a ticket as well.

1 Like

Havenā€™t seen anyone post about this, but the lfos ā€œfadeā€ parameter does not seem to work properly when the lfo is in HOLD (sample+hold mode). The expected behavior would be a sort of simple envelope from/to the held value, but fade doesnt seem to do much of anything (until, at a certain point, modulation stops altogether - presumably its fading the source being sampled instead of the held value!).

This is a big bummer, since it would allow for some really dynamic patches (imagine random depth envelopes for any parameter using noise as the lfo shape! Or undulation from sine shape!). I submitted a ticket already but no response yet, would love to hear from @ess or someone else at elektron acknowledging this issue! :slight_smile:

I reported and asked them to forward it to the firmware team. I really hope they fix this - itā€™s really hard to use an otherwise very immediate and playable instrument.

1 Like

I submitted a ticket also. they agree that itā€™s an issue, but said they donā€™t have a timeline for fixing it at this time. Hopefully weā€™ll get a new firmware to address it soon.

1 Like