Dynamic table creation and axis selection
Posted: Sat Nov 27, 2021 4:11 am
I've brought this up in another thread but I think it deserves it's own. I think it's really important from a usability perspective that users have more control over the 2d and 3d maps used by the software. It makes it easier to write software (no need to predict every use case) and it makes it more flexible for tuners (who usually aren't programmers) to configure what they want. To me this means several things:
1. Every axis on every table should be user selectable. You can kind of do this in TunerStudio with massive if blocks but it's a pain and feels like an afterthought as opposed to integrated into the way logging/internal variables are managed by the ECU (the variables should be structured in a tree, any input and any intermediate/computed variable should be selectablle, the same way you select variables to log or tx/rx via CAN)
2. Should be easy to change the shape of a table (more or less columns/rows, up to some limit of course)
3. Should be able to reference the output of any other table as the input for any table (extension of #1)
4. Should have a collection of do-nothing tables that users can enable for the purpose of chaining tables together (either a table used to interpolate between two others, or a table that is used to add a % to another table, or a table that is straight up added to another table (same units), or select between two tables using a digital input.
Lua can kind of be used to provide some of this, but in a way that is much less approachable by non-programmers, and in a way that's harder to make clear in a GUI - i.e. we can name tables and see that name when looking up axis variables. For example, I can name "User Table 1" as "MAP Target", then when I look up variables to use in an axis for another table, I should be able to see "User Table 1 - MAP Target" instead of just "User Table 1."
These sound like minor issues but I think it's easy to underestimate the usefulness of having this level of integration in the GUI itself. It makes it easier to see how it all ties together.
Anyways I mocked up a start of a GUI. It's written in Python / QT, and I only tested it on Linux. I had another GUI I was starting in Python / WxWidgets but I ran into too many issues with their grid/spreadsheet widget. Let me know what you think and if you find this useful as a potential start for a RusEFI specific GUI. It might be that we can get TunerStudio to add the overall feature, as it seems they're currently receptive to improvements?
1. Every axis on every table should be user selectable. You can kind of do this in TunerStudio with massive if blocks but it's a pain and feels like an afterthought as opposed to integrated into the way logging/internal variables are managed by the ECU (the variables should be structured in a tree, any input and any intermediate/computed variable should be selectablle, the same way you select variables to log or tx/rx via CAN)
2. Should be easy to change the shape of a table (more or less columns/rows, up to some limit of course)
3. Should be able to reference the output of any other table as the input for any table (extension of #1)
4. Should have a collection of do-nothing tables that users can enable for the purpose of chaining tables together (either a table used to interpolate between two others, or a table that is used to add a % to another table, or a table that is straight up added to another table (same units), or select between two tables using a digital input.
Lua can kind of be used to provide some of this, but in a way that is much less approachable by non-programmers, and in a way that's harder to make clear in a GUI - i.e. we can name tables and see that name when looking up axis variables. For example, I can name "User Table 1" as "MAP Target", then when I look up variables to use in an axis for another table, I should be able to see "User Table 1 - MAP Target" instead of just "User Table 1."
These sound like minor issues but I think it's easy to underestimate the usefulness of having this level of integration in the GUI itself. It makes it easier to see how it all ties together.
Anyways I mocked up a start of a GUI. It's written in Python / QT, and I only tested it on Linux. I had another GUI I was starting in Python / WxWidgets but I ran into too many issues with their grid/spreadsheet widget. Let me know what you think and if you find this useful as a potential start for a RusEFI specific GUI. It might be that we can get TunerStudio to add the overall feature, as it seems they're currently receptive to improvements?