Revive mixer scripts

[lshems]

I think mixer scripts are highly undervalued. They can be used for a variety of things.

Cyclic mix for rotors: reduce 9 mixer lines two 1 mixer with three sources and a value as input and three sources as output.

Stick limiterfir quads and helis where you don't want to bind servos when pushing sticks in a corner. Limit the range to a circle.

Or flaperon mixer where you put inbreak and roll, and an offset, and you can adjust all at will without creating unwanted differential.

Or a nine position switch on two switch sources.

The only issue is, they are not supposed to be used for in flight functions.

Can we perhaps make some precautions to make those mixer scripts reliable, or create some infirmware mixers for things like Heli cyclic or similar.

Any thoughts?

[lshems]

Leave this for the reliability issue, with perhaps moving some in flight mixers to use here to radio firmware for that reason.

[pfeerick]

Counter-proposal! 😁

Since ...

A cyclic mix is nothing else then an arithmetic exercise to convert one frame of reference with 3 inputs roll, pitch and throttle to another frame of reference, the swash plate orientation, with three servos being the geometrical connection. The only extra input needed is the geometric setup of the swash (90, 120, ....).

... it seems to me that allowing for a mixer to have 2-4 inputs would do this, and resolve the reliability issue? I say 2-4, rather than 3, just in case there are situations where it would make sense.

[lshems]

Let's merge it then. The issue with your proposal is that you cannot manage multiple outputs in the current multiplex mixer. Multiple inputs would be feasible, but ruin the concept that is nice and tidy.

So if you create a c mixer function with multiple inputs AND multiple outputs, use the Lua mixer script interface to define the inputs and map multiple outputs.

I'll create the Mya versions anyway, but they may serve as an aexample for a c implementation of them.

[pfeerick]

lol... fat chance of me doing it... my c/c++ is probably as good as yours now ;) That's why I stay well away from anything even remotely important (for now).

And c'mon... gimme a chance... now you want multiple inputs AND outputs for the mixer... what next... a faster LUA runtime that makes it so the lua scripts run as fast as the compiled C code? 😁

[lshems]

Lol. I think we can do some things, and Lua is fast enough for this mixing stuff.

We need primarily enough attention from the Devs and a fundamental discussion on the use of lua mixer scripts. Let's just find a way to make them fit for flying. Even if that would limit the size, or put other restrictions on them, like putting them on a separate thread for processing.

These Heli mixer scripts will truly be 10 lines of code each. If there are no other scripts running to crash the Lua environment, there really is nothing to prevent them for use in flight.

How to assure that is the question.

[JimB40]

I'd rather see here LUA tagged issues that covers

• LUA interpreter & compiler in OS bugs & enhacements
• LUA API bugs & enhancements

Any LUA code is in fact application. We may name it Wizard or decide to include some of them in distribution but still it is functional app.

Therefore issues about them here is like having issues about Facebook app enhancement in iOS repository.

[lshems]

I don't agree as Lua or internal widgets serve the exact (and I mean exact) the same purpose and are completely interchangeable.

On top of that, this issue is just about that: adding what are now Lua mixerscripts to the firmware to become native mixes, using the same user interface.

This on the view of reliability,where scripts are always advertised as not safe for inflight functions.

[pfeerick]

JimB is talking more as an organsiational process. I agree in as far as if issues were staring to go onto non-OS related topics, in that case, it would get a invalid label, since apps and third party stuff is nothing to do with the business of EdgeTX. However, here you are talking about LUA mixer scripts, and if they have a place, which IS a core part of the EdgeTX functionality.

[lshems]

I agree on the Lua as app part. We need some place for those also o think, but not here perhaps.

This is about the mixer functionality of itself indeed

[JimB40]

Fully understand @lshems just with increasing issues volume I'd like to defend this space not to cover things connected with every lua script written up to date 😄
Let's find good place to discuss LUA apps (which is in my interest) and for issues connected with lua coding.

[pfeerick]

Just leaving this here as a reminder... https://github.com/EdgeTX/edgetx/discussions/categories/lua

😉

[lshems]

OK, see also #371. It can be closed here, but I do think the limitation for LUA mixer scripts for "in flight use" should be challenged, and possibilities to make it a 'proper' functionality without blocking limitations found.