Hey, just wanted to share that I am also experiencing this LFO bug where LFO’s with a “BPM” time division stop following the BPM when other LFOs do not also utilize the BPM time divisions. Here is an easy way to reproduce one manifestation of this bug, if others would like to see it themselves- there are other aspects not illustrated by this (like lfos being thrown off sync by other tracks LFOs), but it gives you a taste for what’s happening. I hope this is fixed soon!
Init pattern
Set BPM to 75 (for example, just something other than 120).
Fill track 1 seq with trigs.
On LFO page, set LFO 1 to modulate pitch or some other noticable parameter.
Set LFO1 time division to a slower BPM division (e.g. 4bpm or 8bpm), so you can hear the rhythmic syncing.
Now, for LFO 2 on the same track, change the division to one of the non-BPM-synced settings. Suddenly, LFO 1 will stop following the BPM you set, and will switch to 120 bpm settings! Change LFO 2’s division back, and LFO 1 will revert to it’s intended behavior. LFO2’s settings shouldn’t affect LFO1!
Hope this is fixed in the next firmware update, cause this is pretty wonky.
Also, just wanted to second that I’ve noticed trigless locks don’t seem to impact sounds which use the arpeggiator - however, sometimes if you fiddle with the note length and turn the arp on and off, you can suddenly get it to follow the trigless locks - it’s really glitchy, and definitely not as it should be. This is a big letdown, since locking params of notes triggered by arps sounds pretty amazing to me
Yeah, something is not right about the midi coming into DN. I’ve stopped using it, aside from OT midi arp to DN occasionally, because the hanging notes are barely noticeable then. The same notes get retriggered often enough to not let them hang noticeably.
KB SCALE settings are not working on MIDI notes received on TRACK CHANNEL. i.e. notes are not filtered.
If notes are received on Auto Cannel, it works and notes are filtered.
Has the click every 16 steps when holding notes ever been resolved? No audio input just straight DN. When i play a blank pattern and hold down a few notes, there is a click every 16 steps. I’ve seen this posted on older threads but has anyone experienced this on v1.21?
I did a lot of midi mapping with the DN and DT recently (can´t speak for the DTkeys)
and I found 2 things in regard 2 midi
On DN ver. 1.21 i can go -5 oct on the chromatic keyboard but only +4 oct.
nur sure if this is intentionally or just missing.
In regard to midi mapping on the DT.
Some parameters are controlled by high-resolution midi controllers. you can see what parameters in the manual. These usually have two MIDI messages associated lsa and lsb.
I found that, if I want to send MIDI to these controllers I have to send it only to the lsb
parameter and the lsa automatically follows.
Further… not all parameters are set up to receive normalized 0-1 values.
f.e. for SYN1/Harm the min/max values i get are. 0.2913 - 0.7008
Here is a small video that shows what midi messages the DN sends(example SYN1):
I posted a tutorial yesterday that goes a little deeper into the midi topic.
Hey, found yet another LFO bug on the digitone - The fade parameter does not work on LFO’s in “FREE” mode either!
When you have an LFO in “FREE” mode set to fade out, it simply fades out once and never returns, even when new notes are triggered, until you change the fade parameter back to center/fadein - the expected behavior would be for the LFO to do the fade whenever a step triggers the lfo. The fade in does not seem to do anything at all with “FREE” mode LFOs, where they’d be expected to fade in the lfo modulation when notes are triggered.
It seems the fade functionality has not been properly implemented for “FREE” and “HOLD” mode - this is not just a personal user preference, it makes this LFO functionality unusable with those LFO types.
This behavior is mirrored in the “HOLD” mode issue not respecting fade (that I had mentioned in a prior bug report), compounded by the problem I have also reported with the “FREE”/“HOLD” mode LFO not resetting it’s phase on pattern start, which makes it too unpredictable to use in a track since it’s just luck where in the phase the lfo will be when you start the pattern and that can make a huge impact - Imagine a dubstep pattern with a freerunning lfo, where the “wub” could be anywhere in it’s phase the next time you play it back.
I love the digitone LFOs but these bugs really need to be addressed because it limits what you can accomplish with them and it’s a real bummer
@Cuttlefish That’s actually expected behavior. The fade parameter needs the lfo to be in a trigger mode otherwise it doesn’t “know” when to start fading.
I dont see why this is the case - it would make far more sense for it to just fade the modulation signal whenever a lfo trig is sent (via the trig page), regardless of the mode - it would make the fade functionality usable with all lfo types, increasingly flexibility. Idk where you’re getting that it is expected behavior though, the manual says nothing about it as far as I can see.
It is expected because the lfo has ‘trigger’ modes. Which means it resets (retriggers) on a trigger. Free mode and hold mode do not reset on triggers. On the trig parameter page you can turn off or on if a trig should trigger the lfo. Which also makes it fade if that is positive or negative. There needs to be a trigger that tells the fade to start.
Hope this expansion makes sense.
Yiu could try to work around this by setting the lfo trig to off (on trig parameter page) and then lock it to ON on the step of a sequence where you want the fade to start. This could also be a trigless lock. And set the lfo to trigger mode (second mode).
PS. You can trust me on this. The lfo on the digitakt works the same. It’s just how the lfo responds or not to triggers.
What I am saying is that there is a lfo trig setting on every trig, which, regardless of the lfo type, could be used for simply triggering the fade. It doesnt have to also retrigger the lfo - but allowing the lfo trig parameter to trigger the fading in or out of modulation would expand the usefulness of the fade parameter outside those modes.
For example, when a free running lfo is selected and you do a trig, and that trig has “lfo trig” turned on, that should trigger the modulation from the lfo to fade in/out, but obviously not retrigger the lfo since it is free running - it should just trigger the fade.
When an lfo is in hold mode, the same should be true - a trig with trig lfo on should cause the lfo to be sampled as normal, and cause the fade to be freshly applied to this held value - as it is the fade parameter is bugged for free and hold mode lfos since it simply fades out and never returns - to make matters worse, the hold mode lfo isn’t even fading the held value, its fading the lfo being sampled which is basically undetectable! It’s a flawed implementation as is, and I’m not sure where you are getting the idea that this is intended behavior when the manual just says that fade should cause the modulation to fade in or out, not just in certain modes.
I understand what you mean.
However the lfo trig parameter is there to tell a trig in the sequencer if the lfo should retriggers or not. In free mode this parameter does nothing.
What you want is cool, but would be a feature request. you could try to workaround this with parameter locks though to get a similar effect.
I am saying it should do something - that is the issue. Tying the triggering of the lfos fading out to only certain lfo types is an unnecessary limitation which is not mentioned in the manual or elsewhere, and I’m not sure why you are defending it when it is a clear design oversight.
Unfortunately digitone crashed on me during a livestream last night.
Also found a new bug: copying a pattern from one project to another messes up the AT/BC/MW/PB mod matrix settings. Going to report it today.
Using latest digitone firmware and overbridge on latest live 9. The midi lfo’s don’t respond to parameter locks. Support has acknowledged the bug. Its been almost a year since it worked.
It’s not a bug because that is the way it is intended to function. How you think it should function does not make it a bug because it’s functioning the way it was implemented.
But now that you know it’s functioning as intended, there are ways to contact elektron and discuss/ask for a different implementation.
manual does state
“FRE is the default free-running mode. It makes the LFO run continuously, never restarting or stopping even if trigged by a note.”
“Fade In/Out makes it possible to fade in/fade out the LFO1 modulation. The knob is bipolar. Positive val-
ues give a fade-out, negative values give a fade in. 0 gives no fade in/fade out. (-64–63)”
Notice it doesnt specify only functioning in 3 of the 5 lfo modes, it doesnt specify trig mode being required, it just says it should fade modulation in or out. This function is bugged in the current OS according to that description.
And really, whether you want to get pedantic about if this is a bug or a feature request or not, the current implementation is lame and makes the fade function unusable for many different types of patch, and should be updated to actually fade the modulation signal in or out as it says it should.
you could try to workaround this with parameter locks though to get a similar effect.