Did they say what the reasons were? I recently encountered this phenomenon and I thought it was a bug.
The explanation from Elektron is in the quoted text.
I wonder what those ādifferent reasonsā that they mention are.
Digitakt OS 1.30B was released Feb 02, 2022.
āOS 1.30B has a few important bug fixes like fixes for parametric EQ clipping, syncing issues with Overbridge, delay routing issues, lost parameter locked LFO destinations. For a full list of changes, see the release notes.ā
I updated from 1.30 to 1.30B via Transfer. The file uploaded and once completed the DT got stuck at āOS Upgrade success! Rebootingā No progressing bar or flashing LED.
I waited several minutes and decided to power cycle the DT. Then it displayed āUpdating bootstrap, donāt switch offā Once this succeeded it asked to reboot, which I did, and OS 1.30B was successfully installed.
So, itās either a bug getting stuck after the first update stage where it says āRebootingā or it should rather read āOS Upgrade success! Please Rebootā
1 Like
Yes, wrong text IMO on all Elektrons.
Not sure if this is a setting somewhere but I seem to have some strange behavior when turning on the DT. Every time I power on, it goes to the same state that it was in when I last updated the firmware (1.30B). No matter what changes I made, how many times I save my changes, or load other projects, itās always stuck on that previous state of that project upon powering on.
This means I canāt shut down and resume without always having to save the project first and then after powering on, I must reload the saved project again. Annoying and not conducive to the way I like to work.
Has anyone seen this? Iām able to update the state that it wakes up with if I make changes and then reinstall the firmware.
Did you try to do a factory reset? (and repopulate the DT with your projects via Transfer?)
I started to do this, then I realized it was going to take hours to export all of my projects, as I have all 128 slots filled. Going to try doing that soon.
After backing everything up, I did a factory reset. This seemed to successfully reset the 1st project (preset project). However when I shut down and turn back on, it just reverts back to the previous state it was in that I mentioned before.
I then tried formatting the drive completely (samples+sounds and projects), doing the āEmpty Resetā and then āFactory Resetā again. Everything is cleared properly and reinitialized. When I shut down and turn it back on, it reloads the same state that it was in before I updated the firmware. Strange!
Ok, thatās strange. I would contact elektron support for this!
1 Like
I donāt know if this one has been mentionned or detected :
Iām often using a ārandom lfoā assigned to āsample startā, so when a note is being played, it could start at any place in the sample (mostly 10-30 secs samples). It usually works fine, but it often get stuck in a loop (always playing the same sections of the sample so it becomes predictable).
Is this unusual? Is there a way to avoid it?
The LFO depth might have in that case an impact on the range around the default start point where the random value is picked from, no?
I would imagine that your depth is currently low which would explain why the start point feels to be limited to a certain area.
These are just guesses but that would make sense.
edit: I just tested and indeed, the depth limit the range for the random value to be picked from around the original value.
I guess if you want a random start from the entire sample, you should place your start to 60, and then your random LFO with a depth of 60.
1 Like
Thanks for the follow-up. Yes, I do start the sample at 60 and use a depth of 60 with the lfo. As I mentionned, itās usually working fineā¦ until it doesnāt (then it locks to 3 or 4 values and it sikcks with it, until I turn the whole device off/on).
Since we are here : That same trick (random lfo set at starting point) does not work when the sample is set at reverse loop. I think it just plays small bit at the en of the sample.
I really donāt understand why it does behave like this (??).
I am experiencing some weirdness when sending midi clock: Digitakt also seems to be sending out Sysex start (240 or hex F0) immediately followed by End of Sysex (247 or hex F7) repeatedly. It goes away when I turn sync off. This happens over USB both in midi and midi+audio mode. Not tried with Overbridge on yet. I have never used Overbridge in fact.
Just realised I should have checked the midi din port as well but too late now. Will check tomorrow. Just wondering if anybody else can check? Iām also experiencing data drops (on note data) in the incoming midi stream from DT over USB. Again, only when DT sends out midi sync messages.
Sorry if this has been brought up before but in that case Iāll just file a bug report with Elektron.
You are sure you donāt have a MIDI loopback somehow by sending back the clock to the DT?
Good question, but no. This is only DT sending out data, with inputs disabled. I just checked and itās on the MIDI DIN port as well. There appears to be four pairs of Sysex Start/End messages per clock tick, but not consistently. Itās nevertheless a lot of bandwidth taken up for what seems to be essentially noise.
I checked on the Model:Cycles too, and it doesnāt do this, except when you press stop. Then it sends out 4 pairs of sysex. This isnāt machine control or anything like that, but there may be some kind of reasoning behind itā¦ who knows.
Anyway, I would be nice if anyone could confirm this. There are midi monitors (some times called loggers) in DAWs, or you could use Midiox or similar software.
The messages you are looking for are:
F8 or 248 - midi clock tick (what you want)
F0 or 240 - sysex start
F7 or 247 - sysex end
I wouldnāt mind so much but Iām gettimg dropped and stuck notes when this happens, and itās on the DT output, so thereās not much I can do about it.
Alternatively, do any of you get stuck or missing notes when sequencing external gear from the DT while sending MIDI clock sync?
A few long-standing bugs Iāve noticed that Iāve not seen mentioned elsewhere:
-
MIDI trig page ā no restore available with FUNC + NO.
-
MIDI pages ā no randomize function (intentional? If so, why not? Inconsistent with audio pages).
-
Trigs donāt blink when trig page functions are Plocked. Iāve read this might be intentional but Iām really not sure why - seems inconsistent and confusing to me. Would be especially useful when you want to see which trigs have trig conditions. Did this used to work maybe?!
-
Labelling inconsitency ā on the scale setting for MIDI tracks, the tracks are labelled MID 1-8. Everywhere else on the machine and documentation, theyāre MIDI tracks A-H.
Cheers
10001
2 Likes
