Greatly enjoying my Midihub and learning its potential. I’ve managed some simple xxx but have come up against a problem which has me scratching my head.
I’m running an MPC One, Novation Monostation and Dreadbox Typhon with an E-Mu X25 as keyboard controller. The Midihub is linking all these successfully across several Midi channels. All can be played independently, but can also be recorded (as Midi tracks) on the MPC with the MPC sending out clock and Start/Stop messages.
So that’s all good, but I discovered that if I want to play an arp track using an MPC voice, the arp works fine when the MPC clock is not sending, but fails as soon as I start the sequence. I suspect my pipeline is not very efficient and somewhere I’ve created a timing conflict. The MPC is the only device running its clock, so perhaps I’ve caused the timing to loop back on itself?
Any advice gratefully received. I’ve uploaded the pipeline .mhp file concerned, and a screenshot.
X25.mhp (780 Bytes)
i think yes,must be clock feedback
MPC is receiving clock and probably is set to AUTO clock receive,
so you can either use FILTER pipe i’ve sent you
or you can simply set MPC to CLOCK MASTER only
i think would be better to use FILTER pipe to remove unwanted data(CLOCK) from midi stream
X25_MPC_CLOCK_FILTER.mhp (802 Bytes) ,this is 1.14.4 editor
from what i see
probably MONOSTATION is sending MPC received clock back to it,hence need to filter it out
Thank you. Exactly right. Much appreciated.
Hello,
Looking and learning, so I have another question from this example.
Is it mandatory to use Virtual pipes / connectors in this example?
For merging and splitting I can see the use of virtual routes, but otherwise could this example also work with multiple instances of the same MIDI input connector?
I’m asking, because the number of Virtual Pipes is limited.
Regards,
Maik
That’ll need a more experienced user than me to answer.
I’m sure my pipeline could be more elegantly designed, but I’m still at the building block stage. I was simply happy (amazed, more like) that it worked as I wanted it to. Kazeko’s suggestion on using another Filter pipe to resolve the clocking issue was the icing on the cake.
Hey @MaikR-010, welcome to forums and good question!
The answer is No, not at all.
Using @kazeko’s X25_MPC_CLOCK_FILTER.mhp as an example:
If you follow the flow L1 → L3 (or L5) everything that comes in MIDI A in L1 also comes in Virtual A in L3/5.
So Virtual A in those 2 lines could be replaced by MIDI A with no change to the outputs.
Now the MIDI C → Virtual C in L6 might have been different because it’s got a Ch Filter in it.
But as there’s also Ch Filter in each of the Virtual C → MIDI OUT (lines 7,8,9), the L6 Ch Filter becomes redundant anyway.
So @GeeGee’s original worked fine but could be shortened. Congrats tho’ @GeeGee, on diving into Virtuals!
The main reason to use virtuals in this sort of (non-merging) scenario would be if you wanted to do a bunch of stuff in common to all the virtual destinations.
This could be something permanent like filters/remaps…
…or a temporary testing measure like say having a filter which removes notes that you can then quickly toggle on and off for all the outs.
Wasn’t ment to criticize your work, so hopefully you didn’t read it like that 
Your routing was simply a good example of something I was struggling with.
Regards,
Maik
Thank you!
And, another thank you 
for making this as clear as possible, even the redundancy part.
I’m using the Midihub connected to the USB Hub port of my Audio4c interface, so I have to reconnected it to my Mac when I want to make edits. For the DIN ports this isn’t a problem, but for the 4 USB ports running through the A4C I have to ‘guess’ if things will work as expected. So I’m trying to keep things as simple as possible (at first).
Regards,
Maik
The MIDI monitor is great for this:
-
I will often write patches without any gear attached to the outputs.
When you follow the flow through the Monitor all the way to the (USB) outputs, you develop a clear sense of what each pipe is doing. This not only uncovers errors (for me, reguarly having theDrop in rangecheckbox the wrong way round on Range Filters!), but also brings out subtleties (like the difference between Rescales and Remaps) -
by throwing in a temporary virtual to replace a USB output, you can then see the combined flow of all the messages from various lines into say USB C
-
check out the tutorial on monitoring
btw, I don’t often find all the virtuals are used up.
Feel free to upload your preset in case there are are savings that could be made
Great tips! Did follow the tutorial series 
but this is still a very welcome best-practice.
Regards,
Maik