Rockbox Technical Forums

Rockbox Development => Starting Development and Compiling => Topic started by: lee321987 on February 24, 2009, 06:20:42 AM

Title: Skip to next song when time left is less than "Skip Length" setting
Post by: lee321987 on February 24, 2009, 06:20:42 AM
I'm looking to change the source so that I get this effect ----- (assuming "Skip Length" is set to 1 minute) When there is less than 1 minute left in the current song, and I click the 'skip forward' button, playback skips to the next song in the playlist (instead of doing nothing).  Would this take a lot of work?
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: kugel. on February 24, 2009, 12:30:19 PM
I'm looking to change the source so that I get this effect ----- (assuming "Skip Length" is set to 1 minute) When there is less than 1 minute left in the current song, and I click the 'skip forward' button, playback skips to the next song in the playlist (instead of doing nothing).  Would this take a lot of work?

It's in gwps-common.c, in the function play_hop(). Adding audio_next(); before the first return; will enable this.

However, it appears the current behavior is intended.
It is sad, I'd find this feature overly useful, if I wouldn't need to disable it in normal audio playback. As of now, this feature is more or less useless for me, even if I'd really love to use it. This behavior though, disqualifies it for me.

Reading through: http://www.rockbox.org/tracker/task/6188 , apparently quite a few people expressed their wish to be able to skip to the next song. To prevent accidental skips, sdoyon decided against implementing this.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: Llorean on February 24, 2009, 01:31:20 PM
We don't prevent accidental skips in normal playback mode either. It's not like it's impossible to skip backward if you leave the song. I'd agree that it should be changed so that if you're less than a single 'skip length' from the end of the song, skipping takes you to the next song. If you need to come back you can always just skip back and re-find your position. If you never want to leave the single file, you should have a single file playlist.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: kugel. on March 02, 2009, 08:35:04 PM
I had some email conversation with Stephane Doyon. He said the way it works now is indeed intention, and he basically doesn't want to see it changed. I can understand his reasoning, so I think we should come up with another compromise.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: Llorean on March 02, 2009, 08:46:07 PM
What, exactly, is his reasoning? Is he incapable of skipping back to the song he wanted to be on, if he accidentally skips too far?

If he just wants to stay within one song, he can set "Repeat 1" just like everyone else has to do. This feature shouldn't change other behaviours beside the skip length, especially when there's another setting for changing the other behaviour.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: kugel. on March 03, 2009, 02:55:08 PM
This was his response, where he clarified his intention;
Quote
On Fri, 27 Feb 2009, Thomas Martitz wrote:

> Hello,
>
> I really appreciate your work on the Study Mode/Skip length feature.
>
> However, over the time, I've noticed repeated requests to be able to skip the current song, when the skip length is longer than the remaining time.
>
> Not only that the initial task already contains multiple wishes for that, in IRC and on the forums (e.g. http://forums.rockbox.org/index.php?topic=20739.0) the wish is expressed relatively often.
> I, for myself, would love to use this feature. But I don't only listen to long songs/audiobooks (you sometimes appear to only listen to this kind), but also to "normal" music. This means constant changing of the skip length setting. This is, imo, totally necessary, since the skip length feature could very well also be used for normal music. This disqualifies the feature for me.

I listen to music too but don't really use the skip feature in that case.

I don't remember ever setting it higher than a few seconds myself.

> I could commit the change right now, as it's one line. But I don't want to change your code without talking about you about it first. Reading the comments, you intended the current behavior. I'd really appreciate if we can discuss the pros and cons of the current behavior over what the request wants (and vice-versa).

I appreciate your noticing that it was intended. Thanks for looping me in.

Do you find it useful for music? Or is it just annoying to turn skip length off?

(The first versions had a hotkey to turn skipping on or off, but of course that didn't fly. I also used to have a separate feature so I wouldn't lose my length setting, but someone simplified that away... On the e200 it's OK because there's another key binding to skip track, but on my x5 it's an annoyance.)

Perhaps you've guessed that the reason I did it that way, is that once you overshoot and go to the next track, you can't come back to the end of the previous track. I wouldn't really mind it going to the next track, but what I'd want is for someone to fix the rewinding so that I can come back to the end of the previous track.

To sighted users, overshooting is just an annoyance: you can go to the previous track and seek forward.

But there is no way for a blind person to seek to the end of a track. Unless you can recognize your position from the audio and go in baby steps and are very lucky, you'll seek to the end and it'll jump tracks when you release the button. (A clumsy workaround might be for seek to disengage 3 secs before the end of a track, but that too would be wrong and that would be changing pre-existing behavior.)

Note that seeking too is blocked on the end of a track (at least in the old build I'm running). So the idea did not seem too strange.

A secondary concern is that it may be desorienting to automatically skip tracks, as the user would not be aware of it, and it could be a problem if they're looking for something specific. Adding a beep on track skip would take care of that. (I wonder if that could be done reliably: if the user is repeatedly skipping, he might interrupt the beep... and beeping is a bit flaky...)

I will admit it is not very often that I need to go to the end of a track, but it does happen from time to time. Tracks often break on the beginning of a chapter, and sometimes you want to refer to the last pages of the previous one. Or find the end of an episode. Once I had a broken book with tracks wrongly ordered and they were not cut at chapter boundaries...

Reading the forum post: it hadn't occurred to me to make a single track playlist for those cases where I want to find the end of a track. Kind of sucks but I suppose it's not too bad. Oh wait though: wouldn't I just overshoot and fall off the end of the track and playback would stop, and I still couldn't find the end...

Hmm... does this give you any new ideas?

--
Stéphane Doyon
<s.doyon@videotron.ca>
http://pages.videotron.com/sdoyon/

This is his response to my second email (my whole email should be quoted):
Quote
On Fri, 27 Feb 2009, Thomas Martitz wrote:

>> I listen to music too but don't really use the skip feature in that case.
>>
>
> Me neither, because it's tiresome to turn it on and off and on and off, again and again.
>
>> I don't remember ever setting it higher than a few seconds myself.
>>
>
> That's the big problem. You indented it for few seconds, which of course require many many presses. This is of course more likely to accidental skips.

Not enough buttons.

Perhaps it would help you to understand my perspective if I explained a bit how all this started: often with the cheesy joystick on my x5 I would accidentally skip tracks while reading audio books, and it would be exceedingly painful to find my place again. It would happen often enough, the bus would hit a bump while I was adjusting the volume, or I wanted to rewind a brief passage and wouldn't hold the button long enough. My first stab at this was a function to lock out track skips: the action would just do nothing. One of the first comments I got is why instead not use that freed up key assignment for short skips, like the study mode in iriver I think they said. So I did that and found it was great to have the last sentence repeated more easily, and to move more predictably than by seeking.

> However,  and I'm not alone with it. I'd like to use it with several minutes, say 5. That would mean: Virtually every song can be skipped normally, so no change of behavior. But you're still able to skip around in long songs, mixes or audio books. This would be just prefect.

This isn't something I've ever needed. Of course it's similar in implementation but quite different in its objective.

>> Perhaps you've guessed that the reason I did it that way, is that once you overshoot and go to the next track, you can't come back to the end of the previous track. I wouldn't really mind it going to the next track, but what I'd want is for someone to fix the rewinding so that I can come back to the end of the previous track.
>>
>> To sighted users, overshooting is just an annoyance: you can go to the previous track and seek forward.
>
> I don't think it's a real problem. We are not to protect the user of accidents which he caused himself. BUT, particularly sighted user can always use a longer skip length and fine-tune using ffw/rewind. These are not the people we need to take care of.
> And, as Paul Louden said, we do not help people against accidental skips in normal playback either.
>
> Lastly, I think the wish for being able to skip overweights the wish for protection of accidental skips. That's at least the impression I got over time.

As I explained above, preventing accidental skips is what got me started in this.

Obviously one doesn't need protection from it during normal playback, I don't see what this changes. The fact that seeking slows down nearing the end of a track suggests to be that we're trying to protect the user, due to our atypical clunky rewind behavior.

I'm not saying that the function you want doesn't make sense, it does. It's just you can't say that it's perfect for my needs too. I'm not particularly interested in debating whether your point of view "overweights" mine, since to me it seems we are both right for different objectives, and I'm not going to go start a popularity contest over this.

Thinking about it, for long skips, it doesn't make sense to prevent them entirely like I do when nearing the end of the track. What would make more sense, for my usage pattern, is when a skip is about to overshoot, then skip to the end of the track MINUS 5 SECS and beep. Now of course this isn't at all what you're after :-) .

>> But there is no way for a blind person to seek to the end of a track. Unless you can recognize your position from the audio and go in baby steps and are very lucky, you'll seek to the end and it'll jump tracks when you release the button. (A clumsy workaround might be for seek to disengage 3 secs before the end of a track, but that too would be wrong and that would be changing pre-existing behavior.)
> Blind users knows their tracks better than sighted users, additionally, they

Oh come on. Rubbish. Am I supposed to recognize any random sentence of a book I've either read once or not even once yet? And then evaluate exactly the remaining time in the track?

> are always more careful with skipping. Even without skip length, you can easily predict how much you sought, especially if you know your tracks so good. And again, this protection is not in normal playback either. And unless

I don't understand how you can be "careful". And I don't see what normal playback has to do with this. And actually I've often wanted to skip back from the beginning of one track to the end of the previous one.

>> Note that seeking too is blocked on the end of a track (at least in the old build I'm running). So the idea did not seem too strange.
> I don't understand how seeking is locked. It gets slower towards the end of the track, and stops at the very end, without going to the next track.

That's what I mean. Now do it with your eyes closed. Tell me: I'll be glad if I'm missing something, but how do I notice I've reached the end and stop it from just going on to the next track when I lift my finger off the forward button?

> If you mean that, then yes. But this is the nature of seeking, it's meant to be local to a track, skipping isn't.

I don't agree that seeking is intrinsically local to a track. Seems like a Rockbox peculiarity to me, because our rewind doesn't skip back.

But allthat doesn't make much difference. I do agree that what you're asking for makes sense. As I said above, I started this whole thing because of accidental track skips, and seeking is still problematic for blind users. Now if your argument is that I'm in a minority, well I think that sucks but I'm not going to start a debate over it. Just don't try to say I didn't have a need for this.

This is all a balance of compromises... compromise for players not having enough controls, for people wanting a zillion different functions, compromises over difficulty of implementation: it's a bit harder to skip back to the end of the previous track and it might not have been the most important thing to work on, and audible feedback during rewind would be very useful but the pcm stuff is hard to work with and there's this problem of putting out audio while paused... So yes, the behavior I've implemented is a bit of a workaround.

>> A secondary concern is that it may be desorienting to automatically skip tracks, as the user would not be aware of it, and it could be a problem if they're looking for something specific. Adding a beep on track skip would take care of that. (I wonder if that could be done reliably: if the user is repeatedly skipping, he might interrupt the beep... and beeping is a bit flaky...)
>
> Really, do you really expect that people don't know what they are listening too? And if they really don't know, they are bound to look at the display anyway. No point in giving a protection here.

How do you tell one chapter from another, unless you already know the text by heart? How often do you stop and have it speak out the track name?

>> I will admit it is not very often that I need to go to the end of a track, but it does happen from time to time. Tracks often break on the beginning of a chapter, and sometimes you want to refer to the last pages of the previous one. Or find the end of an episode. Once I had a broken book with tracks wrongly ordered and they were not cut at chapter boundaries...
> But I admit that I,  VERY OFTEN, want to skip tracks with skip length enabled.

Not much of an admission :-)

> "it happens me from time to time" doesn't really justify the behavior. Especially since, even if it happens you, doesn't automatically mean you accidentally skip to the next song.

I'm not sure what you meant there, but anyway I understand what you mean and see how it is useful and makes sense to you. Just pleas don't try to tell me I don't need this, since this is the reason I wrote it in the first place.

This is a bit frustrating for me as this feature has been stripped down in functionality once in the past by someone who had never used it and never meant to use it and who was just out do to some kind of cleaning up. Well, at least you wrote to me :-) .

>> Reading the forum post: it hadn't occurred to me to make a single track playlist for those cases where I want to find the end of a track. Kind of sucks but I suppose it's not too bad. Oh wait though: wouldn't I just overshoot and fall off the end of the track and playback would stop, and I still couldn't find the end...
>>
>> Hmm... does this give you any new ideas?
>>
>
> Is this all just about finding the end, which happens you from time to time? You can easily do it without the protection too. And if you have a higher skip length set, you're less likely for accidental skips too.

So given a chapter 15mins long. How do you seek to listen to the last couple sentences, with your eyes closed? Am I missing something, or were my explanations not clear?

> The fact is: The demand for skipping tracks is there. Protection against accidental skips is not worth it, and also not something Rockbox should provide imo. Use seeking if you want the end, or not skip the song.

So I agree that the feature you want makes sense. But you're also saying that my need doesn't exist, that what I implemented is worhtless and that Rockbox intrinsically ought not to provide it, and you want my absolution to trash it for the greater good :-) . I think I might not be the only human being with this particular problem: there are other blind users, drivers, people working with books or podcasts, doing transcriptions... I do understand that the current implementation is a blocker for you. In my mind, skipping 5secs and skippin 10mins are really two completely different functions that just happen to coincide in implementation. I wish you had more constructive solution to my issues than saying my needs are not worth it and I'm a minority. Now as I said, I've withdrawn a bit from Rockbox development and I'm not going to go start a public popularity contest over this. If you commit the change I'll just patch my own version, and tell any of the blind users who might complain to go take it up on IRC themselves.

One possible compromise would be this: a skip length shorter than say 1min means you mean to do some kind of fine work, and then skip protection applies. A larger skip length means you are dealing with either music or possibly very long single track works, and then we let it skip tracks. But then please have it beep on skip, controlled with the same option as the beep on the standard track skipping function. I'd be happy with that, I might even use it your way.

--
Stéphane Doyon
<s.doyon@videotron.ca>
http://pages.videotron.com/sdoyon/

Maybe you can understand his reasoning too.

I, for myself, think we should separate the tracklock feature out into a separate setting.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: AlexP on March 03, 2009, 03:06:57 PM
I understand what he is saying, but I still think that it should skip.  What I would think ideal is to make this setting skip as it would (obviously IMO) make it much more useful, and have in addition a skip lock setting.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: Llorean on March 03, 2009, 03:10:42 PM
I definitely agree that they should be separate settings.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: kugel. on March 03, 2009, 11:58:42 PM
Ok, this sounds very fine to me. I'd like to implement this, I'm just thinking about whether the tracklock thing should be apply to "Skip whole track" too.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: Llorean on March 04, 2009, 12:10:23 AM
Tracklock should prevent skipping or seeking out of the track. It shouldn't be dependent upon any other setting. The way I see it when the end of the track is reached playback should essentially pause until the user manually stops or rewinds back into the track.
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: lee321987 on March 15, 2009, 10:01:57 AM
Just a heads-up -- play_hop() has been moved to gwps.c
Title: Re: Skip to next song when time left is less than "Skip Length" setting
Post by: lee321987 on April 03, 2009, 12:27:37 PM
  One more heads-up --  This functionality is now built-in (Playback Settings --> Prevent Track Skipping)
  There is no need to modify the source code  (I found out because I still had audio_next() in gwps.c, and my player was skipping two songs).

  Have a good day.