So, my only chance would be trying to p-lock pattern change MIDI message in M:S 64th step or something like that? Not sure if M:S can do that 
M:S and M:C canāt send send arbitrary midi PCs, unfortunately. The only thing I can think of is to try something else as master.
Iām not sure but I think other manufacturers send the PCM at the point at which you start queuing the next pattern, to give the slave enough time to queue itself. As Elektron boxes send the pcm just before the change then the slave starts queuing late and takes a full bar to make the change.
Using SH4D as master and M:S as slave reproduces exactly the same issue 
Hi, I found myself in a similar situation sending program changes from a digitakt to an A4 mk1 (also clock and transport) with the delay problem, I donāt know if it has been mentioned before here, but I think I found a solution for the moment with this setup :
-
digitakt is master, if the M.LEN is in inf. configure the CH.len, if not, CH.len to off or the value you prefer.
-
A4: Escale must be in Adv mode, now the value of M.length can be infinity, otherwise the value must be doubled (if the pattern lasts 16 it would be 32, if it is 64=128), the value of chng It must be 2, and the master must be multiplied by 2, which would give a value of 1 to CH.len when receiving the PC.
In this way, the A4 changes automatically when receiving the PC, and does not affect whether the pattern duration is set to infinity.
1 Like
Having the same issue with a DN slaved to OT. As soon as i use scale per track on the DN pattern changes late, no matter what MLEN CHLEN on DN and P.CHAIN on OT. Just to be sure and keep my mental sanity, this is normal behaviour? Shouldnāt there be some sticky post about this?
Makes a lot of sense to me that this thread should stickied or otherwise identified as the definitive place to discuss this ā¦ since it crops up in many different threads.
Moderators ?
2 Likes
I donāt think this is what should happen, but it evidently is what does happen for track scaling between machines. Like I said it feels like a bug. The resolution was to send clock and start/stop midi messages from master but let each machine handle itās own program change (meaning program the song twice)
1 Like
Ok thanks. In my case (some complex idm thing) this is no viable solution for composing. Guess iāll try to embrace the error and quantize to a meaningfull CHLEN with PC delay
This āfixā always falls short and becomes a fail to me when you realise that Elektron devices canāt do this (PC advance/delay sends).
1 Like
Thinking about it, everything regarding elektron sequencers seems built around min 2/16 CHLEN, so i donāt really understand why even with weirdo scaling/MLEN the PC canāt be reliably sent from master and parsed in slave within that 2/16 time frame. But programmaticaly it will probably be much more complex than that (it works reliable w/o pattern scaling though)
1 Like
It should be possible to see if itās a 2/16 CHLEN issue or a message passing time issue by slowing down the tempo. If a slow tempo also fails, then it would seem that there is an underlying assumption between when the pattern change message is sent from the master machine and when it is implemented by the receiver
1 Like
ok did some more tests, seems in my case iām sending way too much note/cc data through the midi cable from the OT. at slower tempi the PC gets picked up, but at faster speeds it either gets completely dropped, or queued for the next cycle. it works slightly more reliable without scale per track, but in busy parts both with or without scale per track the DN slave suffers from PC dropouts.
i know not possible, but would be awesome if we could use the OT thru or USB for clock and PC seperately from note/cc data on the OUT port (and i understand now they donāt want to do scenes for midi, though i think it would be awesome to completely flood and glitch midi with scenes data haha)
Gotta just accept that this will never be fixed. Itās a shame, but it is what it is!
1 Like
in my case itās literally abuse of the MIDI spec, iām like sending 6-8 tracks of super fast arps topped with some CC lfoās 
canāt really blame elektron for that one (unless the turbo midi thing would work between OT-DN, but i assume not)
Anyone still finding this issue with Digitakt and Digitone 2ās? Iām looking to upgrade at some point, would be nice to see improvement, especially with 128 steps and euclidean sequencing now being a thing
1 Like
Hey guys, i was not having this problems with digitakt 2 as master of digitone 1 and syntakt, i could freely make polymetrics, but since upgrade with digitone 2 , i f i set pattern change to 128 and reset to inf i have one pattern late change on digitone 2 , digitakt 2 is changing correctly after 128 steps, 
not cool, i 'm waiting the big update from Elektron soā¦
Please give more detail so we can help you better:
Which devices are in your set-up?
Which device is sending Programme Changes?
What is the Scale setting for the sender?
What is the Scale setting for the receiver which is changing late?
1 Like
Actually testing digitakt 2 digitone 2 combo.
So pretty simple , Ableton midi out via Focusrite midi, digitakt midi in to mid out to digitone 2
If scale mode is set to change 128 and reset to inf on digitakt and ton 2 , digitakt change at 128 and tone change 1 pattern late , if I set inverse change off and reset to 128 on digitone then it change after 128 steps correctly with digitakt . But on my current pattern I have a synth melody in 6 bars ( which is 96 I think ) so reset to inf and change to 128 is desirable
I donāt know how you actually made it work before, but it has never worked for me since as long as I own Elektrons. Digitakt 1 and 2, Digitone 1 and 2 as well as Octatrack.
Always 1 bar late as soon as I use polymetrics.
Their answer to me more than 2 years ago:
There is a known bug that can cause patterns to change too late when the receiving device is in PER TRACK scale mode and the master length is higher than 16. This issue has the highest priority to be fixed, but it is unfortunately complex and time consuming. We hope that a fix can be ready soon. Iām very sorry for the inconvenience.