[Proposal]: CC definitions for value and range mappings

[yuhrao]

Many devices has specific falue mappings for configuration.
Let's take Strymon BigSky as example:

CC 33 (Chorale - Vowel) has this value mapping:

value	description
0	"AAHHOO"
1	"AAHH"
2	"AAHHOH"
3	"OH"
4	"OOOHOH"
5	"OOOO"
6	Random

At same time we also have some devices that work with ranges, like HX Stopm:

CC 61 (1 Switch Looper Play/Stop):

range	description
0-63	Stop
64-127	Play

My proposal is to extend the CC schema to be able to represent those values in a more plesant way for the end user and also priovide a better experience for those who consume it via code.

cc:
  - name: 'Chorale - Vowel'
    value: 33
    min: 0
    max: 6
    description: 'some description'
    type: Parameter
    value_mapping:
      0: AAHHOO
      1: AAHH
      2: AAHHOH
      3: OH
      4: OOOHOH
      5: OOOO
      6: Random
  - name: 'Switch Looper Play/Stop'
    value: 61
    min: 0
    max: 6
    description: 'some description'
    type: Parameter
    range_mapping:
      - min: 0
        max: 63
        description: Stop
      - min: 64
        max: 127
        description: Play

[yuhrao]

I saw that the same applies for PC parameters. For EHX we have a range for change program and specific values for some parameters:

pc:
  description: 'some description'
  range_mapping:
    - min: 0
      max: 99
      description: Loop selection
  value_mapping:
    100: PLAY FSW
    101: RESET FSW

[yuhrao]

Hi @tyzjames I saw your PR #47 and I think that this issue could be an alternative for that approach.
Would you like to share some feedback in this proposal?

Thank you advance

[tyzjames]

@yuhrao thanks for the suggestion. It makes sense. I'm not sure when we can prioritise resources to look into this yet.

[tomoinn]

This would be really nice to have, a quick browse shows some pedals as having this and some without, presumably the morningstar firmware handles both cases?

[tomoinn]

I ended up adding a new optional block to the YAML files for my own purposes (and doing a lot of manual editing, because adding this feature shows up a huge number of other data quality issues). I've added a new key, cc_groups with simple value and name properties. If this key is present, and multiple CC messages are defined in the file for a given value, my code can then show the group name as the 'control name' in my UI and uses the CC names and ranges as values within that key. (I also attempt to extract this automatically for a few common patterns, i.e. ones where the names are something like Group : Value which is reasonably common).
This works for me and is non-invasive in terms of the other file processing. For simple CCs where there's only a single definition it makes no changes to the file structure, and for ones where discrete CCs or ranges thereof have a semantic meaning it handles that pretty well. Good enough for my purposes!
I actually end up turning this into a comment shown in the UI when that combination of device and CC value is chosen, I'm not trying to build anything more complex than that for now.