Hi.
My goal is to create CC105 sine waves going out on channels 1-8 and have independent control over the amplitude and wavelength of the wave on each channel. In example A I have used tempo multiplier and the CC LFO with CC102 controlling the ‘divide by’ and CC103 controlling the ‘depth’ of the wave, all separated by channel. My controller just then has to send the CC102/103 on the channels 1-8, (see the mapping), and it all works as expected.
The problem is that this uses 16 knobs so I thought to just use a channel remap in front of all this so I could use just 2 knobs and change their channel at the start, see example B. I used CC104 channel 9 to sweep the channel from 1-8 then a filter on CC104 to get rid of it. When I monitor ‘to virtual A’ it is all working as I would expect but only tempo divider on channel 1 ever changes irrespective of the channel remapping. If I set the channel remap to channel 2 and monitor the ‘From virtual A’ for channel 2, I can see CC102 on channel 2 coming into the tempo divider but it’s the tempo divider on channel 1 that will be changing. I’ve obviously misunderstood something obvious so if anyone caan point out where I’ve gone wrong, that would be appreciated.
Thanks.
B.mhp (1.2 KB)
A.mhp (1.2 KB)
Thanks for posting your patches
Unfortunately, this won’t affect your mappings:
-
In B.mhp, like A.mhp, they are fixed to specific MIDI channels coming in MRCC (DIN-A)
-
Once a mapping is learnt, Midihub will listen on Port X Channel Y to CC Z for the next mapping value as it enters Midihub
-
You might also do something else with that event as part of your patch, but this won’t affect the original mapping value
(For Midihub to do this it would need to listen to a Virtual port which would bring a whole tranche of complications)
-
Conversely, incidentally, a “mapping port” doesn’t even need to be one of the input ports in the patch; so a patch might have only MIDI DINS, but all the mappings be from say USB-D. (For me, this fact helps pin down the distinction between mapping & ‘processed’ events)
Hope that clarifies.
To achieve what you want would need scaleable/internal/local mappings which aren’t yet available on Midihub.
In the meantime you would need to use a physical loopback.
In your context this would involve something like:
-
sending Ch.9 CC 102/103 into the loop
(Ch Filter allow only Ch9 in)
-
use ChRemap mapped to MIDI MRCC Ch9 CC104 like now
-
Ch Filter allow only Ch1-8 CC 102/103 out
-
using a temporary append of the Loopback Mapping Tool to set your 16 TempoDiv & LFO mappings to the Ch.1-8 CC 102/103 values coming back into your loopback. (Hell, you can even map your MRCC Ch9 CC104 to its ChRemap to reduce the tedium!)
A loopback needs an in & out but with your set-up that looks quite feasible, possibly via the MRCC itself with judicious patching!
PS. Filter out the Clock!
No worries.
I’ve never done loopback via a device before (always cable or USB-via-patchbay), but I think it should be fine with careful use of filters.
Then you can just keep one line for the MRCC loopback-to-set-up-the-maps
Cos your Ch1-8 CC 102/103 's are only ever used as maps, they can be filtered out of the start of every other MRCC-IN thus stopping them being an issue going back to MRCC for a 3rd pass.