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:
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.
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?
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.
2 Likes
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 …
2 Likes