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.)
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?
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.
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.
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.
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.
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 quicker tempos.
Since I don’t own anything other than M:C and M:S, I can’t speak for the other devices.
EDIT: dodgy arithmetic removed.
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.