Midi Routing vs Midi Effect Processing

Midihub Feature Requests
1

Hello, so initial and high-level thoughts about the Midihub architecture. While the architecture seems really flexible and powerful, from a usage perpective, I’m already seeing potential problems between the 2 core use cases the Midihub is trying to solve.

1. Midi Routing
This is where the device competes with the likes of iConnect, Sipario, BomeBox, etc…
In this scenario, we are talking about operations that are at the MIDI Port level, merging, splitting, layering and translating data, mostly based on the idiosyncrasies of your devices, and in general not something that changes very often.
take that block of channels form USB A, map them to DIN B, filter out the start/stop messages on DIN C, re-arrange note ranges and cc so multiple devices can co-exist on the same source channel, stuff like that.
2. Creative Midi Effects
This is the part that competes with various sequencers, the Squarp Pyramid/Hermod being the prime example. In that scenario, what the user will want to do is entirely dependent on the particular composition they are working on. and is mostly independent from Midi Ports and Channels. I might think want to have a complex Delayed/Arpeggio/EQ on a particular synth ( my MicroMonsta on Din A ch 3 ) but quickly realize that part would sound better on a different synth ( the Blofeld on Din B ch 9 for example )

Can a single processing stack really do both justice?
And this is where I can already see the single system of pipes that is meant to work for both routing and effects rapidly becoming unwieldy. Even some thing as simple as creating an arpeggio on ch 3 already means putting 2 pipes, one that will let channels 1-2 and 4-16 pass through unnaffected, and then another one to extract ch 3, and use that to further process the arp stuff.

If there were already a bunch of routing actions taking place on different sets of midi channels, these will also need to be accounted for. and the simple act of wanting to change the Midi processing from one particular synth to another likely to become a complex dance of disconnecting and reconnecting pipes.

And maybe this is because I’m coming from a world where I have this working very well, with the iCMP4+ acting as my Midi Router, which I really only reconfigure when I reconfigure my studio, which happens infrequently. And the Pyramid acting as my Creative MIDI processing, which I reconfigure constantly while I working on a song, and where every song is completely different, even though I often re-use the same stack of effects configured in a particular way over and over again.

Wondering how this community is approaching that Routing/Effects duality?

2

Complex systems will use probably separate Routing and Effects to different devices for various reasons.
Simple setups like 2-3 synths and 2-3 controllers and a computer not only can handle this duality easily but users tend to look for it. Otherwise, there is always a way of getting 2 midihubs, and keep those workflows apart. Just an opinion, a relatively simple setup here anyway.

3

Thanks. My current setup now has enough synths to cover almost every single available channels on all 3 output ports of the Pyramid, so 48 channels total. ( it’s actually not that hard if you have a few multi-timbral synths that can listen to up to 16 channels each )

The way it’s currently setup, every single synth is always accessible from the Pyramid, with a static routing table in a iConnectMidi4+ unit wrapping the Pyramid’s inputs and outputs, and routing channels to each synths over din and/or USB.

The Midihub could easily manage the routing, except for the missing USB host, but I still haven’t decided where to insert it in the chain to maintain that immediate routing accessibility and provide additional creative midi processing, to go further than what the Pyramid can do by itself.

Initially I’m probably going to keep the iCM4+ routing as is, and insert the Midihub between the Pyramid and everything else.

Before:

iCM4+ -> Pyramid USB in
Pyramid USB out -> iCM4+
Pyramid Din A out -> iCM4+
Pyramid DIn B out -> iCM4+

After:

iCM4+ -> Midihub D i/o -> Pyramid USB in
Pyramid USB out -> Midihub C i/o -> iCM4+
Pyramid Din A out -> Midihub A i/o -> iCM4+
Pyramid DIn B out -> Midihub B i/o -> iCM4+

So everything that flows in and out of the Pyramid can be transformed by the Midihub before hitting the iConnect routing table.

We’ll see…

4

Interested to hear how this goes for you! I’m going to have to do something similar as I’m also using all 48 channels from my pyramid.