Thanks, yeah, I try and only use 2 max arps now and it mostly doesn’t happen - still a bit hairy though.
Ah, interesting, thanks for this info and all your effort looking into this.
I usually use the Digitone as a standalone groovebox and use sound locked arps nearly all the time to help make up for the lack of tracks. I’ve had this crash happen when just using two tracks, one with a sound locked arp and the other standard arp. Didn’t occur to me that the sound-locked one could be causing the issue. Have Elektron confirmed this bug?
Think I’m going to stop using sound-locked arps until a fix happens - maybe investigate using midi-loopback instead but have found that a bit glitchy when I’ve tried it before.
When I am controlling a midi channel via Logic through the DT that isn’t 1-4 it will definitely bug out! I am using it as an audio interface as well as a midi interface.
Also the LFO DEST menu can be pretty wonky under certain circumstances, it seems to do it the most when I’m trying to make changes during playback.
From Elektron support:
I also suspect that the freeze could be related to the arpeggiator. As mentioned earlier, we have for a while been hunting a known bug that can cause a freeze, that we know is related to the arpeggiator. We have unfortunately not yet found the culprit, even though our developers have spent a lot of time investigating. We have not received many reports so it seems rare that users experience this bug, but we take it very seriously and I hope we can find a solution soon.
It goes to show not many people report the bugs.
But the problem is broader than the freezing, there is quite a few scenarios (which most user will find themselves in at least at some point) in which it simply doesn’t play back the proper sequence, it’s just that that is easier to not notice, or to falsely attribute to user-error, than a high pitched freezing buzz-kill.
Totally understandable btw I blamed it on user-error (myself) as well when I first noticed it.
Ugh I always assume plenty of people submit bug reports, so I haven’t bothered… I really should send one for this arp bug
We all do
Maybe a good practice would be to report at Elektron then complain here with the satisfaction of the duty being done. We should actually call the thread bug complaints instead of bug reports.
Good practice imo is to complain here, see if other people can reproduce/identify it as user error, then report to support.
So it has a lot of high end on that sound because you added a lot of err? (har har har)
Hope a power cycle can fix it.
Since I upgraded to 1.32 (then 1.32A), I’ve had two instances of entire projects being corrupted. In the first case, a different project ended up overriding an existing project. No idea how that happened. Then, today, using 1.32A, a backup of the same project became corrupted. The sound pool disappeared, there were suddenly only about 50 of the original 128 patterns.
Prior to 1.32 and 1.32A, I never had anything of this seriousness happen. Sorry I can’t provide any other information.
People, backup your work!!!
Yep only since 1.32A but consistenly, on different patches. If i turn the knob a value appears but after a while it goes back to Error.
Are you using MIDI or overbridge to control the Digitone?
I’ve seen this before when the messages sent are out of range; the 'tone shows ERR, mainly on the B operator, if I recall.
On the mixer/Master Overdrive page, FUNC+NO doesn’t revert the settings.
Could this be the same issue as mentioned below for the DT (When Global FX are enabled)?
I was trying to get pure white noise to filter into things. So to do this, from an initialized patch: Algorithm 8, mix all the way to Y, B1 offset to -1 so it cancels out, then introduced feedback to get a pure noise signal. And it workes, but every few presses of a key it freaks out, messing with the harmonics in conjunction with this causes more buggy behaviour. Can anyone else replicate this? Am I being stupid or is this actually a bug? I’m running 1.32a
Just checked this, and got the same result. Amazing source of glitchy noise. Maybe this is just what happens when feeding back an oscillator at 0Hz?
Seems a fair guess, not every path or workflow is bound to be a sweet spot.
Probably wouldn’t hurt to send the question to Elektron to figure out if it’s a “bug” or expected behavior!
Algo 8 is the only one where a single isolated operator can be feedbacked.
Trying to replicate this with another algo (4) doesn’t seem to do the nice glitching.