Feature request: Trim buttons as switches?

If you want a feature in Deviation, the best way to go about it (assuming you can't code it yourself), is to get quorum here and then file a ticket on bitbucket.

If you skip the last step, it is likely to die in committee, since I use bitbucket to keep track of features I'm not currently working on.

I have no qualms about ignoring or closing tickets. But I honestly just can't remember all of the requests made potentially months apart, so the ticket system is the one I support for feature requests, but only after they've gained some amount of consensus on the boards.

Such requests may get closed unceremoniously, remain open for months, or even never be implemented, but at least I know they are there.

And there is never such a thing as being too fussy. The goal is always to make Deviation as good as it can be. Often we need to make tradeoffs to preserve consistency across transmitters, or due to other limitations, but generally, I'd like to at least understand how people want to use the software.

I'm unclear about how an sd card would help.
We have Devo8/10 which have plenty of storage for our needs and will (eventually) be limited by the on-board FLASH (program space) and RAM

We have the Devo12 which has a massive CPU which has lots of program space and RAM, and has a huge FLASH chip for storage along with a smaller one. The problem is that we can't use the large one for write operations without wear-leveling due to the chip they selected. So at the moment it is a read-only, and is programmed via the lib. The smaller flash is used for R/W. If I ever get wear leveling working we'll have full access to the devo12 storage space. Or if I ever finish the Java USB programmer, we will likely get access to it there (which isn't quite as good, but is close)

The devo7e has a tiny CPU with very little program memory and RAM. It also has a smaller flash chip for storage. Increasing the storage wouldn't help because the real limitation is the CPU itself. Replacing the CPU is something that very few people here could do successfully.

So I don't see any benefit in adding storage to any of the Devo transmitters.

On the devo12 we could theoretically write files that are multiples of 128kB to the parallel flash drive. There's 16 MB of space there, of which we use around 1MB today. On the devo8/10 there's ~2MB remaining for data logging.
Log data takes up ~112 bytes per second to capture all available info. At that rate, you can run for ~2.5hr per MB of file space.

At the moment that isn't possible on the devo12, but it is something we could implement that would likely be easier than adding sdcard support.

Okay, I checked in a proof of concept for this capability. I may change how it works so don't get too attached to the implementation. this was just 20 minutes of hacking to see if it worked.

Here is how it works.

On the trim page, if you set the 'step' to the smallest possible value, the label will change to 'Momentary'. Now the trim will act like a momentary switch. If you set it to the largest possible value, it will change to 'Toggle'.

To use:
set the step to either max or min value
set the src to an unused channel (Virt1)
set the Trim+ to the trim in question
set the Trim- to None
on the mixer, select the channel from above (Virt1)
set the type to 'complex'
set the Curve to 'fixed'
set the scale to 0
set the trim button to 'Trim' (thanks RBE)
Now your Virt1 is a switch controlled by the Trim you selected.
In momentary mode it will only be +100 when held.
In toggle mode, it will toggle between -100 and 100 each time you press the switch.

Will this eliminate step 0.1 for trims?

How it is implemened at Futaba 3PK (car Tx), ch3 trim step (1, 2, 5, 10, 20, 50, 3PS, 2PS)
- step 200 = 2-position switch 2PS (-100, +100)
- step 100 = 3-position switch 3PS (-100, 0, +100)
- step 50 = 5-position switch (-100, -50, 0, +50, +100)
...
- step 1 = 200 clicks (-100 ~ +100)

Possible we can add 3PS-Alt (momentary, -100, 0, +100) and 2PS-Alt (momentary, -100, +100), trim steps without memory.

Once more question, what to do negative trim step values?

Some thoughts about the new trim config:

1. Is there any sense of the configurable switch, when the trim step is toggle or momentary? If not, it could be hidden...

2. Do the toggle and/or momentary switches use both trim+ and trim- definitions? If not, the unused one could be hidden on both the trim config page and the trims list.

3. Can the two directions of the same trim button be used for two distinct toggle or momentary switches? If so, the six possible configuration slots will be a limiting factor.

4. There might be an other configuration as well: to use a trim button as a switch. Pushing up would turn it on, while pushing down would turn it off. It is similar to the toggle, but you don't have to care about what state it was before...

5. Further advance the point 4. it could have more then two states, but having more then three states would complicate it's usage, since the values would be for example for a four state button: -100, -66.7, +66.7, +100