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

An overarching temposync UI/UX plan #1351

Open
Andreya-Autumn opened this issue Sep 19, 2024 · 12 comments
Open

An overarching temposync UI/UX plan #1351

Andreya-Autumn opened this issue Sep 19, 2024 · 12 comments
Labels
Design Required We need to design a solution to this issue Experimental Issues related to experimental features that may or may not see the light of day Host Automation Issues related to DAW (host) automation Modulation Modulation related issues Temposync Support UI Issues related to UI look&feel UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc.

Comments

@Andreya-Autumn
Copy link
Collaborator

We've discussed this on and off but never made an issue.

Massive X does this:
mxts
Which is very nice.

The num/denom is a UI idiom that we're implementing in some other places too (audio rate procs, phasor speeds) now, so we could definitely do something similar.

There are some questions to answer (some of which we need to answer whether we use this solution or not), including:

@Andreya-Autumn Andreya-Autumn added Design Required We need to design a solution to this issue Experimental Issues related to experimental features that may or may not see the light of day Host Automation Issues related to DAW (host) automation Modulation Modulation related issues UI Issues related to UI look&feel UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc. Temposync Support labels Sep 19, 2024
@Andreya-Autumn
Copy link
Collaborator Author

"How many notches" I think is tricky to answer. If we steal the MX design straight up, the answer is probably five. Which might be ok maybe?

OTOH, I had an idea which was basically that we can have something called a "temposync map" which is a user editable list of ratios (UI TBD), which dictates the values a time param will snap to.

You could then make the default temposync map be the same ratios we've been using in Surge etc. Prime limit 3, that is. And if someone* wants quintuplets and 5 sixteenth notes and the like, they edit the map and put in 4/5, 5/4 etc.

Then we don't have to show all the ratios next to the knob/slider, which would let us do more options.

@Andreya-Autumn
Copy link
Collaborator Author

*someone == me. Let's be real. :)

@mkruselj
Copy link
Collaborator

The point of seeing the ratios outright is that you see what you're switching to. Hiding that away behind a map or a tooltip is hampering the UX.

@Andreya-Autumn
Copy link
Collaborator Author

Only allowing 5 ratios is also doing that wouldn't you say? Especially if we get temposync+modulation (and thus automation) working I can really imagine Kinsey (and the others who wanted it in Surge) being a bit bummed about only having 5 temposynced speeds.

Maybe showing the ratios in the tooltip is enough?

@mkruselj
Copy link
Collaborator

After using MX for a long time I don't think putting the ratios in the tooltip is gonna cut it... but it seems like we don't really have a choice. It's definitely problematic, because we really don't have that much room to show even five (if you go by how the phasor page looks like in the wireframe)...

@mkruselj
Copy link
Collaborator

OK now I just thought of another option that might save us. If we have a knob arc but show the current ratio inside the knob, that would solve the display so at least you know which one you're on. You won't be able to see which one you are going to, though. Unsure how problematic that would be.

Also, the knob arc should probably show notches on it so that you can see how many steps to go through there are (this would automatically refresh depending on the number of ratios you put into the map).

Quick KnobMan mockup:

ts

@Andreya-Autumn
Copy link
Collaborator Author

Good idea! I do wonder if it'd look weird with knob bodies engaged. But we can probably make it work!

@mkruselj
Copy link
Collaborator

I think the idea is fully incompatible with knob bodies and would look strange af. So even if knob bodies are enabled, in this case the knob should not have the body.

@Andreya-Autumn
Copy link
Collaborator Author

You don't think rotating the ratio along with the knob body is a good idea? 🙃

Jokes aside, yeah I guess that works. Or you could just say if knob bodies are on you have to make do with the tooltips. Which is also fine.

@mkruselj
Copy link
Collaborator

No, that completely changes the UX when knob bodies are just a visual feature. It should not be detrimental to the experience, which in this case it would be.

@Andreya-Autumn
Copy link
Collaborator Author

Hmmm... I see your point but I don't know that that's necessarily the case. Which of the knob body and the ratio is the better experience isn't objective. Under modulation the ratio would often be wrong for example. Personally I'm fine reading the tooltips (and I like knobs better than no knobs as you know).

@mkruselj
Copy link
Collaborator

Regardless I don't think it's a good choice to make in this case. I don't think enabling knob bodies should completely make you reliant on just the tooltip to see the current ratio. It is a bad design.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Required We need to design a solution to this issue Experimental Issues related to experimental features that may or may not see the light of day Host Automation Issues related to DAW (host) automation Modulation Modulation related issues Temposync Support UI Issues related to UI look&feel UX Issues related to user experience (UX) - mouse, touch, keyboard, MIDI inputs, etc.
Projects
None yet
Development

No branches or pull requests

2 participants