Xform PC -> Stop, PC, Start

Hi there. First post.

I bought midihub to fix a bug in Elektron’s Analog Rytm where they don’t process Program Change immediately. After years of users complaining, they’ve done NOTHING. Totally LAME. Especially since a physical button on their device can immediately switch programs.

It was suggested on Elektronauts that a midi event process could fix this by doing the following:

When receiving a PC, transform it into this specific sequence of events:

Stop, send PC, then Start

That would force the AR Rytm to stop, receive the PC, then Start again from beat 0.

I’ve tried to program a pipeline for the last hour with my midihub and …

I don’t appear to have control over event sequencing.

From MIDI A -> Transform1 PC to Stop and send pass-through -> To Virtual E
From Virtual E -> To USB A.
From Virtual E -> To MIDI A

Midi monitor confirms that an incoming PC transforms to Stop then send PC messages are operating correctly IN ORDER.

Now, as far as I can tell, I need to grab the PC coming out of Transform1 and do something with it.

If I pipe it into another Transform2 block, that doesn’t work because it either sends PC AFTER Start, or it consumes PC and doesn’t send it.

So I’ve got to do stuff in parallel. (I think)

So I create a parallel path:
From MIDI A -> Transform2 PC to PC don’t pass-through -> Transform3 PC to Start don’t pass through -> Virtual A

(remember, the other parallel path is handling converting PC to Stop then PC send)

Transform 2 is - well it SHOULD be acting like a delay pass-through and THEN Transform 3 sends Start.

The resulting message is Stop, Start, PC

I CAN’T GET PC TO COME BEFORE START. For over an hour I’ve created parallel messes trying to get midihub to order a SEQUENCE of events.

There must be some priority code somewhere that is forcing PC to be sent after all messages?

Any help?

Again it’s frustrating because I’m doing software work that Elektron should do but they are an intransigent company most of the time and they are never going to fix their Analog Rytm PC problem.

Here’s another attempt:

From MIDI A -> Transform PC to Stop w/ pass-through -> Transform PC to PC w/ pass through -> Transform PC to Start w/ out pass-through -> VirtA

Virt A -> USB/MIDI A

The resulting sequence is START then STOP

Absolutely does not honor any left to right/first to last sequence I have on the screen. (in addition to not sending PC).

Why would it reverse the order of the events on the screen?

Try #3… okay I tell myself, midihub queues up events in the OPPOSITE order it is on the screen.

So I do this for my serial transform pipeline

Transform1 converts PC to Start w/ pass-through
Transform2 converts PC to PC w/ no pass-through (transparent conversion)
Transform3 converts PC to Stop

Result: Stop, Start

Okay! I confirmed it’s back wards! Is it supposed to be backwards? Why would it be backwards?!

FILO - First In Last Out?

So now I try this in serial

From MIDI A:
Trans1 converts PC to Start w/ pass through
Trans2 converts Start to Stop w/pass through

Okay… so based on the FILO experiment working, what am I going to get?

Sequence: Start, Stop, Program

So wait… it’s not FILO


“Pipeline” is a term that generally describes sequences in computer engineering.

Why do these pipelines appear to not be sequential?

No idea about Midihub’s internal architecture, but the order might have something to do with Start and Stop being real-time messages, whereas PC is not.

If I could get consistent behavior I’d have an easier time debugging it. These events have no rhyme or reason to me.

Good idea on the real time vs control messages. But wouldn’t a real time message be interpreted to be sent in order that it’s written on the screen (left to right)?

v1.11.4 didn’t change anything.

If I had to hazard a guess, when events get queued up into Virtual Channels, there is some logic that is re-ordering them based on type or preference or some if/else block with a priority set that not honor the input order they are sent in.

or maybe there’s no events at all - even though they are called pipelines - they don’t handle sequential events and everything is just happening “at the same time” and midihub just crams together the events in any order it wants to.

Bad first experience after waiting months and months to work around Elektron’s problem.

Great guess! Midihub does give real time data more priority, as suggested by the MIDI 1.0 specification:

To help ensure accurate timing, System Real Time messages are given priority over other messages, and these single-byte messages may occur anywhere in the data stream (a Real Time message may appear between the status byte and data byte of some other MIDI message).

We’ll add a flag to Transform pipes to allow disabling the higher priority of the produced real time messages, and another flag for controlling whether the generated message should go before or after the original event. This will allow you to achieve what you’re after.


Thank you so much for attempting to accommodate my weird request.

Unfortunately, today I confirmed it’s not working as I had hoped for me.


App: 1.11.5
Firware: 1.11.7

My PC is being transformed into STOP START PC instead of STOP PC START.


Goal: Sync AR Rytm mkII to MPC Live with MPC being the clock and song and beat switching master. But still utilize the AR’s internal sequencer as its own beat sequencer.

  1. Download newest app and firmware.
  2. Open example pipe to test - the one provided.
  3. Turn off all filters - because I need to send Clocks and MMC start/stop/reset commands
  4. Hook up Midihub’s USB input to my MPC Live output and MIDI OUT A DIN to the AR Rytm mkII
  5. Sync fails on beat change.
  6. Hook up MIDI OUT A DIN to MOTU Micro Express and monitor with Mini Monitor on Mac OS.
  7. Observed PC xform to STOP START PC

Please let me know if there’s anything I can try to break it down more clearly or if there’s a variable I can remove to help debug it.

Thank you

Some more details with setup notes and midi message log from Midi Monitor

Default Preset Example for PC Transform Loaded into Midihub Preset 1:

MPC Live -> USB -> MidiHub -> MIDI DIN OUT A -> Micro Express -> USB -> Mac -> Midi Monitor

  • Using default preset

  • Start at intro of the song, press Play Start

  • Then move through 4 sections of the song

  • then back to the intro

21:23:12.406 From Sync Port Stop

21:23:12.406 From Sync Port Start

21:23:12.406 From Port 1 Program 14 3

21:23:16.509 From Sync Port Stop

21:23:16.510 From Port 1 Program 14 3

21:23:16.510 From Sync Port Start

21:23:32.919 From Sync Port Stop

21:23:32.920 From Sync Port Start

21:23:32.920 From Port 1 Program 14 4

21:23:49.055 From Sync Port Stop

21:23:49.056 From Sync Port Start

21:23:49.056 From Port 1 Program 14 5

21:24:05.189 From Sync Port Stop

21:24:05.190 From Sync Port Start

21:24:05.190 From Port 1 Program 14 3

Example with same preset all filters on Midihub turned off - i.e. no messages are filtered and the PC is passing through the transform blocks - same pipe, just adjusted the filters… Note: Clock messages filtered within Midi Monitor so the we don’t get spammed:

21:27:04.696 From Sync Port Song Position Pointer 0 0

21:27:04.697 From Sync Port Song Position Pointer 0 0

21:27:04.703 From Sync Port Stop

21:27:04.701 From Port 1 SysEx Universal Real Time 12 bytes F0 7F 00 06 44 06 01 00 00 00 00 F7

21:27:04.704 From Sync Port Start

21:27:04.704 From Port 1 Program 14 3

21:27:04.706 From Sync Port Start

21:27:04.705 From Port 1 SysEx Universal Real Time 6 bytes F0 7F 7F 06 03 F7

21:27:08.805 From Sync Port Stop

21:27:08.806 From Port 1 Program 14 3

21:27:08.806 From Sync Port Start

21:27:25.215 From Sync Port Stop

21:27:25.216 From Sync Port Start

21:27:25.216 From Port 1 Program 14 4

21:27:41.351 From Port 1 Control 14 Bank Select 1

21:27:41.352 From Sync Port Stop

21:27:41.352 From Port 1 Control 14 Bank Select (fine) 5

21:27:41.353 From Sync Port Start

21:27:41.353 From Port 1 Program 14 5

21:27:57.485 From Sync Port Stop

21:27:57.486 From Sync Port Start

21:27:57.485 From Port 1 Program 14 3

21:28:00.897 From Port 1 Control 14 Hold Pedal 0

21:28:00.642 From Port 1 Control 14 Hold Pedal 0

21:28:00.643 From Port 1 Control 14 Hold Pedal 0

21:28:00.644 From Port 1 Control 14 Hold Pedal 0

21:28:00.645 From Port 1 Control 14 Hold Pedal 0

21:28:00.646 From Port 1 Control 14 Hold Pedal 0

21:28:00.647 From Port 1 Control 14 Hold Pedal 0

21:28:00.648 From Port 1 Control 14 Hold Pedal 0

21:28:00.649 From Port 1 Control 14 Hold Pedal 0

21:28:00.650 From Port 1 Control 14 Hold Pedal 0

21:28:00.651 From Port 1 Control 14 Hold Pedal 0

21:28:00.652 From Port 1 Control 14 Hold Pedal 0

21:28:00.653 From Port 1 Control 14 Hold Pedal 0

21:28:00.654 From Port 1 Control 14 Hold Pedal 0

21:28:00.655 From Port 1 Control 14 Hold Pedal 0

21:28:00.655 From Port 1 Control 14 Hold Pedal 0

21:28:00.659 From Sync Port Stop

21:28:00.913 From Port 1 SysEx Universal Real Time 6 bytes F0 7F 7F 06 01 F7

Hi, please attach the preset you’re using.

Good idea. Of note, I made sure to load these from the preset memory of midihub - i.e. these should be the exact preset used for my logs above.

ProgramChange to Stop ProgramChange Start All Enabled.mhp (368 Bytes) ProgramChange to Stop ProgramChange Start.mhp (368 Bytes)

The only changes I made to the provided example was to put the output on MIDI DIN OUT A instead of USB. Then on the second patch that is the second log, I turned off all the filters in the filter block - labeled the patch “All Enabled”

I’m not sure what your main goal is but I have Stop>PC>Start messages in this order every time with your Preset. The only thing I have changed is routing In/Out.

@elektrode, I tried reproducing the issue using USB-only on both Windows and macOS, as well as monitoring DIN-5 MIDI using Midiboy, and using another Midihub as a MIDI interface, it always sends and receives the correctly ordered messages.

Can Micro Express be the one that does the realtime prioritization trick? :slight_smile:

There’s been a couple of cases in your output when the order was as expected, it might indicate, some other interface is doing the prioritization.

Anyway, I think you can assume that Midihub is sending out data in the expected order, and it might get rearranged by some other USB device participating in the chain. You can be sure that DIN-5 devices retain the order all the time.

1 Like