I have them both set to INF length and to CHNG after 16 beats, so I thought that should keep them in sync for the changes.
It varies, but I thought ‘16’ makes it change at the end of the current bar you’re in regardless of your positioning within the pattern.
As I said earlier, it works perfectly when it’s working, it’s just when it slips and the A4 stays a bar behind that it’s an issue.
Maybe try length 64, not INF and test that.
1 Like
All I know is, it never werked right. Until I started moving the change message back.
Start with a clean project, default pattern lengths, only change the midi settings, see if it works.
I have the exact same problem with the AR and A4
It works totally fine when you set pattern length to NORMAL. But once you choose to set length per pattern synchronisation is off.
Do you have any of the individual tracks set to lower resolution timings? So instead of 1 do you have 3/4, 1/2, 1/4 or 1/8th?
I found that this caused issues…
Also, for people saying go A4>AR, while that might be more stable I MUCH prefer to have the AR as the master for several reasons (mainly for the ergonomic layout of the AR’s Bank buttons and that it feels more natural having the drums/tempo/beats in control of the clock/transport).
No lower resolutions on my tracks. All 1x. I mean, pattern sequencing is a super simple thing. It should listen to that event and take into account the LENGTH parameter. And that works as long as you are in NORMAL mode. Somehow the ADVANCED mode it becomes buggy.
I remember I had this issue years ago on my DT/DN combo as well. Never gave it much thought back then.
I raised a ticket at Elektron Support.
Let me/us know what they say please…
I have found it way more stable since starting from scratch, and I also have my Digitone changing in sync (AR>A4>(thru)DN)… every so often the A4 will lose sync, but Stopx2 seems to fix it. It’s still not ideal though… I wouldn’t feel confident in playing this live, which is an issue.
Yeah, I’m gonna start blank projects too and if it works try to break it. See where it loses sync. So weird though because it’s really consistent in the way it lags behind. Clearly the pattern change event is received but somehow delayed/queued for a cycle.
Will keep this thread updated.
1 Like
- Pressing next pattern
- New pattern number starts blinking
- New pattern starts
- On other device new pattern starts blinking
- End of pattern it starts the new pattern
The problem here is that the Pattern Change event is not sent when you select a new pattern but when the pattern change takes place. Hence it lags behind a cycle.
1 Like
didn’t solve it. Also hard to start machine together.
Just tried with initialised projects on both machines.
First. Pattern Length NORMAL mode. Perfectly synched pattern changes.
Second. Pattern Length ADVANCED mode. LENGHT 1024 (could also be any other value) and CHANGE 16. Result. Pattern change on slave machine (A4) lags one pattern cycle.
I even kept patterns initialised. Meaning standard 16 steps. No time scale changes or pattern lenngth. All super default. Just changed from NORMAL to ADVANCED mode on Pattern Scale
This must be a bug. A pretty fundamental one if you ask me.
1 Like
Why do you have the length set to 1024?
I don’t know how to do that. The machine sends the PC event, right? I don’t explicitly program it. Is there a way to do that?
There is not. The AF and AR cannot p-lock Program Change messages.
3 Likes
Can OT do this?
For no reason. If you set it to INF I would get a lot of responses saying I should not set it to INF
Hey @martin01 can you reproduce the same issue if you use turbo midi? (I had other weird problems with turbo midi, but not this one.)