Allow reducing the number of player control gesture zones

[PowerUser64]

Checklist

• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have read the FAQ and my problem isn't listed.
• I'm aware that this is a request for Tubular itself and that requests for adding a new service need to be made in vanilla NewPipeExtractor.
• I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
• This issue contains only one feature request.
• I have read and understood the vanilla NewPipe contribution guidelines.

Feature description

I noticed that there was recently a third "middle" gesture zone added for changing video speed. I've used this feature on and off for the last week, and I've noticed that it tends to get in the way more often than it helps. Quite often I'll try to change the volume of the video, and even though I know that the middle gesture zone is there, I often end up hitting it and speeding up my video massively, rather than changing the volume. The same goes for the screen brightness.

The settings menu offers a way to change what the left, right, and middle gesture zones do, including a way to disable them. However, disabling them doesn't actually make the gesture zone go away, it just disables it, so it does nothing. Doing this at least keeps the video from being massively sped up when I swipe in a slightly wrong spot, but it also means that the gesture still doesn't do what I want it to.

As a solution to this, I think that Tubular should offer an option to disable the "middle" gesture zone, or some way to change its size. It is a lot harder to tell where the gesture zones start and stop now that the gesture area is divided into three parts rather than two.

Also, in terms of muscle memory and habit forming, having two gesture zones also gives a clear division of tasks between two hands: left controls brightness, and right controls volume. When there are three actions, the division is less clear.

Why do you want this feature?

This would make it easier to form muscle memory and use Tubular. (See "feature description" above for more on this.)

Why ist the feature relevant to this fork?

1. This feature is not present in NewPipe, as far as I can tell.
2. There's a typo in this issue template - "Why ist the feature..." ("ist" isn't a word). I will open a PR for this. (created: fix(feature-template): fix typo in feature_request.yml #240)

Additional information

I have two additional things to share. First, some alternative ways to achieve what I'm suggesting here, and second, some feedback on the speed swipe gesture itself.

Alternatives

I can think of two alternative ways this could be done, although allowing outright disabling it is simplest.

The first option would be to allow changing the size of the middle zone, in the form of a percentage of screen space. It could default to 1/3, but it should be user-configurable to be any value from 0-100 (inclusive). Setting to zero would disable it, and setting to 100 would make it the only touch zone. This would let users set how big of a touch zone they can reliably hit without accidentally hitting a side zone.

The second way I can think of to do this is to introduce a horizontal swipe gesture, rather than having a vertical one. I think that a horizontal gesture is a much better expression of changing the speed of a video than a vertical swipe in the middle of the screen, even if it would make for more complicated gesture detection code.

Notes on the speed control itself

Maybe should be a separate issue, but I have a few points of feedback on the speed control itself. In short, I think the control should more closely mirror the "tempo" control in the playback rate menu. More specifically, I mean:

1. The speed control is not curved (and it should be).

The speed control should have the same curve as the slider in the tempo and pitch menu. The middle value of the control should be 1x speed. Also, no matter what the current speed setting, moving this control the same distance should always change the speed by the same perceptual amount each time. This means that, much like the playback rate menu, the larger numbers will be closer together on the control, and the numbers closer to zero (0.5x, 0.25x, 0.1x) will be further apart. This is because making something play 2x faster means doubling the playback rate. 1x->2x, 2x->4x, 1.5x->3x, 0.5x->1x. Notice that the numbers change more as they get larger (2x->4x is +2x, but 0.5x->1x is +0.5, even though they both double the playback rate).

2. The control increments are too large

The playback rate swipe control has very large and imprecise steps for changing the playback rate than what the playback rate menu allows for. This makes it feel clunky to use. Rather than offering steps in 0.25x increments, I suggest allowing the full 0.01x increments that the playback rate menu allows for. Controls are really only useful if they are precise and do what you want. Right now, this control is hard to use effectively because it is so imprecise that it can't really express what I would like to do with it.

---

All this said, thank you for your hard work and dedication to making Tubular what it is! I really appreciate what you and all other contributors have done to make this software what it is today.

[asandikci]

It would be easier to implement middle gesture space percentage as user-configurable. Horizontal gesture will need more work.

1. The speed control is not curved (and it should be).

🤔

2. The control increments are too large

Gesture increment follows the step in menu. Change step in menu and try again 😉

[PowerUser64]

"What do you mean by curved?"

By curved, I mean in the mathematical sense. The slider for changing the tempo uses the Quadratic SliderStrategy, which applies a curve to the slider. This curve is needed because tempo changes are not a linear operation. Going from 1x speed to 2x speed is not the same as going from 2x speed to 3x speed, and the slider needs to correct for this. This kind of correction is extremely common in other software, such as music production software.

The curve used by the main tempo slider is defined as follows:

Tubular/app/src/main/java/org/schabi/newpipe/player/helper/PlaybackParameterDialog.java

Lines 64 to 68 in c46ffd9

	private static final SliderStrategy QUADRATIC_STRATEGY = new SliderStrategy.Quadratic(
	MIN_PITCH_OR_SPEED,
	MAX_PITCH_OR_SPEED,
	1.00f,
	10_000);

For a more pictorial explanation of this phenomenon, I have modeled QUADRATIC_STRATEGY on a graph:
https://www.desmos.com/calculator/afrvhyjizp

The slider attached to the "SliderPos" variable is equivalent to the slider in the playback rate menu.

---

Gesture increment follows the step in menu

The connection between these is a bit unclear, I think that most users will not be able to figure this out.

The increment in the playback rate menu is for changing the increment applied by the buttons in that menu, and there is no affordance that demonstrates a correlation between that increment and the one used by the new speed gesture.

This increment in the menu is needed because the buttons can only move the tempo in finite increments, but sliders (both the one in the playback rate menu and the gesture) are not limited by changing in finite increments — they can reach any value in their range. Why add unnecessary quantization steps on top of this?

Is it so the number stays round? If that is your goal, the quantization increment should either apply universally to all sliders (tempo and pitch), or it should be an entirely different setting (eg. "Increment (Sliders)"). Right now, the increment of the gesture is controlled by a value that both is made for use in a different control scheme, and has no clear connection to the control it is affecting. If you go the route of making a setting for controlling the tempo quantization increment, the increment should also apply to the tempo and pitch sliders in the playback rate menu, so as to clearly communicate that that the control is global.

Also, because the increment is being used on a slider, it should be applied on the slider level (as in, quantize the 0-1 "SliderPos" variable in the graph), rather than quantized on the tempo multiplier level (the 0.1x-5x number calculated by the graph) because otherwise the quantization will counteract the curve that increases the precision for small values. (Numbers that look nice and round in base-10 like here aren't actually what we want as tempo multipliers because they are not spaced in perceptual increments.)

[klaviartur]

Hi @PowerUser64,

maybe as the creator of this feature, I should respond to your issue.

Firstly, I am sorry, that the feature does not add the same value for you as it does for me (and others, that explicitly thanked me for that). But exactly for the reason, that there may be persons with different taste than me, I tried to make this feature fully reversable, which obviously failed.

I don't know, where in the process this went wrong, but in the last tests I remember before opening my PR, deactivating the middle gesture restored the 50/50 split between the left and right swiping zone. As I don't ever have it deactivated in my personal use though, I didn't catch it not working in the meantime. Thanks for pointing it out. I will try and fix it in another PR.

The horizontal swiping I would rather use for other features in the future, e.g. palyback positioning.

Regarding the quadratic slidestrategy, I think you are completely right, it should be implemented.

To be honest, I just didn't want to invest more time than necessary to implement the speed swiping gesture I was craving fr so hard, except for the aforementioned (failed) effort to make it reversable. For me personally it works sufficiently well and I am not willing to put more time into this at the moment.

Hope, this helps you.

PS: Yes, the stepping size is so my inner Monk can have nice round numbers. I have it set to 0,25x.

Edit: Looking at the source code I obviously hallucinated testing restoring the 50/50 split between the left and right swiping zone 🤦 . PR with fix is out.

[klaviartur]

@PowerUser64
In the meantime until PR is merged, consider setting the center swipe action to "volume" too, additionally to the right one.

[PowerUser64]

Thank you for your response @klaviartur!

I think this feature is actually fine, but my gripe with it is that the gesture zone's size isn't configurable. The current size of the middle gesture area is too easy for me to hit. The ergonomics of the gesture are probably impacted by the ratio of screen size to how long your thumbs are. Having a 1:1:1 ratio isn't good on my screen size because I hit the middle one too much. A 1:1:1 ratio might work well on some devices (possibly larger ones), but it doesn't work very well in my case.

If I were to propose a minimal change to this that (IMO) would resolve this issue, it would be to make the middle gesture size to be a lot smaller, so it's closer to 1/7th of the screen size. This is because the center of the screen is easy to find, and having that gesture zone be on the dividing line down the center would not interrupt the sides too much. That said, a configurable size for the middle gesture (in % of screen size) would probably be ideal though. Here's a plot to show what 1/7th would look like: https://www.desmos.com/calculator/cgebehktgo.

I look forward to trying out your latest change, thanks for the update!

[klaviartur]

@PowerUser64 Actually, currently it is not even 1:1:1, but 3:4:3, which is even worse for you. The reason for this is that my short thumbs didn't reach the center area conviniently at 1:1:1 😉

I agree that choosing the center portion in % would be ideal.
The only downside being having another settings item, it's already quite cluttered.

Maybe I'll take the time and implement it sometime.

[PowerUser64]

Actually, currently it is not even 1:1:1, but 3:4:3

Ahh, no wonder :P

The only downside being having another settings item, it's already quite cluttered.

Yes 😂
Settings is quite cluttered right now. I think you could probably justify making a "gestures" group in the settings menu and putting it above the behavior section. Behavoir is probably the most cluttered section at the moment. It could really use some organization IMO. I'm not sure how far Tubular wants to stray from Newpipe in this way though. Whatever you think you'd prefer to write though.

Thanks for your time on this.

[klaviartur]

I just opened another PR #258 which allows to choose middle gesture area width between 15, 25, 33 and 40 percent.

[PowerUser64]

Great idea! I think this is a great way to handle this. Those sizes will probably work for most people. I also think that the default of 33% is good, since most people will probably assume each touch zone takes up a third of the screen. I would be interested to know what most people put it at.

I tested out your new PR #258 and your previous one #255, and things seem to work as expected! Changing the middle gesture size works as expected with #258, and removing the middle gesture with #255 makes the side gestures each take up half the screen just like before! Hopefully these are able to be merged soon.

Once they're merged, I would definitely consider this issue resolved. There are a few sub-issues that should probably be created from this regarding quadratic slider strategy and the tempo step size setting, but the core of the issue is definitely resolved through these. Thanks for your work, I really appreciate the time you've put into this!

[klaviartur]

I'm glad, it works for you.
I agree, that the 1:1:1 ratio is most intuitive.
Furthermore it is rooted in upstream NewPipe itself, where the function for getting one of three areas is already present, but does not affect swiping but only tapping (for skipping). The middle third pauses the video on double tap.
One possible caveat of my implementation is that I didn't separate those uses, which means that the tapping areas are also changed by the setting.

@PowerUser64 I'd like to hear your thoughts about that.

[PowerUser64]

Oops, miss-click. I didn't mean to close. @asandikci could you re-open this? I don't seem to have that permission.

[PowerUser64]

Ah, interesting! I didn't notice that. I think it's probably alright for these zones to have the same sizes, since their positions are probably ingrained in peoples' fingers to a certain degree. Part of me thinks they should be separate since they're for different purposes, but another part of me thinks it's probably fine to leave them paired together since what feels right for one set of actions will probably feel right for the other set of actions (due to things like the ratio of thumb to screen size that I mentioned).

I think that, although separating them might seem like the right choice from a separation of concerns perspective, I think that from the perspective of wanting to create consistent user interfaces (consistent enough to develop muscle memory for), it probably makes sense to have them set to the same values. More variability makes things hard to predict.

This is a really good question to ask though. I think the way it is right now is probably good. That said, I haven't done extensive enough testing with #258 yet to say how it feels in practice (to me at least).

If we leave it, this setting might need a new description in the menu to better communicate what it's doing. Right now, it seems to imply that it's only the setting for swipe gestures, since it's positioned near them in the list. Changing the note to mention how users should "change this setting so taps and gestures feel right on their device" would probably suffice.

Does this help @klaviartur? I'd be interested to hear your thoughts on this as well.