Dear colleagues,
Here I come to bring up a question that I think is a bit unusual.
In my current set there are FOUR active Midihubs (I think I have become a good customer 
).
All four Midihubs are connected to a computer, as I’m trying to take advantage, in addition to all their Midi ports, of some of their virtual Usb ports.
The most time-consuming issue is to find the best way to interconnect them by losing as few Midi ports as possible.
And here I must say that I find in this interface, probably the most powerful I know in the Midi world, an extremely weak point, and that is the lack of integration between several units.
I’m currently using, at least, one IN and one OUT in each of the units.
And this is only if I manage to contain (with lots of pipelines) the infernal loopbacks that are created, otherwise I may need up to two ports.
One of my units has also reached the limit of 255 pipelines.
I understand that I have a complex workflow, but this problem already worried me when I had two Midihubs. As I got more, it got worse.
Am I missing something essential due to lack of knowledge, or is that really how I’m putting it?
I can imagine some kind of integration between different units in the Editor, or some way to take better advantage of the USB ports, I don’t know…
Sorry if it’s a bit confusing how I describe it.
Thanks and I look forward to your comments!
Cheers,
Ian
What sort of DAW and OS are you using? You could have your host computer forward some of the MIDI data between Midihubs via USB, to save physical DIN-5 ports.
Hey Giedrius!
It´s a DAWless setup (in terms of audio). Just receiving MIDI in Resolume Arena, using the USB Ports. MacOS 12.3.
Is there any simple workaround for avoiding loopbacks in case I use -let´s say- every DIN C port for this interconnection?
So far, I had to create quite long pipelines to avoid specific messages to create loops. But there´s so much MIDI data going on, in all 16 channels, that it becomes endless to block the loopbacks.
Thank you always!
Now you know you can count with me as a potencial customer for a XXL 16 IN - 16 OUT Midihub 
I still can´t believe how much this thing changed my creative life!
Cheers
In case you don’t use a DAW, but connect Midihub to a host computer, you may forward MIDI data via USB using something like Midi Patchbay on macOS (MIDI-OX on Windows, aconnect on Linux), so this may save some physical DIN-5 MIDI connections.
To avoid endless loops for loopback mapping, you could use a single dedicated port for it, you’d simply not use the input pipe for the port anywhere in the preset, the mappings that are mapped to such a port would still take effect.
To follow on from
@KRNFLD it sounds like you’re several generations (& two Midihubs) on from your pipeline switching back in Jun22.
What I’d add to Giedrius suggestion is “Don’t be afraid to use multiple passes” and “FilterFilterFilter!”
As an example, here’s a diagram from one (middling complex) loopback I’ve made available:
The important bits here are the green arrows and the first and last blue thought bubbles:
- The green arrows make clear to me the only things I want to allow through for this pass and
- The bookend blue bubbles hint at the sort of filters I need to make sure of this.
My default when building a complex loopback patch is therefore “nothing that goes in is allowed out”.
To achieve this at the building-stage, I will “over-filter” by default not only for the task in hand but also because I want to be able to reuse the same physical connection for other purposes.
This allows safe loopbacks even with mutliple parallel and serial( multi-pass) use.
Only later might I decide I can afford to lose some of these filters…
..like here..
…in line 1 only notes are let in & only CCs out just cos I want to future proof the loop from letting any un-transformed note in.
Line 2 on the other hand needs no end filter cos only CC83 leaves.
Another point of note here is the (virtual) output D.LOOPOUT and input D.LOOPSPLIT in the last few lines.
These allow the products of the loops to be split, so that only the CCs destined for mappings go back into the loop and only the CC meant for the “outside world” are allowed out
Your situation needs even more care as you are using all 16 channels; you don’t have the luxury of reserving a channel just for loopback information purposes. Even more “encapsulation” planning there, depending on how “universal” your channels are…
Hope at least some of this is useful.
By the way, have you explored Midihub → Midihub loops?
Hey, Resonotter
Thank you very much for your reply. As always, your explanations are real lessons.
My set up has indeed continued to grow and I think it has reached a pretty “definitive” point, at least for this stage (I’m attaching a 2021 messy scheme and when I have prepared the 2023 I’ll send it to you 
)
As you say, having all 16 channels in use (and I would really need about 4 more) is the biggest complication.
What do you mean by this?
Thanks again
Hey @KRNFLD that’s a seriously nice diagram; if that’s 2021, 2023 must be really scary!
Midihub → Midihub loops
What do you mean by this?
You’ve essentially got the basis for one in your 2021 setup: MH1.D → MH2.D → MH1.D → …
I sometimes use my 2nd Midihub to setup the scaled mappings for my 1st when it’s convenient.
Whether this would offer more than a standard physical loopback would depend very much on the use case, I think…
Same applies to 16 channels; if you can ‘compartmentalise’ the workflow so that that in any one scenario you know there’s >=1 channel that isn’t part of that flow then it’s doable.
Same applies to CC numbers; I tend to use a range (say 77-81) rather arbitrarily to set up “get this, modify it to that … then pass it out as the other”. In your situation I’d be exercising a lot more care!
What sort of functionality are you now adding via loopbacks? I imagine it’s gone beyond switching.
Nice network 
You could be more satisfied with solution like this (unfortunately it seems like dead or in deep sleep), where basic HW unit can be multiplied as many as you need, but for user is presented like one unit, just bigger/extended.
Or you can go smart, leave this rabbithole where you trying to do advanced things with simple devices (which aren’t designed for) and build advanced MIDI network around Bomebox as central router (and MIDIHUBs as endpoints, means network configurated as star, not circle) with comfort of using/integrating standards like LAN / WiFi / RTP / WIDI…I think it’s more reasonable approach to connect complex setup like yours (without risk of insanity :)), especially if you’re planning to expand it.
You can control it from PC/Mac and/or iPad, for example.
Dear Resonotter,
Here I am again, with delay.
My set has one computer, nine MIDI controllers, two samplers, two synths, two electronic drums, three fx processors and three audio interfaces.
Virtually all of these devices interact with each other.
The two synths and the audio interfaces only receive MIDI.
The nine controllers only transmit MIDI, to the instruments and to the video software.
All other devices send and receive MIDI, both Notes and (mostly) CC messages.
I have used so many filter pipes that one of the Midihub’s has reached its 255 limit.
The management of the 16 channels is the most complex of all. But I’m getting closer to having a stable structure.
As for the original topic (the interconnection of Midihubs) I seem to be managing the DIN ports.
Here I attach the most recent drawing of the physical cabling structure.
Thank you very much as always.
Hey, thanks for the message!
I looked into the Bomebox for some time, and it looks like a nice and versatile device, but it didn’t seem to be my solution for this set up I’m developing.
Also, a month ago I’ve returned from living in Berlin to my city in Argentina, and here it’s practically impossible to get new hardware.
Do you really think the Midihub is a simple device? It can be, that’s the good thing. But it can also reach a very advanced and rich level of complexity.
Thank you!
Best,
Thanks for the picture, Ian.
I’m not sure if you’ve got a specific question relating the setup, but I recall your original query was about managing the integration between the units.
A couple of issues spring to mind from looking back at the thread:
Firstly: the computer issue
you mentioned
some way to take better advantage of the USB ports
and Giedrius asked
What sort of DAW and OS are you using?
Your answer suggests that the Mac 10.12 is connecting the Midihubs with Resolume Arena to feed it with messages controlling the visual aspects.
Is that all?
Does that mean you’re not using MIDI Patchbay?
Looking at your new diagram, MIDI Patchbay would allow you to lose all those orange arcs.
Moreover as it offers a rudimentary level of filtering for each patch connection…
…I would hope you be able to lose some of the filters within you presets.
(I’d imagine some current difficulties might also become moot purely because Patchbay would allow you to have dedicated MH X → MH Y connections rather than your current chaining – which is what I presume your dotted 3.D → 2.D arc signifies)
Secondly, “loopbacks”
Seeing your diagram, I now realise that I (and possibly Giedrius) assumed you were talking about
deliberate physical loopbacks designed primarily to overcome Midihub’s current lack of internal/virtual mappings.
Your diagram suggests you’re not…
…so apologies if my Post 5 was a complete Red Herring!
Having said that, if you do want to take some message manipulated/ created in say MH3 and use it as a mapping in MH2, then MIDI Patchbay above would give you the scope to have a MH 3 → MH 2 connection (say A → A) dedicated just for mapping messages (Leaving say MH3.B → MH2.C for event messages)
Umm, I think that that the MIDIhub is pretty powerful, but the design is simple. Setting anything in app is more about workarounds (you have to figure out how to do anything due combining/multiplying/dividing/etc. simple steps by yourself and waste not small amount of time with it) than about really smart solutions. I just don’t want to turn it device on because of this. And I’m not satisfied with approach of developers to calling so now I’m considering to sell the device and buy CME’s U6MIDI Pro, it’s just 50$ and can do the job better. The same job.