The idea is simple maybe, the implementation… probably not.
I have a mixer+FX [gen~] patch going where I can select different routing destinations for the Daisy Patch’s CV inputs, allowing me to choose which four of the WAY more than four variables the CV inputs are affecting. COOL!
BUT! The only way to know what the destinations are is to keep a number table on paper or in my head.
The idea would be to enable some text feedback on the screen to show the destination parameter name instead of an integer. Quite honestly I have no idea how it could be done with [oopsy~] but it would be a great feature for complex mixer/FX patches with many variables where, for example, you’d like an external LFO to affect the volume of an audio input channel one day but the next day affect an “aux send” to a delay instead, leaving your mix parameters to be handled with the encoder. -The issue being that you could recreate a rather complex multi-osc synth voice with filters and FX and whatever you want BUT [oopsy~] “forces you” to hard-code what the CV inputs are affecting.
Just riffing here 
This would undoubtedly require another bunch of custom [oopsy~] named objects akin to the dev branch MIDI objects, but I can dream, right?
The current param page on the OLED lets you dynamically map the encoder to extra params. So, hypothetically, perhaps this page could also let you remap CV/knob etc. inputs to other available params?
It adds more overhead to the UI, and to the code (now analog inputs need to be mapped through a kind of matrix router), and will add to the menu-diveyness, … and probably these mappings should be saved between reboots, so we’d also need to get the QSPI stuff working first.
There’s been another request for more modal mappings, e.g. a patch has say 3 modes, and in each mode, the knobs/cvs map to different params. Could be e.g. [param knob1_mode1_foo], [param knob1_mode2_bar] etc. Would that be sufficient?
I’m kind of leaning to the latter simply to reduce the menu-divey depth, and because it would probably cohere better witth a custom-UI that is also requested.
That sounds like a decent idea but maybe would restrict a parameter knob to only appear in one mode, unless you had [param knob1_mode1_foo] AND [param knob1_mode2_foo] which could work for most patches or cause mayhem with others.
With unlimited modes available you could do anything, I suppose.
A persistent menu item to choose OR a modulate-able mode parameter?
Adding to this idea, if’n you could ‘fetch’ what mode you’re in from inside the patch then you could have some interesting fun.
Thinking aloud, I guess, [param knob1_mode1_mode2_foo] could work? For knowing which mode you are in, perhaps [param ui_mode]? It wouldd need @min 0 and @max 3 for 4 modes.
It’s really getting a bit clunky though. I’d like to step back and look at what the custom UI thing would need, and see if there’s some intersection of these two conceptual requests that could be both lean, flexible, and not too clunky.