MPC-EMX.zip (789 Bytes)
Here you go - two takes of what you asked for (zip as not allowed to upload csv?)
Oh yeah, the two MPC patterns are assigned with the PC of 1 and 2. I’m not sure where/how it it triggers it - I’m presuming its the same as manually putting them in the sequencer on 001.01.01 of each pattern.
My bad, I forgot to mention that all the Monitor’s incoming and outgoing filters should be disabled, so that all the messages are getting outputted. 
Could you please disable the filters and repeat the procedure?
Whoops I forgot I’d filtered out some stuff for general use. Should be OK now
MPC-EMX-nofilters.zip (3.1 KB)
Ok, MPC1000 outputs the Program Change message at the exact moment the preset is supposed to get switched, in between the Clock message of the very last Clock of previous loop and before the Clock message of the new loop.
This is a logical place to do that, however, there’s one caveat - the MIDI Standard treats the Clock and a couple of other single byte messages as a special kind of message - they’re in the ‘real time’ group, meaning they can be delivered ‘out of order’, with a higher priority, than the rest of the messages, including in between sending other kinds of messages.
That means it’s sort of legal for the first Clock message of the next loop to be sent before the Program Change (which is a Channel message, not real time) gets sent.
Let’s test this theory - do you have a free MIDI Input on Midihub? Using the same preset, could you connect one of the Midihub’s outputs, and connect it back to the free Midihub’s input, set up the preset to forward the MPC data through a loop back into Midihub itself, and produce the same CSVs using the looped back input?
Let me know if this sounded too complicated, it may use some more detailed explanation. 
I think i’m doing it right
I’ve got IN-A going to OUT-A which is then physically connected back into IN-B. Absolute bare-minimum pipes:
MPC-EMX-loopback.zip (3.2 KB)
I meant that the message order could possibly get changed at the Midihub’s output, so the ask was to produce a log of Midihub’s output sent to an unused input, like this:
FROM MIDI A → TO MIDI A
FROM MIDI B → TO MIDI B
With:
The bold pipe is the one to monitor to produce the .csv file.
I’d like to compare the output to original csvs to see whether any of the events swap order or not.
Sorry, so this would mean to monitor MIDI B - IN right> ie. “TO B” in my screenshot (given that MIDI B - OUT isn’t being used?
Otherwise I don’t understand what “TO MIDI B” in your "FROM MIDI B → TO MIDI B" means as the loop as described ends with MIDI B IN doesn’t it?
Thanks for perservering with this btw. I currently just use the Midihub for very utilitation purposes with other gear so I haven’t delved very deep into it.
It’s just a placeholder, to make sure the FROM MIDI B operates as expected. (It should, but previously there was a monitoring bug where the input pipe was standing on its own in the line, it would not be providing the events to the monitor, it should be fixed in your version, but doesn’t hurt to place the output pipe in this particular test, to ensure success 
)
MPC-EMX-frommidib.zip (3.2 KB)
Ok, thank you for providing the CSVs.
In both takes, the events match exactly what the MPC1000 is outputting directly, with the program change happening in between the clock of the last moment of the loop and before the first clock of the new loop, so the event order does not change as I suspected.
Here’s some more ideas:
A completely different idea that could work well:
Use an external MIDI controller to make both, the MPC1000 and EMX-1 receive messages to make them switch program/pattern as required. This way, you’re not depending on MPC1000 program change message timing. Midihub can help by allowing you to use, say, a particular MIDI Note On message to produce the necessary Program Change messages on the necessary channels. If you’d like to follow this option, please create a new topic for reaching a solution.
An external MIDI controller might not be necessary if you can make use of some existing controls of any of your devices that won’t affect your performance. (like some very high octave notes or something else that you don’t normally touch, but have easy access to)
Ah excellent, having a Clock Delay of anything 2 and above makes the EMX follow the pattern change cues exactly how I want. 1 doesn’t work. So simple a solution but I was lucky to have you here to interpret the midi charts to understand what the MPC is actually doing.
Out of interest, what is the Clock Delay figure referring to? Is it 24ppqn?
I can feel the delay when triggering pay and hear it metronomes going on both machines but it’s not really noticeable with pads and FX type stuff.
I’m mainly using the MPC to arrange and layer up non-transient-heavy sounds (ie. no percussion) from other sources to add to existing EMX tracks (it’s an archival job putting back together some old, recovered music). So they don’t need to be super-tight, especially as they’re not going to keep drifting over time as it will get retriggered on each pattern change.
I’ve got one other synth that used for this stuff that I was thinking of connecting to the MPC too (just sounds, sequenced by the MPC), and I guess I can just use Sync Delay to taste on that as well to get it to sit well with the EMX if it’s too tight with the MPC. So great to have this thing as a swiss army knife to fix all sorts of different use-cases.
Thanks so much!
Indeed, 24 MIDI clocks make up a quarter note, 6 make up a sixteenth, and the 2 you used would be a triplet of 1/32.
Keep in mind that the delay in real world time depends on your BPM when using this pipe. The higher the BPM, the lower the delay.
One more idea occurred - sending a Song Position Pointer message to EMX1 whenever there’s a program change, to reset it to 0, or something right outside your loop bar length. Here’s how to do it, insert a Transform pipe before the output to EMX1 and set it up like this:
Argument 1 and 2 define the position to set. Both 0 mean it should be at the start of the loop. It might not have the intended effect. The position is in terms of sixteenth notes (4ppqn), different from MIDI clocks. If both 0 don’t work, try setting:
| Loop length (quarter notes) | Argument 1 | Argument 2 |
|---|---|---|
| 4 | 16 | 0 |
| 8 | 32 | 0 |
| 16 | 64 | 0 |
| 32 | 0 | 1 |
Let me know if this has any effect on the EMX1.
