Make the "increased resolution of patch cable strength" feature toggle-able in the Community Features Menu

[ok-reza]

This pertains to #17

Would like this feature to be toggle-able (ON/OFF) in the Community Features Menu.

[m-m-adams]

What's the issue with it? This feels like something where refining the behaviour is better than gating it behind a setting. As much as possible I think we should strive for clean integrations with the existing UI rather than the community features menu

[ok-reza]

Yeah, part of the desire for a toggle is that it's not refined enough yet. Beyond that, there is an underlying issue of font size and the clarity lost with smaller text.

1. It completely removes the visual bar graph for modulations (full width across display) and modulating a modulation (half width across display).
2. Currently, highlighting digits is visually inconsistent on OLED, it uses a large font underscore for the smaller font size that now displays the numbers.
3. There's a large gap of space between the numbers and the underscore highlight.
4. The period sits unnaturally below the numbers.
5. The higher resolution values on OLED are smaller in font size, so users that prefer clarity don't have an option for readability.
6. Higher resolution isn't offered for values not pertaining to modulations.

Personally, I don't need that much fidelity for the values, to get two digits worth of resolution really would be most useful for achieving the perfect pitch of a specific modulation or something. One decimal place of resolution is kind of plenty anyway IMO.

I think a more useful resolution increase would be having all numbers 0-50 being toggleable to 0-127 standard midi values, for both parameter values and modulation strength values. It opens up non-gold-knob-assigned parameters achieving the resolution gold knobs have (and visualizes them properly with a specific number). Even in this proposed case, I would want it to be toggleable option. There will be people that still want the 0-50 values they are used to, some people will start to realize that scrolling from 127 to 0 will take over twice as many scrolls on the select screen to min/max values than 50 would.

I see value in keeping 0-50, 0-50.00, and 0-127 and having them all as options based on user preference.

[m-m-adams]

Thanks for the detailed issue! That makes it much clearer where you're coming from, I mostly do sound design on my 7seg where it's a straight upgrade. @bfredl as the original author of the change do you think you could address any of the above issues?

One thought that might help is not showing the extra precision until after the encoder is clicked to select them, then having them pop up to be adjusted.

As much as possible I think we should be striving to avoid the community feature menu when we can cleanly integrate into the existing UI. Every change will have detractors but in general the feature should be morphed in a way to incorporate their feedback rather than just disable the feature. Consider especially that the new user experience will be negatively impacted by multiple menus and a confusing structure between them.

See https://xkcd.com/1172/

[bfredl]

The entire idea behind the original patch is that the behavior is completely opt-in and backwards/forwards compatible, both in terms of .xml memory and button behavior muscle memory. The defaul scrolling resolution of the the select knob has not changed, and you would select additional precision by using the <-> encoder which in all other editing menus either (1) does nothing or (2) is used to select the edited decimal or otherwise move around in the edited field.

I do agree with the concerns about the UI tho. This was the first code I ever touched involved screen rendering and it could definitely use a overhaul...

One thought that might help is not showing the extra precision until after the encoder is clicked to select them, then having them pop up to be adjusted.

This makes sense. one option is that we add a setting menu whether to use the old display layout or the new one when entering the menu. But the <-> encoder will always be active and if you use it the display would dynamically change to the new decimal layout regardless.

[bfredl]

Better integration of patch cables with MIDI learn is an interesting idea for sure, but something I consider separate feature entirely with more design considerations on its own. like wouldn't you need a mode where it maps to to the -64 ... 63 range instead so you can do bipolar modulation over midi ?

[ok-reza]

Even if no decimals show up unless you activate them via '<> scroll' they will still appear whenever you assign a modulated parameter to a gold knob (or learn it to a MIDI knob), use that knob, then select that modulation onto the display (due to the 127 value resolution). So even by adjusting the behavior in the effort to 'opt-out' of it, users will still run into it. It's just not a clean solution. At it's most innocent, this is a distracting amount of values compared to the norm, at it's worst it's an accessibility issue for those OLED users that want the largest text size where possible.

Since this doesn't fit into the criteria of 'Community Features' menu I then think this should still be a toggleable option in the 'Defaults' menu. Could be "Para" for "Parameter Scale" or something of that nature. We are adjusting the expected UI from the default official firmware. Perhaps even just as a temporarily placed toggle until an official Community Firmware release occurs. I don't want to load different firmware every time I want to experience the original behavior, even just for the sake of testing and comparing behavior (seems like a handy way to check for OLED UI inconsistencies as they are debugged).

Should we eventually be expecting two decimal resolutions for regular parameter values outside of modulations as well? Do those parameters also have the benefit of being backwards/forwards compatible?

[bfredl]

ill still appear whenever you assign a modulated parameter to a gold knob (or learn it to a MIDI knob), use that knob, then select that modulation onto the display (due to the 127 value resolution). So even by adjusting the behavior in the effort to 'opt-out' of it, users will still run into it

I know but here you are just describing a pre-existing inconsistency. Before my patch or even with an option to turn it hard-off, the behavior would be to be to show a different value to the user than the one the synth engine is actually using... Regardless, if this is considered preferable than a slightly mal-kerned comma sign, this could remain the display until the user has actively used the <-> encoder, even if the value was not an integer.

Since this doesn't fit into the criteria of 'Community Features' menu I then think this should still be a toggleable option in the 'Defaults' menu. Could be "Para" for "Parameter Scale" or something of that nature.

Hmm, I think it would be fine in the community features menu. It would just be a less intrusive change to only change the default display rather than change the behavior to be somehow doubly opt-in, and less of a thing to clean up later if we figure out a OLED display layout which is satisfiable. Anyway I will try to code up a patch so there is something to test and discuss further from there.

Should we eventually be expecting two decimal resolutions for regular parameter values outside of modulations as well?

The more I look into the code the less there seems to be such a thing as a "regular" parameter. (For instance, pitch and level parameters, without any patching involved, differ wildly in behavior w.r.t learned CC and knob mappings). the "Decimal" menu style is already used for some existing parameter kinds and this would have to be considered on a case-by-case basis for other kinds of parameters.