Program change messages not handled as expected

First of all, since this is my first post in this forum, hello everyone!

So I (finally) received my Analog Rytm yesterday, spent the evening learning the basics and jammed with the machine for a couple of hours.

One feature that is very important to me is the “Direct Jump” pattern mode – actually it was a major reason to buy the AR.

It’s great for building “lively” rhythms that are composed of multiple patterns that you “juggle” with to create variations, insert fills, and so on.

Pattern changes via the AR panel mostly work as expected - the new pattern starts playing immediately at the current position/step.

For some reason, “sometimes” – I have not yet figured out how to reproduce this reliably – the new pattern is queued instead of being activated immediately (the pattern number display, e.g. “A01”, starts blinking in this case).

Selecting the same pattern again when this happens activates it immediately so this is not a showstopper, just a bit annoying.

This morning I hooked the AR up to my PC via USB MIDI in order to record the MIDI events which I expected the AR to send when changing patterns via the panel.

That’s when I hit a brickwall:

The program change events (on channel 14 by default) are not being sent as expected.

Apparently the AR only sends a ProgChg when the first step of a pattern starts playing for the first time after a pattern change.

This means that if, for example, you have a 16 step sequence where pattern A01 plays for the first 8 steps, then you change to pattern A02 to play steps 9…12, then to pattern A03 for the remaining steps 13…16, the AR does not send any program changes at all!

I tried different “CHNG” settings in the advanced scale menu but that didn’t fix it.
All patterns have the same scale settings, btw.

Transmisson (and reception) of program change messages is enabled, of course.

Is this a known issue ?

There’s another thread on this forum Receiving Program Change Messages Not Responding Immediately that addresses a similar/related topic.

What worries me is that Elektron released a firmware update one month after the other program change issue was reported and apparently the update did not address/fix it.

I have two weeks to return the AR. I like the machine but (at least for me) the program change issues are major showstoppers.

Is this still being worked on and will this be fixed in the next update ?

2 Likes

This is a known issue but not an easy to solve and not something that will be solved soon.

The MIDI standard was not developed to handle this and using program change for pattern change is already outside how the MIDI standard was set up.

I agree that sending program change when changing patter during direct change would be good. But some DAW and machines needs to know this before since they need some processing time. This is why the AR and all Elektron units only send this out when it knows that it’s going to change pattern and the program change is actually sent out before the pattern has ended. This is the current solution and it makes the machines compatible with the most DAW and Machines but the issue you are describing comes with this compromise.

I hope this clears things up a bit about why Elektrons machines behaves this way.

/Olle

1 Like

Actually, the MIDI standard intended program changes exactly for this kind of application (“a drum box may use Program
Change to select a particular rhythm pattern”).

For practical purposes, changing patterns in response to a note-on (as an optional alternative) would be nice, though.

I also don’t see any issue with the AR sending the program change a little bit in advance.

Other equipment may need the time it takes to play a step or two in order to prepare for the change.

The problem in the scenario I described above is that the AR sends out the program change far too late or not even at all!

The AR can clearly handle “instant” pattern jumps when the feature is used manually.

All I am asking for is that instead of always having to manually press buttons on the AR, I want it to send out a MIDI message the instant that a pattern is selected manually in ‘Direct Jump’ mode, and vice versa react to such a MIDI message just like the actual hardware buttons were pressed.

This problem should not be hard to solve at all.

If, for some legacy/compatibility reasons, the devs don’t want to change the way the current program change implementation is working, they could add a configuration option to enable/disable immediate program changes and simply leave it disabled by default.

If, for some legacy/compatibility reasons, the devs don’t want to change the way the current program change implementation is working, they could add a configuration option to enable/disable immediate program changes and simply leave it disabled by default.

This is the reason and your suggestion is what have been discussed as a fix. But what I’m saying is that this is not a quick fix and with it comes some conceptual questions. The developers are aware of it but there is no time schedule.

(reply to customer support)

Hi Olle,

sry, in the forum I did not realize that you are part of the Elektron team.

Thanks for the honest answer. Better this than broken promises :wink:

I’ll keep my AR, anyway. It’s a lot of fun to play and the user interface is very well done.
Last but not least - it sounds good!

Although I don’t understand the exact nature of these compatibility issues,
I have to accept that you have good reasons to not change the program change
behaviour as it is right now.


However, maybe there’s another solution to this:

You could add a sysex message for button presses and releases.

The AR would sent out this message each time a button is pressed or released.

When it receives such messages, it would act like the actual hardware button were pressed/released.

I just had a look at the sysex data the AR currently sends out.

Apparently each message starts with a standard header (F0 00 20 3C 07 00), then the next byte determines the message type:
52: kit
53: sound
54: pattern
55: song
56: (recv’d with ‘all’)
57: global

So what you could do is add a new sysex message type ‘60’:

F0 00 20 3C 07 00 60 F7

<btn> would be the button 'id'. The AR has 69 buttons (including push-rotaries and pads) so the range would be 0x00..0x44.
      It would make sense for the enumeration to start at the top left button (FX) and end with the bottom right one (Page).

<ac> (short for action) would determine whether the button is pressed (1) or released (0).
      (maybe also (2) for press+release?)

I’d suggest that the sequence can be repeated up to say 4 times (for combos).

Applied to the pattern change issue, the following message would select pattern A/E 03 of the current bank group (A…D or E…H):

F0 00 20 3C 07 00 60 2B 01 2B 00 36 01 36 00 F7

(assuming that $2B (43) is the id for the A/E button and $36 (54) the id for the ‘Step 3’ button)


I also want to share another completely different idea how to approach this ‘pattern juggling’ workflow.

I’ve created a new thread (‘pattern juggling / rearrange recording’) for this because it has nothing to do with program changes or MIDI messages.
(the basic idea is to let the AR record the replayed steps into the pattern clipboard)

Greetings,
Bastian

I am experiencing a problem when working with the Analog Keys and the Rytm together.

Rytm is the source of the program change
Keys is the receiver.

It works instantaneously if the speed is set to 1x, but if you pump it up to 2x, keys will queue instant of change instantly.

I think it has to do with when the program change is sent. I am sure a few ms buffer are needed to change pattern

I have submitted a ticket for this.

Hi people,
so the problem still exists :(((

I have a MPC 1000 with JJOS (But it also happens in my ableton setup) and a Analog 4 and a Rytm set to slave.

If I change the pattern on the MPC, and send a Program Change to the elektrons, they will follow, but always one pattern too late…

If the MPC is set to slave though, it works, but I need it the other way around…,

The only solution on my horizon at the moment would be having an external midi clock (no pc) with a through function, so i could send the program changes when I need them. But that means at least two new devices…

Couldn’t you just add a new change mode for older Master Clocks?
So that it puts the Program change in the memorey directly and changes directly after the currently running pattern is finished instead of starting it from the top once more?

Hello Lovely Elektronauts,
since there were no replies to this problem yet, has anybody found a solution in the meantime? :slight_smile:
Sorry for bumping this topic again, but it’s making my work so hard at the moment :wink:
Cheers and thanks for any answers!

Diego, running in to the same issue (except with a 2500), I’ve been programming individual pattern changes as midi events a bar ahead of where I want the pattern to switch. Huge pain compared to having an instant pattern select command (MD got this perfect, imo) or even having the built in JJOS one just work… but it’s been working so far.

I’m still experiencing this issue with the current firmware. Has a solution come about?

Hi Guys, the only solution I found was sending the Program-Changes from a third-party instrument in the middle of a pattern:
In our live-setup without computer, we use a behringer x32 as our main mixer. That mixer can send program-changes as well.
If you send a program-change in the middle of a pattern, the octatrack, the rytm and my mpc all change the pattern on the next 1 of their pattern.
midi goes like this: x32 -> rytm (Through)-> mpc1000 (Through) -> prophet (Through) -> octatrack (Through) -> nord waves

It runs OK, but it is a little un-musically (as we say in germany…) since all sequencer-instruments have to have the same pattern lengths…
And you really have to practice sending the program changes at the correct moment, otherwise you’ll screw your loop.

Adding alternative triggs and mutes always helps musically. And after all we want to play our music, no only program it. Still annoying, that it doesn’t just work.

Proof that it works: www.vimeo.com/209549104 (that’s a short video of our live-set without computers :slight_smile: )

Cheerio

Problem is still here and feels like a bug, because:
Even if you put your rytm to PTN direct Jump Mode, it won’t change pattern immediately if you send a program change from an external source. It will if you change the pattern on the machine itself immediatelly, but not if you do it from an external source.

I think this whole PTN direct Jumb, PTN Change problem is a bit bigger then expected. Even my MPC on its own handels it veeery strange (you could say wrong), if the pattern on the mpc you want to jump between have different lengths…

Hopefully one day somebody will make the maths… can’t be that hard, can it??? :wink:
Still LOVE YOU Elektron!

Please elektron find us a solution, it is an essential function for some for the live …

+1 this needs to happen!

You can buy a Sequentix Cirklon which has a setting specially to send program changes early to Elektron machines so they change when expected.

If Sequentix figured it out, I wish Ableton could do something similar then!

After reading all these various threads on pattern changing issues, not to mention OB, sync, latency, etc. I’m about ready to give up and play acoustic guitar, or maybe even something more simple, like tambourine. :cry:

Would love to be able to compose/jam drum parts on Rytm, use p-locks, etc. and then arrange a larger song in Ableton, tying together my Rytm, other hardware gear, and virtual instruments. Horizontally along the Arrangement view I wish to have a track of MIDI clips that send messages to my Rytm to change Patterns accordingly with various parts of the song (intro = A1, chorus 1 = A2, etc.). But doesn’t seem to be able to do things in sync. Rytm always goes wonky.

The Rytm has been around for years now, Ableton seems to be Elektron’s preferred DAW to support, at least with OverBridge. So, why is this still such a hassle/impossibility? Am I missing something? Maybe it’s just not a very popular workflow? Am I the only one still trying to make this work? Anybody else?

With Live you could try to set up a separate midi track for program changes and pre delay it. It’s always tricky syncing a computer though, since they’re not dedicated hardware.

3 Likes

This is exactly what I do, -60 ms delay for the dedicated program change track in Live does the trick!

[quote=“Olle, post:4, topic:6560”]
This is the reason and your suggestion is what have been discussed as a fix. But what I’m saying is that this is not a quick fix and with it comes some conceptual questions. The developers are aware of it but there is no time schedule.[/quote]

Multimap exists in other Elektron boxes, which allows you to trigger patterns from MIDI notes… Come on Elektron!!!

I have it set up in Live so it works as has been discussed in various threads already. Set the launch quanitsation of the clip with the program change to None, and set the CHNG parameter in the AR to 16 and set it to Direct Jump.When I launch the Live clip with the PC, the jump happens on the next beat, which is as “immediate” as i need it to be… otherwise your’re entering syncopation territory which will be impossible to achieve unless we get pattern changes with MIDI notes instead of PC. . . Where is Multimap ?