PARAMETERS: mapping enhancement springboards

[dndrks]

I've been thinking a lot about how the mapping function works on PARAMETERS, so I just wanted to collect some reflection here in case it's helpful. if this feels like noise, just lmk.

multi-map

• current: re-mapping a control to another parameter removes it from its prior definitions
• proposed: map many parameters to a single control
• challenges: provide user a way to quickly un-link the control from all mappings

### range (see this thread)
- current: a mapped control will access the full range of the parameter
- proposed: allow the user to refine the range of the parameter, so that (for example) a slider can focus on a subset of the parameter's values. could lead to really expressive control when combined with multi-map.

arc

• current: an arc cannot control parameters unless the loaded script explicitly supports it or if the arcify library is used
• proposed: unless a script defines arc interaction, arc could default to a mapping mode that allows the first three encoders to be mapped to any parameter. the fourth encoder could switch between multiple banks, so an arc could control up to 12 parameters across 4 banks (for example)

midi callback

• current: if a user maps a controller that has LED feedback (thinking specifically of Midi Fighter Twister or OP-Z), LEDs do not display the loaded state. user has to turn the encoder all the way to the extreme in order to align the values. if a script sets params values directly, this decouples things pretty quickly.
• proposed: provide a method to report relative parameter values as a "midi echo" back to the transmitting device on a specified channel, with a specified type (CC, note on, etc), mapped 0-127. this would also open up a potentially dumb but fun-sounding creative opportunity to map a parameter's changes to MIDI notes lol
• challenges: this might be too niche, but could be a nice MIDI QOL improvement

[tehn]

re: range, an individual issue should be made for this, it's a bug