RFC vSwitches: virtual switches for mixer

I am working on a method to use virtual switches as they are discussed in another thread ( Independent trims for flight modes ).
I make my development with Devo8 and the corresponding emulator, have not transferred it to the other tx. Now I may be a little late because Devo12 will change many things.
I have to mention that my english is not the best and I tend to tell things slightly too complicated. Please ask if something remains unclear.

This is what I have implemented yet:

• a page for defining six virtual switches
• - renaming is possible
• - a hardware switch can be assigned to the vSwitch
• - a logical operator can be defined (and, or, eor)
• - in this case a second hardware switch can be assigned
• use these virtual switches like the real ones in every mixer
• extended emulator windows to show the vSwitches

It looks like this:

They will be shown like this (the given name still not used here):


Until now I have made the configuration of vSwitches as a part of the model config, but I am not sure if this would be the best place.

Please, I would like to hear what others think about these vSwitches:
1) Are they in general useful or nonsense?
2) Where should they be placed?
2a) In model config (that means model specific)
2b) In tx config (that means one for all)
2c) In tx config, but separate configs for helis and planes (means one for every model type, if there will be more sometime)
3) Are the logical operations useful? (I thought so because I can achieve more combinations with two three-way-switches: 3x3=9)
4) How many vSwitches should exist? (implemented yet 6, prepared for 8 )
5) Should the vSwitches be independent or should there be a priority to evaluate the resulting "flight state" (what I mean: if they will be used for flight states only one can be active at one time (from a logical view). So every state gets a name and with a priority it can be decided which is the only active (and the rest may be ignored or set to off or so))
6) Should the "active vSwitch" name be shown somewhere on the main page (this could be useful when it is used to indicate a flight state)? (maybe more difficult on other tx)
6a) If yes, which should be shown? They can be active independent from each other.
6b) If yes, should they all be shown as icons like the toggles, at different positions if independent (or at one position if representing "flight states")?

I would like to make it round before I post the changes in the source code. A few work is still to be done (like saving / restoring the values to ini-files (I know how to do), showing the given names in the mixer's switch field).
My development is based on an earlier commit (be96db7, 1/10/2013), so it could be a challenge to integrate it in the actual sources, but I'll do my best...

FDR,
thank you for your instant feedback. I need more time for mine and will reply at the evening (we have noon here).
(also for the ToggleIcons)

On my cell phone so havent read the complete post yet but PB and i were talking about this in the deviation vs er9x thread.

I would like to see > and < operators as well....

Look into er9x custom switches to see what i mean.

Great work!!!

Ok, so I think we are all talking about different things in a way.

- V switches used to store settings for flight modes.

- V switches used to make configs compatible across the TX's

- V switches used to store values as "inputs" and compare them to other values and inputs. (the er9x custom switch method).

I think it might be useful to name these in such a way as to know what we are talking about rather than just virtual switches.

Perhaps, F switches for flight switches, V switches for the assignable switches regarding model configs across TX's, and C switches for Custom switches that can "do math" and store values.

I don't use flight modes in that way. The mixer and the fmode switch are enough for me on that topic. But I certainly understand some folks want that kind of thing for lots of good reasons.

I do use the Custom switches in er9x and find them to be really powerful when building complex mixes.

rbe2012's work crosses over a bit into all 3 of those catagories, but may not completely cover any one of the 3 catagories.

I hope I'm making some sense here. I think it might be too easy for the term vSwitch to get confused and cause issues simply because everyone is using the same term for different things.

For example I can say that fSwitches are not important to me personally, but I would like to see cSwitches be able to do > and < evaluations.

??? ....Or am I an idiot? Which has been known to happen.

Thanks, guys, for your feedback. It is really great to see the common interest to make things better and I don't feel so tired anymore after some nights of coding...

I try to sort the postings:
Hex proposed to divide "my vSwitches" in three different categories. For me it seems to be a good idea to seperate these things and he is right, I don't cover one of them completely (at the moment...).
I will use the full names (flight switch, virtual switch and custom switch (and hardware switch or real switch?)) in the future to avoid mixing up.

Virtual switches:
I think it would not be so hard (at least for Devo8 where my experiences are) to realize a mapping between PB's list of virtual switches for 7E and the real switches in the tx (if we define the relationships). I had to implement such a method what can be used for this without too much effort. For a 1:1-mapping maybe the existing method for channel mapping may be sufficient. I will look into this.

Flight switches:
When using my vSwitch-approach for flight modes (what it was influenced by) you simply have new possibilities in abstracting the switches used in the mixers from the real switches (and renaming can make this more comfortable). This might not be enough to be complete as the discussion about independent trims has shown. Maybe for this a new approach would be better, like storing more than one more or less complete config and switch between these.

Custom switches:
I have read the er9x manual when I started to interest in deViation, what was still before 1.0 and quite a lot has happened since then. So I have to read it again (maybe with more success; it was hard the first time...). But I really like the points outlined by FDR and Hex. It would give us a still higher grade of freedom (although I can not see a benefit/practical use now for me personally, but I am still far away from an experienced flyer and I have to believe you (and I do)). Let me go a little deeper in this aspect the next days.