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?