Xform PC -> Stop, PC, Start

Midihub Support
1

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.

2

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?

3

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

WTF IS IT? RANDOM?

4

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

Why do these pipelines appear to not be sequential?

5

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.

6

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)?

7

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.

8

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.

2 Likes
9

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.

Notes:

App: 1.11.5
Firware: 1.11.7

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

Setup:

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

10

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

11

Hi, please attach the preset you’re using.

12

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”

13

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.

stop_pc_start
stop_pc_start2430×800 327 KB

14

@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
15

Just wanted to do a final follow up.

So I switched to MPC MIDI DIN OUT -> Midihub -> USB OUT -> Mac

and I got consistently ordered, and ordered as expected, results! So we suspect the Midi express was prioritizing realtime messages.

Let me just give you a big thank you for going out of your way to implement this very specific feature request. I really appreciate it.

Unfortunately, the Analog Rytm can’t be helped. :frowning: Even with your implemented feature, the Analog Rytm just can not respond immediately to program changes like it does when you put it in Direct mode and hit the physical button.

The community hoped we could work around Elektron’s bad programming and make the Rytm respond immediately to PC, but even with your Stop -> PC -> Start message, the Rytm was injecting an extra beat when switching. I put it against the click track in the MPC and it was just a disaster.

This is not your problem, but it’s Elektron’s.

Thank you so much for trying to help!

4 Likes
16

Would ‘Sync delay’ pipe help? It can shift the clock every time a start message passes through some clock messages amount. Note that negative values can be used to shift into the future, but only a limited amount. :slight_smile:

1 Like
17

Hello!
I’m new here, and sorry to get this topic back from the graves, but I’ve recently added an octatrack to my existing setup that I use as a master with the Digitakt and Digitone by its side. As most of Elektrons user I knew about the PC problem long ago, and thought I could solve it using Midihub.
Well, it does kind of work, but the problem I have is that on the first cycle after launching the sequencer, the Octatrack send a first PC by itself at the end of the first pattern, but it seems to do it 1 or 2 steps before the end, resulting in both Digis to change pattern … too early (I know, we reversed the problem).
You suggest @Giedrius to use the “Sync Delay” pipe, which I tried to place in different places, but I can’t grasp where it should actually be.

I attached my config for review.
Thanks in advance for your answers.RBS_Elektron.mhp (903 Bytes)

18

Hi RBS, welcome to Midihub.
Just had a quick look at your patch. Good stuff.

Pipeline 1 is only letting the PC through, transforming it a note, dispatching 2 copies & self to vA.
It’s these soon-to-be-Stops which need delaying, isn’t it?
If so, the Sync Delay should go in that pipeline. Between the Transform & Delay would do.

Dunno how many ‘clocks’ per quarter note the OT transmits; maybe worth doing a temporary change to your outs so you can bring the OT events back together to Monitor the order of events-out and change the Sync Delay’s “Delay By” accordingly.

PS. In Line 7, The OT is only letting through Clock…Stop through to the DK & DN, right?

1 Like
19

Hey, thanks for your answer.
So basically the setup I need is this:

OT as master for both clock and transport send to DT and DN.
Obviously PC change issue from Elektrons machine corrected.
And last part is controlling the mutes on the Digitone from the Digitakt.

The first part I used the existing patch from patchstorage, but because everything but PC is filtered, I created a second pipeline just for clock and transport infos aside from this.
The mutes from DT to DN also work properly.
When I will have all this working, my plan is also to plug in my keystep to control each devices.

Concerning your question regarding the amount of clocks per quarter note, I’m not sure how I should measure this. What I can tell is that with a 60bpm beat, I get 24 clocks per seconds so per beats in theory, and therefore per quarter note (4/4) or am I calculating completely weird things here? :smiley:

20

I was looking again at the wording, Samuel:

drops a given number of Real-Time Clock MIDI messages or produces up to one quarter note worth of Clock messages in an instant to shift forward. The shift happens every time MIDI Start message is processed.

Haven’t got your patch up right now; do your pipelines receive a Start message?