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.
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.
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.
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.
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.)
Turbo speed doesn’t even switch on on my devices…
Sorry if this is a granmother/egg situation, but have you connected the ins and outs of both devices? ( I had to double check the manual for that, or someone on this forum told me…can’t remember which.)
The issue is very simple. It works in NORMAL mode. As soon as you turn on Pattern Scale ADVANCED mode it doesn’t. Nothing to do with Turbo.
I got an additional repsonse from Support;
Sorry, after looking into it a bit more I realize that I got confused for a while - and you are of course correct. Whenever a program change is received the device will cue the corresponding pattern. The change will happen based on the state of the receiving device, just as if the pattern was cued locally. If the pattern setup is equal between two devices the behavior should be identical. The behavior you describe is a bug and I will immediately talk to our developers about it. Thanks again for reporting!
Hey, I was just curious if you tired it with turbo, I have found my units better sync’d in turbo mode, I was only trying to help.
Thanks for following through and posting the response for support. Much appreciated.
My bad. I didn’t mean to be rude. Really appreciate creative solutions. 
Say what? That makes less sense than their original comment. How can the receiving device know that the sending device has hit the end of its CHNG cycle?
Or am I missing something?
I guess the end of the sender’s CHNG cycle (or slightly before) is the moment when the pattern change is sent? If the sending device is readying a pattern change, it will (or should) send that PC message out to other devices near the end of the cycle so the receiver will get ready to change too. Right?
This is the important bit regarding the receiver: