Make config files more human readable

[szszoke]

Two bit field properties are used for device definitions: filesystems and storage. While this works for computers, it is not very friendly for human users. One needs to know what binary means, what binary OR is, what hexadecimal numbers are, etc. This is all fine for programmers but even to us it could be more intuitive to see a more verbose value that is spelled out in human terms.

A potentially better way to handle this in JSON would be to make both of those into objects and have a boolean property in the objects for each bit.

Before:

{
  "id": 43,
  "name": "Elektron Digitone II",
  "alias": "dn2",
  "filesystems": 280,
  "storage": 0
}

After:

{
  "id": 43,
  "name": "Elektron Digitone II",
  "alias": "dn2",
  "filesystems": {
    "samples": false,
    "raw-all": false,
    "raw-presets": false,
    "data-any": true,
    "data-project": true,
    "data-sound": false,
    "data-preset": false,
    "data-ii-preset": true,
    "samples-stereo": false
  },
  "storage": {
    "plus-drive": false,
    "ram": false
  }
}

Omitted properties could be evaluated as false, in which case the device definition could be simplified to this:

{
  "id": 43,
  "name": "Elektron Digitone II",
  "alias": "dn2",
  "filesystems": {
    "data-any": true,
    "data-project": true,
    "data-ii-preset": true
  }
}

Parsing this schema into something that is usable in C would not be difficult. The final result could still be kept in an integer. The default value should be set to zero however.

One could check for the presence of filesystems and storage. If they are numbers, then they could just be parsed as such.

If they are objects then one could iterate over all the possible keys and for those that are present in the object, and the value is true, the corresponding bit could be set in the bit field integer.

Another possibility is to use arrays for filesystems and storage where the arrays contain a set of keys. There would be a key for each possible bit. Each key would have a corresponding offset in the final bit field integer, and for each valid key that is present in the filesystems / storage array, the corresponding bit would be set.

Example:

{
  "id": 43,
  "name": "Elektron Digitone II",
  "alias": "dn2",
  "filesystems": [
    "DATA_ANY",
    "DATA_PROJECT",
    "DATA_II_PRESET"
  ]
}

Neither formats would compromise on the robustness of using a bit field for configuration:

• Objects by definition cannot have duplicate keys therefore a bit cannot be set to true and false at the same time
• The arrays could have duplicate values but those would not make any difference because the only thing that would be inferred from the presence of a key is to set a bit

The parsing logic could either silently ignore the unknown keys or potentially show a warning but there would not be a need to treat those as errors. This would have an application in testing a unreleased version of Elektroid and then going back to the stable version.

I recognize that having an object instead of a bit field would make the device definitions longer and more verbose, but in this case that would actually be a good thing because the device definitions would be more human readable than they are today.