CC Remap not working as intended

[ekkomouse]

I am using CC1 remap to take cc32 and remap to 0 so a device can accept program changes and bank changes. Then I take CC0 and remap to cc32 or anything else to stop the device from receiving that other cc0 message.   Unfortunately it maps cc32 to 0 and then at the same time takes its remapped 0 and remaps again to whatever I chose 0 to remap to. So it can not remap independently, nor can I filter cc0 separately before the remap.

[Jesse Johannesen]

All mods are done in series, so when you are remapping a CC, it is doing that, then passes it to the next mod. Can you remap it to an unused CC that doesn't matter instead of trying to swap the CC destinations? That might be your best bet.

[ekkomouse]

All mods are done in series, so when you are remapping a CC, it is doing that, then passes it to the next mod. Can you remap it to an unused CC that doesn't matter instead of trying to swap the CC destinations? That might be your best bet.

I dont know why your forum doesn't notify me of responses on any threads, I don't get the email, I have checked spam and junk. It just doesn't send notifications, I get lots of forum updates from other places though.

Cc 0 and 32 are specifically for bank messages. Some devices want cc 0, some want cc 32, some want both. This device only wants cc 0, but the sending device sends bank on cc32 (which needs remapped to cc0 in cc scale mrcc function) and also sends cc0 at the same time to change PC Banks. Unfortunately I can not simply exclude cc0 from this output in the MRCC tools, and I can not remap cc0 to another as I need it for banks. the MRCC cc remap would be useful to have the ability to treat a cc remap as exclusive. Meaning the remap does not pass to the next mod for that type of modification, so cc remaps could be exclusive which would then allow receiving cc32 and remapping to cc0 and outputting to device from there, and then separately receiving cc0, remapping to cc any and outputting from to device from there, or better yet, cc exclude modifier so unnecessary cc data isn't saturating the midi bandwidth.

[ekkomouse]

Checking in on this again

[Jesse Johannesen]

The situation hasn't changed. The way that MRCC modifiers are applied is in series, so there's nothing that can be done without a system wide rewrite of the firmware unfortunately. the only thing I can think of is something like A) swap 0 and any number CC the target synth doesn't care about,(let's call it X) then B) 30 and any number the target synth doesn't care about, (Lets call it Y), then C), X to CC30 D), Y to CC0 and place them strategically so that:
1 for a case that wants CC0 but not 30, you would use B ,
2 if you need CC30 sent to CC0 and don't care about CC0, you would place A>B>C
3 if you need CC30 but not CC0, you would place A, if you wanted them both but swapped you would place A>B>C>D

I'm not 100 percent sure whether this is a solution, but it's as close as we're going to get at the moment, so my apologies if that isn't a optimal solution. I will put a request in for adding an exclusive mode, but it's not going to happen this year for sure.