@skyscraper / Andy
I like this architecture and tridge is in favour of it. It results in a nice compact robust solution. Your implementation is particularly tidy,
It does run into trouble when you start modifying it through mavlink. I will explain why you might want to do that later. For now I will explain why it is a problem.
The core problem is when you decide to store the mixer when you have modified it. When you translate the -mix file into the mixer you loose information. You are pretty much compiling the .mix language into a machine code. The mixer is the state machine that runs the machine code.
Is it possible to reverse engineer machine code to get back to exactly the same source code?
Yes. We almost do this when debugging but it requires source code and debug data. Even then that is only one way. If the values in the machine code were changed then the source code needs to be automatically re-written, comments and all.
There may be a half way solution where comments and formatting are missing. You would get translation of variable names so that the saved .mix looks somewhat like the original. Maybe you could make a script that patches the original with the new version.
The next trick is how to do live mixer editing through mavlink. A gcs needs to know how to identify each of the different parts of the mixer. It also needs to know the geometry of the mixer you have loaded. Since you have a machine code table it might be possible to give each item an index identity so it can be modified.
And now to the why of it..
Correct me if I am wrong but it looks like you are flying gliders. They are tricky beasts to setup right. I am flying a 5m 11channel aircraft which takes much time to setup. I do have mavlink connected mixer tuning and I can't imagine being able to do this any other way. This has been running on MatrixPilot for the past 5 years.
There is the option of writing the whole .mix file to the AP and rebooting. If you can imaging doing that 20 times per control surface you get an idea of how horrible it would be to use.
What happens when your mixer gets more complicated? For example, I have variable aileron->flap and aileron differential depending on flap and brake setting. It simply is not possible to define a mavlink parameter for each of these possibilities. At some point any tuning method that is unreliable, difficult to use or takes a significant amount of time will drive you quite crazy and you will stop using it.
The challenge: Finding a way to connect your solution to a mavlink tuning service and regenerating a .mix file.
If we can solve this we have what I consider a perfect system.