Ran into this problem last night with my OT and DT - by matching the Master Lengths on both units it seems to have fixed the problem (for now) - however I don’t quite understand the logic behind it.
I read somewhere to not use Autochannel for PRG Change so put both units on CH16
Additional info: Model:Cycles as sender does behave exactly the way Elektron replied (before the models existed). It seems to send PC about 0.6 of a step in advance. So the time advanced is shorter for shorter tempos. So for 100 bpm it’s about 270 milliseconds.
Since I don’t own anything other than M:C and M:S, I can’t speak for the other devices.
Finally after almost two years with my MPC replacing my digitakt which was collecting dust I have some good news for you. As a developer I like to solve problems and even though I’ve never work with MIDI I had to try a way to fix it directly at the root.
I connected the MPC midi OUT to my soundcard midi IN and my soundcard midi OUT to my digitakt so I can log the midi messages sent by the MPC and received by the digitakt for debugging purpose.
I’ve downloaded the software MIDI-OX and started to debug… then to applied a mapping.
After some research I found this info which helped me to configure midi mapping. Basically on program change you have to stop the sequencer, change the program, trigger note on and start again the sequencer. I’ve read that some ms were necessary but in my case it was not, I don’t get why it would need, or maye it’s already delayed.
After trying few things I success to transpose it to MIDI-OX, this is the configuration:
I have digitakt midi pogram change in=out to channel 16.
Now it works perfect, when I change pattern on MPC it changes right on time on the digitakt.
Note that I need to have my computer connected to my soundcard with midi going i/o… I will probably invest in a Midihub so I don’t need my computer ans soundcard anymore.
This solution is super easy, only 4 steps needed to make it work again. This bug brought a lot of frustration to the elektronaut community and a checkbox settings was absolutely possible to add in the settings. Trust me I would have prefer to make music during all this wasted time.
ABSOLUTE SHAME ON ELEKTRON.
I hope it will work chaining more midi from the digitakt. It should be but we never now with this box.
Why do you think it’s a bug? The box behaves consistently whether you press the buttons with your fingers or with MIDI.
If you’re jamming out and manually try to change patterns the instant the bar is finished, it’s going to queue up the change and only switch after it plays through another loop, right? Same thing with MIDI.
You’re expected to manually change the pattern before the current bar is through so that it gets queued up and switches seamlessly. Same with MIDI.
If you screw up your timing and end up with a queued pattern change when you wanted it to switch, one manual work-around you can use to switch to the queued pattern “instantly” is stop-and-start playback. Same with MIDI, as your tool demonstrates.
All this seems to work exactly as I’d expect. No need for shame or recriminations. And I certainly wouldn’t want to see this behavior patched or changed by the devs such that MIDI worked by a different set of rules than the physical controls.
Luckily, the behavior is flexible enough as is that tools like yours are possible without any such patch.
I am not saying that my solution is the best and this exact solution should be implemented in the settings. Mine is just a workaround which is absolutely fine for what I’m doing.
Also I can’t propose any other solution as the digitakt OS is not open source. I am sure they could develop a proper solution and if it doesn’t suits to you, you could deactivate it in the midi settings and find your ‘normal’ scenario with queued patterns.
I’m pointing out how easy it was to find this workaround so working with the code source should be even easier to propose a settings that instant change pattern instead of queuing.
I’m sorry to repeat my self but yes this is a shame that a 700e machine doesn’t pattern change at the right moment when triggered by a non-elektron.
This just remind me Apple who want their user to stay in the same eco system for their gear to work. And I absolutely hate this behavior.
The problem encountered was not a bug, however, the proposed technique may be useful for fixing at least one other actual bug (or VERY undesirable feature) with elektrons, notably a working M:S <-> M:C sync setup can be made to stop working only by changing scale mode to TRK, nothing else.
What would you call it then?
Just that it is what it is and you shouldn’t expect to be able to sync/use program changes with an Elektron device with anything other than another Elektron device?
So, Elektron workable PC’s are only exclusive to Elektron devices?
It’s clearly a design decision.
The pattern queuing allows for all of these:
The MIDI spec doesn’t define how to produce pattern change behaviour. IIUC it has passing suggestions for options, but leaves the details up to each manufacturer.
Getting them all to agree one system, after they have multiple instruemoents already in the wild, seems like a big ask. Does anyone know if the new MIDI2.0 even has a definition for pattern seitching?
Another way of putting it: Elektron workable PC’s are exclusive to devices which can send advance notification of pattern change (which includes elektron devices and possibly some others ?)
Example: Model:Cycles sends PCH 0.6 of a step early before pattern change.
EDIT: Quote from an elektron support ticket: the program change needs to be received a few ms before the pattern change is supposed to happen
Yep, I get all that side of it. I really like the complexity of them standalone, the variable pattern/track lengths in particular, and I generally use mine standalone (or OB’ing to Ableton) these days.
Honestly, I’m long past expecting my (6!) Elektron units to work with anything else on a Midi Program Change basis, so when it pops up in threads like this it’s just a bit of a reminder how that side irritates me slightly… I’d love to be able to work standalone with my MPC and Analog Four/Digitone, knowing that I can change sequence on the MPC and have them follow… the same way I can with the TR8S/MC707, or sequences on my Sub37, etc, etc…. But it is what it is.
I’d say, ideally, you should expect to trigger behavior via MIDI in exactly the same way as you trigger the behavior physically.
In the case of changing a pattern, that means you should select the pattern at least a beat or two before you want the actual change to happen so that it “queues up” and starts flashing, ready to change.
I can understand your frustration if you’re using a sequencer that limits when you can send certain MIDI such that you can only send PCs exactly on the bar or something. But that’s a limitation of that sequencer, not a bug in Elektron’s. The Elektron is accurately exposing the behavior it always has (and likely always will have) via its MIDI interface.
At any rate, this isn’t a “you can’t use Elektron device with anything other than another Elektron” thing. I use my boxes with plenty of non-Elektron sequencers, both software and hardware. The only requirement is that you are able to send messages to it as if you were playing it live — which is the whole point of MIDI in the first place.
Still, the PC is bugged.
Even between Elektrons machines which were supposed to behave the same way.
It works perfectly fine as long as you don’t use track length and so on.
Here is their answer when I sent a ticket regarding this problem 6 months 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.
To be honest, as nice as the customer service is, I believe they also just tell you what you want to hear. Truth is, I asked 6 months ago and nothing happened, and I’m sure the request was already made years back …
That’s the thing: Elektron boxes absolutely will pattern change at the right moment when triggered by a non-elektron. The question you should be asking yourself is, “for this device, what is the ‘right moment’?”
When is the right moment to trigger a pattern change on an Elektron sequencer playing another pattern? A beat or two before the current pattern reaches the end of its loop. Send the PC then (again, exactly when you’d normally press the button yourself if playing live) and you will have no problems whether your sequencer is made by Korg or Squarp or whomever.
Now maybe you don’t like the way Elektron queues up pattern changes like this? Maybe you feel it’s a shame that they don’t all have the Direct Start and Direct Jump modes of the A4, for example? That seems a reasonable thing to want from a 700€ box! But it has nothing to do with MIDI or bugs or manufacturer lock in.
And you’d have better luck asking for that feature you wish it had rather than insisting they fix something they clearly don’t even think is broken 
Fair point. To say “this isn’t a bug” should not be read as “there are no bugs” 
Yes yes, I was not going against what you said.
I agree with you that most of it is the intended behavior, and from a logical point of view, it makes sense. But yes, aside from this, some other logical behaviors don’t happen the way they should.
How can the elektron know when a pattern change is coming? If the two sequencers are in sync, the pc message will get to the elektron late. They would have to implement a direct change witch would mean that it starts to trigger the old sound, but immediately change. That would sound glitchy. Or they would need to introduce a fixed latency so it could get the pc message when received from another sequencer.
Totally. I’ve just got the COVID and have nothing to do but sit around replying to everything 
This is the cop out answer that frustrates and annoys a lot of people, myself included, who are otherwise really happy with their Elektron devices.
In this day and age, you shouldn’t have to stand on one leg while patting your stomach to make a device change in time with everything else. (You know, jump through hoops and make specific allowances on other machines).
@hazer posted a way around this in 4 steps.
His point is correct. If he can do it, really Elektron should be able to do it within the boxes.
A check box that made this happen, maybe at the temporary expense of other timing:Ch.Len options would be fine by most people who have a problem with this I think.
Now, honestly, if you asked me- do you want this functionality to work seamlessly in sync with other devices, but have to full sacrifice the master and per track/part seq length options, I would probably say no and stick with what I have now.
(Hope the Covid’s not too bad, btw 
).
Do these “everything else” boxes have chains you can make and unmake on the fly?