When remapping velocity values to a CC number presumably the original velocity data is still being output (along with a copy of those velocity values with the new CC number) because velocity is part of the note information, whereas when remapping CCs the CC data is not part of the note information so the MRCC is not outputting the original CC number, only the new CC number?
It might be nice to be able to toggle each CC mapping between either "Move" (the default type) or "Copy" (to keep the original CC number data along with the new CC number data). This would enable us to use one source CC to control multiple target CCs, with different scaling for each target CC if required. If the user wanted to have multiple target CCs but have the original CC removed they could set the first mod slots to be "Copy" and the final mod slot to be "Move", as the processing always occurs in the order of the mod slots.
So my feature request would be that the CC scaling and mapping sub page gets a new setting on the screen at the left of the existing line "CC: x to: y" where we can choose whether we want it to "Move" or to "Copy" the CC data from the source CC number to the target CC number.
Another separate feature request that might be useful would be allowing us to set the target CC number on that screen to "None", so that (when used with the default "Move" kind of mapping) it would provide a way to delete particular CC number data that is being produced from the source device but that we don't want the target device to see, without having to filter out all the CC data, or having to find some irrelevant CC number to map it to just to get it out of the way.
An alternative way of implementing this second feature request would be that if the "Move"/"Copy" option of the first feature request was being implemented, a third option of "Delete" could be included there, and when "Delete" is chosen the "to: y" part of that line and the velocity scaling graphics below it become invisible because they are not relevant when deleting a CC number from the data.
In case my post above is confusing, this is a visual example showing my described way of implementing both these features via a new option where you can select one of the three behaviour types "Move", "Copy" or "Delete":
![[Image: lmMBcLC.gif]](https://i.imgur.com/lmMBcLC.gif)
I imagine Velocity would only be available as a source for "Copy", but CCs and Aftertouch would be available as a source for all three behaviours and as a target for "Move" or "Copy".
It might be nice to be able to toggle each CC mapping between either "Move" (the default type) or "Copy" (to keep the original CC number data along with the new CC number data). This would enable us to use one source CC to control multiple target CCs, with different scaling for each target CC if required. If the user wanted to have multiple target CCs but have the original CC removed they could set the first mod slots to be "Copy" and the final mod slot to be "Move", as the processing always occurs in the order of the mod slots.
So my feature request would be that the CC scaling and mapping sub page gets a new setting on the screen at the left of the existing line "CC: x to: y" where we can choose whether we want it to "Move" or to "Copy" the CC data from the source CC number to the target CC number.
Another separate feature request that might be useful would be allowing us to set the target CC number on that screen to "None", so that (when used with the default "Move" kind of mapping) it would provide a way to delete particular CC number data that is being produced from the source device but that we don't want the target device to see, without having to filter out all the CC data, or having to find some irrelevant CC number to map it to just to get it out of the way.
An alternative way of implementing this second feature request would be that if the "Move"/"Copy" option of the first feature request was being implemented, a third option of "Delete" could be included there, and when "Delete" is chosen the "to: y" part of that line and the velocity scaling graphics below it become invisible because they are not relevant when deleting a CC number from the data.
In case my post above is confusing, this is a visual example showing my described way of implementing both these features via a new option where you can select one of the three behaviour types "Move", "Copy" or "Delete":
I imagine Velocity would only be available as a source for "Copy", but CCs and Aftertouch would be available as a source for all three behaviours and as a target for "Move" or "Copy".