Pattern change one bar late issue

I just wanted to add that this is still an issue even though I have found a work around.
Why do Elektron is the only company that ‘cue’ a pattern change ?
I mean all the other gear, racks, effects, synths instantly change the pattern an not Elektron ?
Why isn’t there an option for this ?

When for example sending a program change from Ableton, you will need to use a negative track delay for the track/clip in order for the program change to be sent early enough for the Elektron device to have time to cue the pattern.

I call this a bug

When PROGRAM CHANGE SEND is enabled on an Elektron device that acts as master, the program change will always be sent a few ms early so the receiving Elektron device has time to cue the pattern. That’s why it’s working in an Elektron ecosystem.

And this is a shame that it only works between two Elektron devices

1 Like

Yeah, it’s the only thing that really gets me down with Elektron, it’s only in the last few years they’ve implemented both LSB & MSB for bank changes, for years it meant the Octatrack couldn’t send bank changes to gear unless it only used MSB. That used to drive me mad…

Since getting an MPC as my main hub, the pattern change problem has become a lot more significant for me. If using the program change box on an MPC track or automation the Rytm starts 1 step late for some bizarre reason. I think it’s pretty shocking they keep making new devices that inherit this atrocious behaviour. I have a lot of love for these machines but this issue always feels like they’re just taking the piss out of me. It’s such basic midi stuff…

1 Like

Syntakt released but still nothing about this, ew elektron

Isn’t the ongoing issue that other devices send pattern change instructions “on time”, too late to be followed up on when the pattern has already started repeating?

How is this handled better in other pattern-based sequencers if you can’t look ahead?

I’m not saying it hasn’t been handled in other, more controlled ecosystems between devices of the same manufacturer (Elektron obviously sends the change request earlier in the process.)

2 Likes

Don’t plan on hearing anything about it. It’s been an issue for many years with many different types of MIDI controlled sequencers. If you dig you’ll find threads from years ago.

I even made a software solution for Ableton Live to get things to sync.

You absolutely have to send the program change early.

You best bet is to look for an outside solution.

I’ve had thoughts about a master control box. One that could send a set of user defined program changes to multiple boxes at the user’s request.

Only a thought though, I have no plans to make one currently.

Get creative. Maybe you could use something that already exists to send a bunch of program changes when you want?

1 Like

Did spot this one-

Obviously a pricey solution but good to see that there’s been options built into other devices.

I could see an agile team like Squarp working on a feature request.

Still haven’t tested program change with my OXI One yet.

1 Like

MIDIbox Seq V4 also has an option to send program change early.

I bet something like a BOME box could be used to convert a particular MIDI note (for example) to a program change. Then you’d just have to figure out a setup that worked for you.

1 Like

I am using your Ableton Live program when I am at home in the studio and I start my computer only for this… Thank you for this.
But I wish this could be fixed so I can hook my gear and play live what I produced at the studio. Without depending on a computer for that unique function.

I know it does exists some gear but spending over 300€ for this unique feature is not a viable solution for me when I’ve already spent over 1K on Elektron.

2 Likes

Despite the above apparently being a statement from elektron, this is NOT what I’m finding within the elektron system: PCH is not syncing correctly between M:C and M:S when playing, even though PCH works immediately when playing is stopped and making manual changes.

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.

2 Likes

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

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.

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.

2 Likes

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.

2 Likes

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.

2 Likes

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?