Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QoL UI: user feedback for the meaning of macro selection #5813

Open
j5v opened this issue Jan 23, 2022 · 3 comments
Open

QoL UI: user feedback for the meaning of macro selection #5813

j5v opened this issue Jan 23, 2022 · 3 comments
Labels
Feature Request New feature request UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc.

Comments

@j5v
Copy link
Contributor

j5v commented Jan 23, 2022

Is your feature request related to a problem? Please describe.
This is a quality of life UI feature that gives feedback to the user about what they have selected in macros, in cases where the effect is nontrivial.

For patches where formula LFOs take macro input to then modulate other parts of the synth, where the modulation outputs are not straightforwardly 0..1 continuous or linear, but are instead modes of operation or interpolated discrete states, that the user would want to know about. The feedback text would come from a formula LFO, while the user would be changing the macro slider.

For example, I might have a macro slider that selects from:

  • Different modes of an instrument that use a similar model, e.g. [double bass, cello, viola, violin] or [bass, tenor, also, soprano].
  • Vowel and formant morphs, from more than one macro slider.
  • Sliding a window over the tunings and resonance of an instrument.
  • A sweep over frequencies or levels, and the user would benefit from a readout with context.

Describe the solution you'd like:
Possible solutions (one, many, or all)

  1. A readout as float text (basic, but we'd need to make good API decisions to make formula code still work if we do the next step).
  2. An always-visible text panel. Stretch: multiple lines (main UI or tear-off) that macros can address by line. If space is tight, or accessibility is difficult, then we could optimize how these lines are shown, or have a single-line state.
  3. To help with the non-continuous slider, a design-time parameter to select the number of quantized steps (0 = continuous). That reflects in the UI as a scale, and discrete steps for the slider. There are use-cases for different partitioning modes: n.0-centred (interpolations), and n.5-centred (discrete modes).

Impacts:

  • Slider/macro UI: background reticules for steps. Options: number of steps, snap to step, step or zone.
  • Formula LFO: API, object model. New side effects to the UI state.
  • Skin design: a new multiline status display.

Describe alternatives you've considered:
.

Additional context:
If we don't want macros to send unclamped values, then the slider output can still be 0..1 for all these cases, because the formula LFO can scale to context. It's an extra step for the sound designer to reconcile the slider steps with the code.

This is an advanced use case, used by (I guess) less than 5% of patch designers, but it would provide more meaningful context to users, for macros that would otherwise be difficult to use.

@j5v j5v added the Feature Request New feature request label Jan 23, 2022
@mkruselj mkruselj added the UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc. label Jan 23, 2022
@mkruselj mkruselj added this to the Currently Unscheduled milestone Jan 23, 2022
@j5v
Copy link
Contributor Author

j5v commented Jan 23, 2022

Alternatively, use the existing modulation UI, to have a formula output 'modulate' the UI Status lines. Instead of 'adding' like the other modulators, this modulation just copies the text to the Status line. This seems a lot simpler than adding side-effects to the object model, and scanning these states for changes.

@baconpaul
Copy link
Collaborator

This is super interesting. I've thought a lot about the modulation graph and how the orange arrow (in S16 and later) and the formula modulator (in XT) obscure it, even with things like the mod list. Mod Mappers will do the same. We did purposefully make the extra state opt-in so we could infer a maximum graph from the init state, but of course that's not the same as displaying value transformations.

Very interesting

@mkruselj
Copy link
Collaborator

I think a better way to deal with this is to simply have additional state stored per macro. Namely:

  • A mode selector: is macro float unipolar, float bipolar, bool or enum? Obviously it would be normalized 0...1 all the same.
  • In case of bool, the macro slider changes its behavior so that it only reacts on mouse down and disregards any drags.
  • In case of enum, a dialog pops up with a value edit which picks how many steps we want, and the same number of text input fields to set a display value for each enum. Macro slider gets quantized to this number of steps. To simplify things I would discard any options to change the weighting of the enum spread within 0...1 range. This is really taking it overboard IMO.
  • I would make a concession here and just suggest that float modes just always show +/-100% and that's it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request New feature request UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc.
Projects
None yet
Development

No branches or pull requests

3 participants