Pattern change one bar late issue

FWIW, this is what I found out when trying to sync M:C and M:S, starting out from the simplest possible case, 2 16-step patterns.

1 Like

Can someone explain to me the significance of the auto-channel here ?

Sounds like, for the simplest possible setup (or for M:S <-> M:C sync, where sending PC independently is not an option) the autochannel needs to be used ? Does this mean the sender needs to send on the receivers auto-channel ? Or something else ?

Elektron devices with the same auto-channel set will automatically sync patterns, as opposed to using some sort of program change trig like on a Digitakt, for example. I made that comment before the Model series came out, and I’m not familiar with them personally, but I imagine they aren’t too different in that respect.


Okay, thanks. What I’ve discovered since finding your comment is that between the two models, using the autochannel or not seems to make no difference, you just need sending and receiving channel to match. I’m still discovering other rules that need to be satisfied (like you can’t have mode TRK on the receiver).

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.

1 Like

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.


See the result in video

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:

  • manual pattern selection
  • manual chain construction
  • syncing pattern changes across multiple devices
  • variable length patterns (although I think they messed this up a bit with the different LEN and Ch.LEN behaviors)
  • consistency between manual and automatic behaviours

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?

1 Like

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.

1 Like

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 :wink:

1 Like

Fair point. To say “this isn’t a bug” should not be read as “there are no bugs” :slight_smile:

1 Like

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.