Monitor all ports?

Midihub Support
1

Hi guys,

I have an Octatrack and a Faderfox sending midi to Midihub IN A and B, and Midihub sending out Midi to 2 synths (outs A and B, irrelevant for the topic), and back to Octatrack and Faderfox through ports C and B respectively

The thing is that at some point of a long set (1 hour), suddenly my Octatrack soloes the Midi Track 8. I’ve been checking up and down and I have no idea why it does that, but I guess it’s receiving a midi message for that, which according to manual is CC#127 (from the Fadefox or looped from the Octatrack)

In order to try to find out why this is happening, I would like to know if there’s a way to monitor ALL midi (incoming and outcoming) of all ports of the Midihub. It doesn’t look like it’s possible with Midihub editor (is it?) but maybe there’s a good software for this.

My goal is to just start monitoring, play the live set and stop when this fails and check, because the issue is completely random, and it took me way too much time trying to find an explanation. I’m also attaching a copy of the preset, in case someone dares to investigate :smiley:

Thanks!

Midihub 2025.04.22 14.24.54 - 80forms en patch2.mhp (2.4 KB)

2

Hey @DiegoC, thanks for the preset; it’s a big help.

First answer: Yes it should be possible to monitor all the output in one or maybe two places by using Virtual outputs

Here's How:

Change every MIDI-D-OUT → Virtual D-OUT:

DiegoC_snap0
DiegoC_snap0390×235 25 KB

DiegoC_snap1
DiegoC_snap1377×235 22.9 KB

giving:

DiegoC_snap2
DiegoC_snap2120×474 18 KB

Do the same for MIDI-C-OUT:

DiegoC_snap3
DiegoC_snap3185×186 11 KB

Create Virtual IN → MIDI OUTs…

DiegoC_snap4
DiegoC_snap4100×118 6.13 KB

…so your preset works as before
AND you can monitor all the outputs in two places

If desired, you can add a few more lines to monitor all the C/D messages in one place
DiegoC_snap5

But, (2nd Answer): You can simplify the preset a lot by using Transform’s Ranges and Insert After instead of Replace.

This, for example…

DiegoC_snap6
DiegoC_snap6314×500 53.8 KB

…becomes one pipeline.
This will also make monitoring a lot simpler

Gotta go soon, but I’ll give you a few pointers later if you’re interested

Lastly, there’s this inconsistency:

DiegoC_snap7
DiegoC_snap7291×561 60 KB

which may be your issue

3

hey @resonotter thanks a lot! funny thing, I have discovered by myself right before your answer :smiley:

What I have also done is sending same virtuals to usbs, so that way I can monitor them with other midi monitor software. Because if I’m correct, as soon as you select other pipe, all the history of that monitor window vanishes, right? So it’s to risky to accidentally lose all the log!

Thanks again, hopefully I can find the faulty stuff, because I really only have 2 pipelines sending MIDI to the Octatrack (midi out C), so I really don’t know where’s the mess! :smiley:

4

Good idea.

is the 126/126 inconsistency correct, btw?

5

sorry, which one you mean?

6

oh sorry, I missed the second answer… reading right now…

7

Oh sorry, I uploaded the old version, the newer one doesn’t have those pipes. Anyway, I don’t think that one affects, because it’s just a CC remap that is not 127, and also is not sent to Midi Out C (the one sending back to the Octatrack…) Anyway, I attach the version I have done ready for monitoring
test-virtuals.mhp (3.2 KB)

1 Like
8

Thanks, useful to know a bit more about the routing.

Your MIDI C pipelines are pretty minimal:

  • send all message types from B → C
    (most pipelines have filters, these don’t so I’m guessing B → C includes stuff like Stop etc)
  • Only allow Channel specific messages on Ch 11-14
  • Rescale (“Invert”) CC22

So unless Octa allows a message from channel 11-14 to affect Channel 8 it’s hard to make sense of it!
(I’d offer putting CC127 in the CC Filter list but I’m “clutching at straws”.
As this messes with the CC22 line, maybe try appending this one line replacement (Append).mhp to replace both lines)



Let us know how your monitoring goes!