Distorted audio and no progress when navigating through song with arrow keys

Problem

Since the GtkScale under the waveform can be focused, it is (kinda) possible to navigate through the song using the keyboard by Tab-ing to the scale and then using the arrow keys.

However, since the page-increment and step-increment values of the GtkAdjustment given to the scale are both zero, the position remains unchanged when trying this.

While this is happening, the audio also quickly repeats, leading to a distorted sound.

Alternative solution

The page-increment and step-increment values of the GtkAdjustment could be updated to practical values, which would also fix #7. This is still bothersome to use on a keyboard, and some additional logic must be added to ensure the GtkScale never goes below 0/above the maximum.

Appendix

Here's a video where the specified current behaviour can be seen and heard:
Screencast_16.12.2023_04:28:36.webm

Related to #28

Related to #7

The issue should be fixed. The fix allows using the arrow keys to seek.

For the proposed solution allowing navigating through the audio file via the keyboard, Gtk won't allow this as it uses arrow keys for moving focus between elements. Overriding this behavior would require hacks if possible and may lead to bad UX problems.

When I tested using step-increment yesterday, using only this simple fix did not work as expected.

When you are at a position below the step increment, you cannot go to position 0 as you get reset to your old position.

Also, when just scrolling forwards for some time, the progress bar behaves very weirdly.

Could you test the latest CI build to see if the potential issue is present?

I tested the CI build.

The bug I just mentioned (only being able to skip 10 full seconds, not less) is there.

Also, if you scroll over the end of the song for the first time, you start at the beginning. After this, the scale and visualization both behave very weirdly.

Additionally, only the arrow keys do something. Scrolling over the scale still does nothing. ~~This is because using the arrow keys increments by step-increment, but scrolling increments by page-increment. page-increment is still 0.~~

Video showing first two bugs:

Bildschirmaufzeichnung.vom.2023-12-16.16-38-24.webm

Hi. your attached video seems to be broken.

And for the scrolling behavior, make sure to download the latest CI build. After you do so, please report the version installed.

Hi. your attached video seems to be broken.

That's just the GitHub video player being bad. Try opening the video in a new tab, that works for me.

Okay, the video is now loaded. I'm unsure what behavior you are trying to show though

And for the scrolling behavior, make sure to download the latest CI build. After you do so, please report the version installed.

I used the latest version (0.1.7-491eae6).

I think I know what's wrong.

decibels/src/player.ts

Line 213 in 491eae6

const delta = dx * 1000000;

In this line you multiply the horizontal delta with a fixed number.
However, a PC mouse can only scroll vertically.

So now, laptop users with a touchpad can scroll from left to right, but you cannot scroll using a normal PC mouse because it can scroll only from top to bottom.

In a comic reader I developed some time ago, I used this:

    if input_source == Gdk::InputSource::Mouse
      if dy > 0
        index += 1
      elsif dy < 0
        index -= 1
      end
    end
    if index == 0
      if dx > 0
        index += 1
      elsif dx < 0
        index -= 1
      end
    end

I'm unsure what behaviour you are trying to show though

In the first ten seconds, I press the left arrow key repeatedly. There you can see the GtkScroll resetting to its previous position all the time.
From 0:10 - 0:12, you can see that the user can scroll over the end, starting at the beginning.
When this happens, the song is paused. In the paused state, you cannot scroll over the end again.
In the last few seconds, you can see me pressing the right arrow key repeatedly. There, I'm never able to reach the end of the song. This is similar to the first bug.

So now, laptop users with a touchpad can scroll from left to right, but you cannot scroll using a normal PC mouse because it can scroll only from top to bottom.

This is indeed true. I use a laptop, and scrolling left-to-right is most sensible. How I see it works is I can either choose to get horizontal or vertical scroll events, or both. In the "both directions" situation however, GTK doesn't report the direction currently being scrolled to so it's a bummer, and we have to choose one.

Maybe switching to vertical is better.

In the first ten seconds, I press the left arrow key repeatedly. There you can see the GtkScroll resetting to its previous position all the time.

This seems to be a GTK bug. GTK handles the scale scrolling, and when you under-scroll (scroll before 0), GTK should automatically clamp the value to 0. (by using the lower attribute.) I will be seeing if I can create a GTK issue.

From 0:10 - 0:12, you can see that the user can scroll over the end, starting at the beginning.
When this happens, the song is paused. In the paused state, you cannot scroll over the end again.

This is because, when you scroll to the end, the audio is automatically restarted (in other words: seek to 0, and paused) so that's why the behavior ensues. What would you like to happen when you scroll over the end?

In the last few seconds, you can see me pressing the right arrow key repeatedly. There, I'm never able to reach the end of the song. This is similar to the first bug.

Why would you want to skip to the very end of a track?

This seems to be a GTK bug. GTK handles the scale scrolling, and when you under-scroll (scroll before 0), GTK should automatically clamp the value to 0. (by using the lower attribute.)

I have already experimented with this.

While this bug happens, the following message is printed on the console:

gtk_media_stream_seek: assertion 'timestamp >= 0' failed

I suspect that somewhere in the typescript code, 1 second is subtracted from the current scale position.
Setting the GtkAdjustment's lower property to 1000_0000 (10 seconds) fixes the issue completely, but causes other weird issues (only being able to scroll from 0:10 onwards).

Problem

Suggested solution

Alternative solution

Appendix