Hi,
I have several track audio and midi. All in 4/16/32 on 16 or 32 … scale 1, 1/2, 1/4 and the total lenght 64. So nothing weird. No swing applied.
After the first cycle, some tracks are delayed like it plays 65 or 66 step …
in major patterns i don’t have such issues but for two it’s a total mess.
What’s wrong ? could ARP had influence ?
i guess its this bug on 1.21
Have had this issue too. Only solution was to can the pattern and start over.
Same here too. Hope they fix soon, I hate losing work/time.
I’m having the same issue, it drove me crazy for a couple of hours until I realized it must be a bug.
Hi all, can it be that the exact same bug prevents correct changing of patterns from digitakt to digitone. I normally let my digitakt change the patterns on my digitone.
I have one pattern with a track that is scaled to 6 steps only. I set the master length to M.LEN parameter toinfinite and had the CH.LEN set to 64 (in order to let it change with the digitakt after one full cycle of the pattern).
But it does not work (well it does, but one cycle to late) when the program change comes from the digitakt.
When I switch patterns by hand on the digitone everything is alright and it works as expected.
When I put back the M.LEN to 64 it works.
Well, works kind of because letting the pattern last longer that one full cycle means the 6-step motif is cut at the end of the pattern and reset with the new pattern start.
Isn´t the what the M.LEN parameter should be for.
I can´t get my head around that. It does not make sense in any way.
If this qualifies as a bug I can stop thinking I would do something wrong.
Thank´s in advance
This just bit me on my very first pattern I created on my Digitone… 
Took me about two hours to figure out that the issue was caused by the “Scale per track” feature. I thought I had some trig condition hiding somewhere that added a step or something (this is my first Elektron device), but eventually I was able to reproduce it with just “Scale per track” and a super minimal pattern.
On my pattern, if I set M.LEN to 32 (the length of the longest track) I get an extra step on the second loop, but if I set it to INF things stay in time.
Really disappointing that this still isn’t fixed… Can someone tell me where I can find/follow the bug ticket?
Not sure what you mean everything should work correctly…
The issue described in this thread is from when it is getting sent a program change…
If you set master length to 32 everything will restart at 32
and that is when it will change patterns
If using inf Pattern length set the Chng to when you want it to change patterns
TheWhistler mentioned program change, but the original post has nothing to do with program change messages and several folks replied that they have the same issue before TheWhistler replied. I think TheWhistler may be describing a different issue.
In my case, I create a simple beat with a note trig on 1, 5, 9, 13. Then I set the pattern to “Scale per track”, setting Track 1 to LENGTH=32/32, SCALE=1/2x, and Pattern to CH.LEN=OFF, M.LEN=32.
Now when I play the pattern, an extra step is inserted between trigs 1 and 5 on the second loop. It’s really obvious if you turn on the metronome since the metronome no longer syncs with the beat on the second loop.
If I change M.LEN to INF in the “Scale per track” settings, then the timing issue does not occur.
It definitely has nothing to do with program change messages in my case, and I don’t think the other people describing this issue (besides TheWhistler) are describing something specific to program change messages either.
I should also say that, frustratingly, I cannot reproduce this every time. It occurred on a somewhat complicated pattern that I was working on, and I have now successfully reproduced it in a very simple pattern. But if I just follow the steps above directly, I do not reproduce it. I think there is some order of configuring “Scale per track” that causes it, but I can’t pin it down. :-/
Yeah guess I didn’t read it properly and I didn’t read every post,
The reason I said that is because it’s the only issue I’m aware of when it comes to scale per track… never had the issue you described
I had this issue yesterday. I started a thread and then deleted it because I mistakenly thought the arp was causing it but I figured out it was because I had a different scale per track. Put it back to scale per pattern and it was all good again.
What was happening for me was on the second play through the track with the arp on it would hang on step one for 2 steps. So with each play through it would get one step further behind.
Nowhere, because Elektron hasn’t such a ticket system in place.
This bug drove me crazy a few months ago when I updated to the latest firmware, I spent well over 2 hours thinking I was missing something obvious and it was my fault.
Hard to believe they haven’t fixed it yet.
This problem is since version 1.21, there is the same problem on the digitakt since version 1.11. To bypass it, copying your patern to another project and copying each data on a blank patern on which you have previously defined the length. then transfer the unbuged patern to the original project.
The problem comes up regularly when you change the scale per track settings.
the bug has still not been fixed since June 2019!
I invite you all to contact the support service so that the Elektron team corrects the bug.
digitone-digitone-keys-1-21-bug-reports
digitakt-1-11-bug-reports
Is this bug fixed with the latest firmware update?
Hello, I just started an account to get info about this issue. I’m getting really frustrated with the Digitone’s (as well as Model:Cycles) inability to effectively play back sequences that use the scale per track function. Although Elektron apparently addressed the issue with the latest Digitone firmware, the issue wasn’t fixed for me. Is that the case for others too?
I bought the Digitone and Model:Cycles with their supposed ability to create polymetric sequences as a major selling point, and I do love many things about them, but I’m finding that this bug is a big one- it greatly hinders the potential of these devices.