EdgeTX
[Feature Request] Create a common input layout for all radios
Currently, every radio has a different number of switches defined, trims, etc.
This is of course defined by hardware available.
Yet, if there would be one virtualization of all radios, where you can map all physical switches to the common radio model, and assign physical inputs or fixed values of up,mid and down, or even percentage values, to all those inputs at will, all models and scripts would become interchangeable between radio models.
We need this to increase interoperability of models and scripts, so we can finally start community effort on sharing these.
See https://www.justfly.solutions/index.php/full-repository
I’m not sure I understand properly. But there is something you might like. With the new storage mode based on YAML, we should reach a state where models can be seamlessly exchanged between radios. So of course, it will only work with switches & pots available on both radios.
Ok, stay with me:
I currently create an input in the inputs page for ANY functional control input for the model that I might want link to a switch. This input is then used throughout the model, instead of the direct input from the hardware.
Depending on available hardware switches and trims, I can then assign to this functional control input any physical switch or input I like. If I don't have enough physical switches for all functions, I have to choose to put some functional inputs in a 'fixed' state by assigning the MAX as a source, and play with the weight to get the wanted default functional behavior for that function control input to the model.
However, actual physical switches are part of the model definition now, which prevents for instance a model exchange in the field by switching SDcards and restoring a backup model from one radio type to another.
If this concept of assigning fixed values to 'physical' switches that are not there for radio x would be introduced in the calibration and hardware assignment page, together with the possibility to set positive AND negative values for the endpoints in the calibration, you would get complete freedom in assigning ANY physical layout to the standard model layout, including out of the box support for inverting switch behavior.
Lengthy post, but it boils down to putting the physical available inputs in a radio firmware controlled list, and allow mapping to a general model definition that should contain for instance 64 slots for physical inputs, that can be used either as switch or analog input, depening on the hardware inout you assign to it.
You could even assign sliders to model switch inputs and vice versa. Have it populated with a default setup by having the model ask to the firmware for the entries of the gimbals, trims and the two primary switches, and leave the rest to the users, and you have complete interoperability between physically different radios, because the exchanged model info doesnt contain the radio specific mapping. That is in the firmware!
Ok, I think I get the concept, thx for explaining. This will require quite some changes, but I'm open to it once the transition to YAML is done. That will give us much more flexibility in terms of internal data model, which is not possible right now without huge efforts. But frankly, yes, I like the idea. And I know your history with the OTX team very well, believe me ;-)
I'm patient, but would love to see things that REALLY open up for low threshold community effort sharing
This would be nice to have... as mapping of physical inputs (switches, pots, sliders) to inputs used in models is something that would greatly help when moving between radios. I've been thinking something of something along the lines of naming the purpose of the switches, and then they can be dynamically assigned as the model is loaded... i.e. if you configure a switch as "arm", and a model file is looking for "arm" switch, it would automagically find it when loading the model (once you've configured "arm" to be a specific control)... or fall back to a low value (i.e. low if not defined).
Is this how this would be expected to functionally work? i.e. a new input class/group, that would map physical controls to the "reassignable" inputs/controls in radio setup? Which would apply to both sources and switches (thus can be used everywhere).
There are several ways to achieve improvement. One is to simply have the same number of inputs and switches on all model types. Let's take switches as example. Suppose we define the switch objects to always be present up to n, so 14 switches. Suppose in the hardware screen you now can assign all those switch objects to a hardware 'switch', or, and thats the new part, to a fixed value of -100, 0 or 100. In this way all switches will have either a fixed value or a changeable value through a physical input, that could even be a continuous one. If throttle is assigned to a switch, smaller than -85 being mapped to -100, greater than 85 to 100 and the rest to 0. Now, suppose i move a model to another radio with less physical switches. For all switches not 'there' anymore, you assign the default value as set in the 'soucrce' model. That could be the alarm position ar startup, and if not defined, some default value like -100. (0 is no good choice because of 2-state switches.
Same approach for continuous physical inputs, where a physical switch could be chosen as input.
You could even go bolder and skip the difference between input and switch alltogether.
The advantage of the above is that you dont need to do anything with functional names like 'arm' for certain inputs, which is against the entire idea that the radio is just an input output mixing device, and names are just attributes on objects without any function. Even aileron, throttle, rudder and aileron for the stick inputs have always been confusing for me, as they refer to functions they do not fulfil for my models.
Also, the above approach is actually very limited in impact on how things work for users.
A practical usecase: Suppose two switches are used to set flightmodes, h and i, and the j switch is used to activate the student mode. However, the target radio has 2 physical switches less, so i and j are missing.
After copying the model to the target radio, switch i will get the startup alarm position of -100, and j also.
Now the number of flightmodes that can be chosen is limited to those where switch i was at the -100 position on the source model, and rhe trainer mode cannot be activated by a physical switch.
The model is however wothout any special action fully functional. The user can choose to reassign other switches, but not neccesarily.
Now, when you think further, for color radios, you could even imagine on screen buttons to be assigned as virtual devices for these switches and inputs. Or on BW radios to allow lua to set the value of these virtual devices. They are virtual in a sense that they do not have any physical 'value' but only a value set by the software.
And that is why i commented on the virtual switches change. I really think it should expand the existing switches to a standard number for all models and use the idea to be able to use any physical or logical input device providing values. Then thàt change should only allow for the serial inputs or whatever physical source you want to be taken as value for the device.
For continuous physical inputs, same stuff.
It would also allow finally to uncouple the name of the throttle stick from the throttle 'source', and have physical input 'devices' expanded with 'virtial' ones. So the current 'sources' would be named S01 to Sxx, and could be linked to the physical input devices 'throttle stick' , etc. or a virtual input device with a fixed value, to be changed with a lua function if needed.