sometimes (seemingly more often after jumping from the last slot) song mode will not play the next pattern slot / the slot thats currently highlighted, instead playing the pattern from the previous slot. seems like it can happen more than once in a row
Steps to Reproduce
make some patterns, arrange a song. sry.
may even be a bug in the stable firmware, didn’t test.
project where bug occurs is not overly long (6 slots at time of writing, bug occured at 4), 4 unique patterns, no pattern numbers skipped, all patterns 64 steps long.
i think i have experimented with performance mode track-independent pattern-switching and different pattern lengths in this project - maybe thats a clue, idk. doesn’t seem to happen in other projects (most of them set up on current stable firmware)
doesn’t require being in performance (actually haven’t used perf mode in many weeks/boot cycles since said experiment but did use the arranger in the project since then)
the playback starting point doesn’t seem to matter
if perf mode is involved in triggering the bug its a lot less direct but a lot more persistent
also observed the pattern visualization changing, seemingly showing and playing the same pattern despite assigned pattern numbers being correct. the change seemed permanent, at that point i restarted without saving or checking the pattern data in detail but it looked like pattern data has been overwritten
had to make a link, too big, included invisible “Workspace” folder just in case:
tried to reproduce it before and failed, but had the device plugged in using usb audiostreaming while experiencing the bug - pattern view scrolling was stuttering noticably more and the project is already cpu intensive judging by the indicator, maybe cpu load plays a role
i tested a bit more with the same setup as before (listening via usb streaming at the pc) and captured a picture of the glitch changing how the pattern tracks are displayed (note correct pattern numbers):
i couldn’t really find any rhyme or reason behind what triggers it, except that it seemed like switching between pattern- and song-views using the hotkeys helped triggering it, but not very directly. hard to get it to consistently trigger but staying in song-view and not interacting with the device at all gave me the longest bug-free period (15-20 pattern played without glitch).
robably tested a good 15< mins and got it 6-8 times.
few new insisghts:
seemed most likely to happen when transitioning from the last slot to the first / looping the song
the playback glitches track-wise, basically creating new patterns, a lot more random than described previously
ran a test project, 8 different wavetable instruments and 2 synths playing at once to choke performance, 2 slots, 2 very short alternating patterns, pattern 1 hard-panned to the left, pattern 2 to the right.
so without any glitching the stereo recording should give us an alternating patgtern.
heres a test run without glitches for referecnce (~200bpm, error-free at first try):
note how its immidiately glitching at max bpm, right after the first loop twice in a row. later it becomes more chaotic.
playing fast obviously takes more ressources, i would guess its not the speed itself but the performance impact thats causing the songmode playback to glitch.
now same speed (max), only recorded via line out, not usb streaming:
a lot more stable, takes a few repeats until it fucks up. lot less cpu stress without using the streaming - indicator flashingf yellow/orange instead of constant red.
to me it seems safe that songmode playback skips a few beats when the cpu is at its limit
Sorry for taking long to reply. I’m trying to sort out what to do with this. Would you mind if I rework and edit the Bug Report to reflect the high tempo and your experiments? I’m still unable to reproduce this on my end from the original project.
