[Feature Request] Mixer / Output mapping
Miami Mike described it pretty well in his blog on RCG: https://www.rcgroups.com/forums/showthread.php?3883631-How-OpenTX-should-have-worked
The proposal adds a layer of indirection between mixers and outputs. It could lead to
- 'orphan' mixers which are not linked to any output
- individual mixes being linked to multiple outputs.
This will have a major impact on the Monitors screen, since the latter depends on the 1:1 relationship between mixes and outputs. I'm not sure how this can be resolved without adding UI complexity/real estate.
IMO a more satisfactory approach would be to have up/down buttons on the Outputs, to allow re-ordering. This would also fit in well with a touch interface.
@RC-SOAR I‘m not sure I understand what you’re proposing. Would you be so kind to elaborate a bit on that?
IMHO, the key idea here is to have some possibility to go beyond this 1:1 mapping. Being on the UI level, or just “under the hood” (re-ordering requires some kind of mapping, internally).
Some have tackled it by offering a channel re-mapping in the receivers (access rx do that, don’t they?), which is a requirement I can totally understand, but is wrongly placed in the receiver, I think.
Some other manufacturers offer something closer to Mike’s original proposal.
but all in all, this is probably about having some sort of flexibility between the logical channels (mixers), and physical (output).
@raphaelcoeffic First, thank you for the work you're doing on this. It's great to see OpenTX being further developed in this fork.
I understand the need for more flexibility, similar to what's achieved in the MPM. As I see it, there are two ways this can be achieved:
(1) Add a mapping layer as per o/p's proposal, whereby an output can reference any mixer. There will no longer be a 1:1 relationship between mixers and outputs.
Or (2) allow channels to be easily re-ordered. This will maintain the 1:1 relationship.
There are a couple of issues with the re-mapping proposal.
First, the user will have to reference the mapping table to understand what's going on.
Second, there may be 'orphaned' mixers (mixers which are not referenced in any output). These will not appear in the channels monitor screen - even though they may be important mixes. This is not really acceptable.
Below is a screenshot of the monitor screen as it currently appears. It will no longer be usable in its current (well-proven) form.

Instead, I propose a simple 'move Up/Down' option in the Outputs menu. Essentially a built in channel changer.
This will achieve the primary objective, which is to re-order the outputs to match the user's setup. Crucially, it will allow the Monitors screen to be retained. It will also work well with a touch interface. And it will not require any change in workflow or the printed reports.
More detail: with each move,
- The outputs object is moved up or down one slot, switching places with the adjacent output.
- All the related mixers are moved with the output, so the change is reflected in the Mixers menu.
- All references to the channels are updated automatically.
See simulation below.

If a mapping layer is the only option available, then I guess it could be made to work by enforcing a 1:1 relationship between input and outputs. This is how the MPM works. This would avoid the possibility of orphan mixers, and you would allow existing monitor screen to be used (with some changes). But I still prefer the second option.
Thx a lot! This is feature design! I need to digest the info 😳
I fully support this!! Whether we keep a 1:1 mapping or the original proposal is good with me. Much smarter than hacking Lua scripts that move entire mixer groups around like I did here: https://github.com/jfrickmann/SoarOTX/blob/master/SD-CARD/SCRIPTS/TELEMETRY/JF/CHANNELS.lua
Yes, go.
But do the inputs as well. Shuffle physical switches over predefined names.
There are two things relevant here:
- Being able to switch output order
- Being able to use intermediate results of mixers to output
1 is easy by allowing a chanbel assignment per output. Add the channel number on the output channels and only allow for swapping channels maintaining integrity of all mixers used on all ouputs and vise versa. GUI wise this could be up down shift, and you need to make a choice what you order them like.
2 is more difficult, and would not be needed when we would have more mixer lines. In the current setup it is however very costly to use a calculated 0-100% flap mix as input for elevator compensation, while that mix also has trim lined added you dont want in the elevator mix. An option would be to be able to use mixerline x as source on another mixer. Than you can refer to ant intermediate mixing result, either as weight on a mix, or as a separate mixer to ouput to a separate channel.
Perhaps this could be reevaluated to be taken up in some future release?