Forking deviationTx

Richard96816 wrote: It's all such a tower of babble. I have things I'd like to try. But where do I find the information that tells me how to quickly set up the build environment? This is free software, but it doesn't quite act like it. I've built other packages from other projects and it was relatively quick and painless. Getting started with this one looks like it will take weeks.

It's hard to find, but then again, so is pretty much anything.

Click Links in the menu on the left. Click "Team repository". Read the contents of the README in the repository, which tells you how to set up a build environment. Which is the first place I look for that information on open source projects.

This is changing - we've got docker images now. But they aren't done yet, so not listed in the README.

No one has yet suggested putting words to that effect on the home page. It's an absolutely primary enticement to participation, and you're all suggesting hiding it somewhere. It's your pride and joy, but it looks like you're somehow embarrassed to show it off.



Open software flourishes when others download, build and try their own ideas. Faceless software junkies getting hooked on your creation and stretching it in new and wondrous ways. But first impressions need to be as effortless as possible. Hook them before they have a chance to change their minds.

Hi, I tried and install a docker compilation chain on my (obsolete) PC, and will probably replace it in a few days. When it's replaced, I will try and test a few ideas about memory optimisations for the devo7e.

I saw in an other thread that for now the most memory constrained protocol was DSM2, right ? By looking at it I seem to have identified a few dozens of bytes to shave.
What other protocols are near/at the limit ?

Additionally, I may have an idea to shave some bytes in the ROM side too (related to "binary" configuration files, but keeping a tool-less one-way compatibility and other way tooled one).

However, I'm not sure it's worth the effort if the devo7e is "outscoped" post 5.0. So the big question is : if I were to manage to temporarily relieve the "memory" pression for a few months, will you all consider taking it along for the ride a few (sub)releases more ?

PB had already done some work on binary config files. I've also thought about it. Nobody really wants to abandon the 7e, but the memory constraints are getting painful.

It seems like the real plan for the 7e is to use the docker images to make it easy to build versions with a different features set. We'll then pick a feature set (or several?) to build as part of the distribution/nightly.

My choices would be to turn off telemetry and multi-module support. I know there are 7e users who needed those things, but I think they are in the minority. Having to do your own build beats no support at all. Taking out telemetry will also help with protocol space issue. But this is all up in the air.

Actually, my idea for config files is (in the memory limited targets) to replace in the config/*.c files the const strings by smaller memory hashes. Then, when loading a file, using a variant of the MATCH* which would test against the hash of the string if there is no direct match.
When reading a "non native" ini file all the tested value would fail the "direct test", but correspond with the hashed value.
When storing, the hashed key is used, and the ini file would not be directly readable. But at next read by the 7e, the direct comparison works.

And one could use a map of the strings and their hashes to convert back the "hashed" ini file to the more compatible and human readable one.

To implement that, one would only need to create a specific .h file, only included for memory limited Txs, where all the string constants to be replaced are "#Defined" as their hash, and create an alternative set of "MATCH" macros which implements the two-step test instead of a single string comparison.
If compatibility is foreseen as a problem, one could also add the "dictionary" (list of the strings and their hashes) to the distribution, so that the ini file can be reconstitued without the exact same version.

Clearly a hack, but that could gain some bytes to the expense of the hashing time when reading the file. If that can help wait for a more complete overhaul of the config, it seems like a win to me, with limited cost.

I still like the idea of using an Android phone or tablet instead of a PC. You could connect it to the transmitter with USB and store chunks or plug-ins or whole code modules and quickly change setups. And you'd have much more computing and storage in the field then even the bigger Devos. Then there would clearly be no limit to development going forward.

The trick would be to start simple. Then phone-side development could make wonderful things happen down the road. Voice and video and more inputs and lots more. The small form-factor of the 7e would be a real asset.