Rockbox

Tasklist

FS#6377 - multi-mode reverse and forward

Attached to Project: Rockbox
Opened by Mark Terran (mterran) - Wednesday, 22 November 2006, 22:24 GMT
Last edited by Marc Guay (Marc_Guay) - Friday, 12 December 2008, 15:15 GMT
Task Type Feature Requests
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I appreciate the variable rewind acceleration feature for the Archos player. My request instead concerns the behavior of the controls themselves.

As far as I know, no portable mp3 player provides discrete skip and search buttons, i.e. <| |> AND << >> for a total of four buttons. Instead, there are only two directional controls; the user presses the reverse button momentarily in order to jump back to the beginning of the track; in order to search backwards the user must hold the reverse button long enough to override the track-skip function and enter into search mode. Having achieved this, the user then releases the button once the backwards review has reached the desired point.

The problem is, if the desired retrograde is very brief, as in 1, 2, 3 or 4 seconds - important for some who are trying to learn brief but dense musical phrases, for example - the terrible danger exists of the user unintentially returning altogether to the beginning of the track.

Now, in some early portable Sony CD Discman players, there were only the two directional buttons. However, there also was a third, button-mode button which would transform the forward and reverse buttons into true search buttons (i.e. pressing it momentarily would not cause the player to skip tracks).

Would something like this be possible? Or, could the on and off buttons on the Archos player be rendered cue and review buttons on demand?

Is there any player where this could be feasible using Rockbox?

I would be eternally grateful for this feature!
This task depends upon

Closed by  Björn Stenberg (zagor)
Friday, 12 December 2008, 15:15 GMT
Reason for closing:  Invalid
Additional comments about closing:  Closing all feature requests.
Comment by Paul Louden (darkkone) - Wednesday, 22 November 2006, 22:27 GMT
Have you played with the FF/RW much? It actually starts off quite slow and accelerates in an attempt to accomodate those who need to move very short distances.
Comment by Mark Terran (mterran) - Wednesday, 22 November 2006, 22:38 GMT
Thanks for mentioning this. I appreciate that it does start slow, but it would be great to be able to overcome the lag time from when you press the button to when the player starts reversing, to be able to have that kind of positive and instantaneous control without the danger of unintentionally skipping back to the beginning. would use of the on and off buttons as "soft" buttons to act as cue and reverse buttons on the Archos player possibly be feasible? (and toggling the power on and off some other way, such as pressing and holding play) Thanks again.
Comment by Dominik Riebeling (bluebrother) - Wednesday, 22 November 2006, 22:57 GMT
when learning music phrases (which you said this would be important to) why not use the A-B repeat?
Comment by Mark Terran (mterran) - Wednesday, 22 November 2006, 23:48 GMT
Thanks for mentioning this. The A-B is valuable to me and I am thankful the Archos has it, but getting to the spot where I want the A-B to begin often involves the frustrations of the skip/review button. That's why having not only the A-B function but also a directional button-mode control as on the early Sony Discman (if not 3rd and 4th buttons) would be a dream come true for the sheer immediacy it would provide. Of course, as a beggar (untrained in writing code), I realize I cannot be a chooser :) but thought I'd throw this out anyway in the hope it might be feasible. Thanks again!
Comment by Paul Louden (darkkone) - Wednesday, 22 November 2006, 23:51 GMT
I think a better function than coopting a button to do this would be to simply make the FF/RW buttons slighty more configurable (allowing the user to pick if, upon tapping they immediately FF/RW, skip X seconds/minutes, or Next/Prev track). So you can easily toggle what they do by loading a .cfg or changing it in the menu, rather than complicating the controls further.
Comment by Stephane Doyon (sdoyon) - Thursday, 23 November 2006, 02:45 GMT
Would you have a look at P#6188? My goal was different but perhaps the
solution might be the same. I wanted to avoid unintentionally skipping to
the next track or the beginning of the track when I'm reading audio
books, which tend to have long tracks. Plus a quick skip backward is
something handy to have the last sentence repeated (much quicker than
rewinding). P#6188 has key mappings for x5 only, but I could certainly
flesh it out if there's interest and someone to test it.
Comment by Mark Terran (mterran) - Thursday, 23 November 2006, 04:31 GMT
First, my hat goes off to you developers. I marvel and I also am thankful.

Referring to the previous two posts: I see Paul Louden’s point about not messing with other buttons and instead just making the two directional buttons configurable; this essentially is what the early Sony Discman did, i.e. it allowed one to configure the two RW/FF buttons to either 1. function as true search controls (instantaneously responsive and directly controllable search/cue/review with no skipping, hesitation nor delay), or 2. skip to Next/Prev track. But now, I love this idea of a THIRD mode, that would allow INCREMENTAL skipping by a predetermined number of seconds/minutes as Stephane Doyon also discusses, above and at P#1688.

My dream would be to have these three button modes for the two directional buttons, and also to be able to specify, in the incremental skip mode, the size of the increment in seconds/minutes - yes, all the way down to zero seconds, for those who may want only one or two seconds and also for those who simply want to safety-lock the track.

If the above were not feasible for the Archos player, I would love to see, if nothing else, an alternative whereby these RW/FF buttons are able to function as true search buttons BY DEFAULT (i.e. immediate response and without skipping) but then also remain functionality as track-skip buttons simply with a double-click of the button in rapid succession. Not only would this provide the player with true search controls, it also would help prevent the accidental track-skips that are caused by either not holding the button long enough, or, as Stephane mentioned, accidentally bumping the button or joystick while on the go (since most bumps won’t be a perfect double-bump).

Thanks again.
Comment by Mark Terran (mterran) - Thursday, 23 November 2006, 04:54 GMT
Come to think of it, here is yet another possibility, in case the triple-mode function explained above (that I really wish for) is not feasible. It is something I believe I saw on an early Citizen Discman-type CD player: in Play mode, the RW/FF buttons (or joystick) function as true search controls, by default (i.e., instant response, and no track-skip). In PAUSE mode, however, the RW/FF buttons then function as skip Prev/Next track controls. This route too would be just wonderful as far as I'm concerned; plus, unwitting track-skips caused by accidental bumps wouldn't be possible either unless a previous accidental bump first placed the player in Pause mode.
Comment by Linus Nielsen Feltzing (linusnielsen) - Thursday, 23 November 2006, 08:08 GMT
I would say that the current behaviour is the by far most common one, and most people expect a player to behave that way. Changing the default to a search-only mode would confuse a lot of users.
Comment by Mark Terran (mterran) - Thursday, 23 November 2006, 11:15 GMT
I see your point and I agree. My use of the term "default" in my last post was a bad choice; what I meant to say was that it would be great, as one of a few possibilities, to have the RW/FF buttons work in the manner I described - that is, primarily as true search buttons (in play mode) and secondarily as track-skip buttons (in Pause mode), instead of the standard functionality - and to have these work this way merely as a user-selectable alternative, for those who use their players for unusually intensive listening (as in the case of music-transcribing, or learning a language) not to mention users who simply are annoyed each time the long track they're listening to reverts to the beginning of the track with each accidental bump (as I understand it, the main buttons on the Archos player are hardware-controlled and therefore cannot be made to be "holdable;" thus the value of user-configurable RW/FF buttons becomes even greater with these non-holdable units).

Admittedly such concentrated and intensive use of the review control is not typical of the average mp3 player user. Still the mp3 player remains a potentially powerful tool for the serious music or language student, particularly if it has this added playback flexibility and control. For this reason and others it sure would be great if the RW/FF buttons (or joystick) were user-configurable, in the menu. But no, I agree, such added functionality should be an alternative modality to the common standard rather than a firmware default; thus my use of the word was poor.
Comment by Dan (Skyly) - Thursday, 23 November 2006, 17:21 GMT
The iriver firmware for the H300s has a study mode option, which is similar to something you mentioned, incrementing upon a button tap, making it impossible to track skip unless completely stopped. This mode still demands a delay before track seeking, otherwise it wouldn't be able to tell the difference between seek and increment. It only has a minimum of 1 second, which I think could be too much at times. There are further stupidities with iriver's way of implementing this, such as disabling the track names while playing is stopped, despite this being the only way to track skip in study mode, as well as disabling seeking of any kind while paused, completely wasting the two buttons.

I like your most recent idea; having an option to replace typical operation with your suggestion: instant-seek, and skip only when paused or stopped. I think that is a better idea than having a mode that completely disables skip, because seeking is of less (but not zero) use while the track is paused, and this would still allow skip functionality without having to switch modes again. With Rockbox's nifty crossfade while skipping functionality, this would even still allow track skipping without juddering stops and starts. Certainly we do not want the current default behaviour to change with regards to these buttons.

I would recommend avoiding double-tap solutions, simply because it would break crossfading into the next track unless the player allowed some small delay to test for a double tap, and having such a delay would defeat the purpose entirely, so the only choice would be to have messed up (or no) crossfading when skipping.

So I would like to have the option to switch between the current standard ("default"), and the instant-seek + skip only while paused/stopped ("instant-seek"), plus a duplicate of iriver's Study Mode to optionally replace the "tap FF/RW" command with the increment function. It would be better to implement this as a third mode, instead of trying to apply it as an option to the other two modes, as applying tap-to-increment to instant-seek mode would render it the same as if you applied tap-to-increment to the default mode anyway.

To summarise...

Default mode
Playing:
Hold FF/RW = Delay, then seek
Tap FF/RR = Track skip
Paused:
As above.

Instant-seek mode
Playing:
Press FF/RW = Seek instantly (does not distinguish between tap and hold)
Paused:
Hold FF/RW = Delay, then seek
Tap FF/RW = Track skip

Study mode
Playing:
Hold FF/RW = Delay, then seek
Tap FF/RR = Increment
Paused:
As above.




You could ask for a mode that does incrementing, delayed seeking, AND track skipping as well, by replacing paused or stopped increment with track skip. I do think it is bloating things too much to add a 4th mode just for this, and that forcing this upon study mode would be a bad idea, as the user would be in danger of losing their spot while the track is paused. I would happily see track-skip-while-STOPPED in study mode, but Rockbox does not implement "stop" properly for this. So as it stands, I think the 3 modes I laid out is a good design of what Mark is aiming for.
Comment by Mark Terran (mterran) - Thursday, 23 November 2006, 18:44 GMT
I think Dan's 3-mode layout, as set forth above, would be FANTASTIC. All perfectly logical and elegant too. No extreme appropriations of other function buttons or other downsides. Just a great user option that would overcome the grievous deficiencies of the industry status quo with regard to these controls and dramatically increase the utility and enjoyment of the player as far as I'm concerned. The three forward and backward button-modes, the increment user-adjustable from 0 seconds to x, and mode-continue on resume (at least), would be perfect - and a great complement to the variable-acceleration search on the Archos player!
Comment by Stephane Doyon (sdoyon) - Thursday, 23 November 2006, 18:50 GMT
Fwiew now that is getting just a tad confusing :-).

Just to make sure I understand: we've been using the terms
"search/cue/review" and "seek" interchangeably right?

Now is there a difference between instant seek, vs an increment of 1sec?
With P#1688 and the increment set to 1sec: bump the button and move by
1sec, hold and it goes into ff/rew == seek. Isn't that equivalent to
the "true search" mode described above? Do we really need three modes?
Clearly you guys see these things as different, so I must be missing
something.

Re double click to skip tracks: to me this is incompatible with the
incremental mode == tracklock == P#1688, because I will often do a
double, triple or sometimes quadruple backward increment. One can triple
click the joystick to the left in under a second. Assuming an increment
of say 7secs, I can go back 7, 14 or 21secs in a very snappy manner.

Having to change mode to skip tracks as in P#1688 is admittedly a bit
clunky, and there's the problem of remembering in what mode you're in,
and whether that mode should be reset whenever reentering the
WPS. Perhaps the key sequence usually used for directory skipping could
become track skip in tracklock mode: that's click then hold. There's some
small potential for accidentally skipping, but it's probably acceptable,
I'll have to try it and see.

The idea of using PAUSE as a different mode allowing skips is
intriguing. It seems to me however that this isn't convenient enough to
avoid switching back to the standard mode when you are in fact browsing
tracks and not reading or studying music. Pausing would be more
convenient than switching modes for a skip of one track, but for multiple
skips it'd quickly become annoying, so you still need a convenient way to
switch modes.
Comment by Dan (Skyly) - Thursday, 23 November 2006, 20:03 GMT
I use search, cue, review and seek interchangeably, yes.

I have to apologise for the unclarity of my first post, it was a bit shocking. I blame this small text field heh.

I see what you mean about instant seeking while having incrementing on, good point. It could immediately start seeking the instant the button is pushed down while still catering for an instant increments at the same time. If the button is lifted quickly enough to register as a tap, Rockbox simply ignores what little seeking it has done, and increments from the exact moment point the button was pressed. Since Rockbox plays silence while seeking, and since it is much less than a second for a 'tap' to become a legitimate 'hold', there would be no noticeable effect felt in any way. Not only that, this also applies to instant-seeking vs track-skip. This should be applied already! New summary at the bottom to describe this better.

I agree with your further reason to avoid double-click controls.

I think using pause to skip is the best solution available for those wanting instant seeking. It wouldn't be a problem for flipping through when you're looking at the screen, but for ears-only browsing it would be a hassle indeed. I really wish Rockbox did not use the stop button the way it did, having it available would allow for a nice solution : press pause then skip to play the next track; press stop then skip as many times as you want to continue skipping freely. This thread isn't the place for it, but that's my particular whim.

The only solution otherwise is the hold-and-press. Currently there simply isn't room for it, at least on the H300s anyway, and I'm sure they have more buttons than the iPod and Archos players. Play is used on loop mode, Stop is off, Navi is context, A-B is menu, and Record, while free, seems too hotly argued to blow on this feature. However, I think the current implementation of loop mode is dodgy, so I'll still entertain the idea heh. Problem is, a press and hold requires two hands, so you're practically looking at the screen already. Meanwhile, remote controls aren't feasible for this either, so these two problems together have defeated the goal of ears-only browsing. It is plain cumbersome on the H300s as well; their button layout is a joke for multi-key controls with the FF/RW buttons. Since this situation of holding it with two hands means silent browsing is feasible anyway, the idea of pause-for-multiple-track-skip as much as necessary while staying paused is just as functional. In the end the multi-key method provides next to no advantage (by not aiding ears-only browsing), while supplying alot of awkward operation. I would prefer pause-skip-unpause over hold-something-press-skip. I could still do that on the remote. Of course, if loop mode was not taking up the play button, I would have nothing against see both methods being implemented.

As it stands, I would just expect the user to accept one mode or the other. If they want instant seeking, they are going to be aware that they're sacrificing instant skipping. I think that's something that is easily accepted because replacing that button tap is part of the deal.


From your first questions, I still would prefer the three modes. If you tried to study mode with either other mode, you're asking what function to give a FF/RW tap when paused. Study mode users don't want track skip - I value being able to increment and seek while paused, as much as I value the track position being safe. Instant-seek mode users don't want to lose track skip, and while hold-key + press-button is theoretically workable, I would really hate that to be the only way to skip in instant-seek mode. You can't share study mode with track skip, and you can't share default mode with instant-seek mode.
So I think having 3 modes is still preferable and not bloat.




Revised summary...

Default mode
Playing OR paused:
Tap FF/RR = Track skip
Hold FF/RW = Seek instantly. However, release fast enough to register as a tap, and track skip instead. Completely unnoticeable, and saves delay.

Instant-seek mode
Playing:
Press FF/RW = Seek instantly (does not distinguish between tap and hold, allowing for tiny, instant searches).
Paused:
Tap FF/RW = Track skip
Hold FF/RW = Seek instantly. However, release fast enough to register as a tap, and track skip instead. Also unnoticeable.

Study mode
Playing OR paused:
Tap FF/RR = Increment
Hold FF/RW = Seek instantly. However, release fast enough to register as a tap, and increment instead. Again unnoticeable.



The sublime functionality in my opinion would be to have that Stop button, and the stopped state, returned. Study mode users could have access to skip, yet still have increment when paused. Instant-seek users could have access to ears only browsing. Even default users could just have good old stop-and-drop position functionality. But alas.
Comment by Dan (Skyly) - Thursday, 23 November 2006, 20:08 GMT
Edit button sorely missed. Apologies again for cluttered sentences, and a typo when it was not helping.
Comment by Mark Terran (mterran) - Thursday, 23 November 2006, 20:14 GMT
In response to Stephane's message of 07:50PM, personally I do think of search/cue/review, rewind, backspace, scan, and seek interchangeably, but also as having usually an audible (at least before acceleration) and visual (as indicated on the player's minutes and seconds digital display) components, and yet tractable enough to be able to time-shift only very short distances, even as close as only a second.

AFAIC, the central benefit of having the three modes for these directional buttons is the "instant" aspect of Instant-Seek - the utter elimination of the time lag upon activating seek (search). The difference between the increment mode and the instant-seek mode is that the duration or distance of the search in seconds/minutes in the instant-seek mode would be immediately and directly controlled by how long the user's finger is on the button, whereas in the increment mode, the overall distance of the jump backwards or forwards is pre-determined by the user in the button-mode menu and activated by momentary tap. If the setting is one second then there may not be much difference in use, yet the qualities of pre-determination of the distance of the jump in the increment mode, and determination and control of the distance of the shift in real time by the finger in the instant-seek mode, would be preserved. In other words, one significant difference between a true search mode and holding the button in increment mode as you described relative to P#1688 - even with the increment set to only one second - is the time lag that still would be present from the time you put your finger on the button to when the machine actually starts searching. Even though it is not a terribly long time, it still causes continual and repeated interruption to the progress of a user who is trying to use the player to concentrate on brief passages as in the case of transcribing music or learning new foreign words or phrases.

Regarding the double-click to skip tracks and its incompatibility with the increment mode, good point and another good reason why my earlier suggestion of a double-click to skip tracks should be scratched. After all, Increment-Skip, like Instant-seek, ought to function instantaneously with the touch of the button without the least hesitation or delay, and this certainly would conflict with activation of another function by double-click.

Regarding Stephane's final paragraph, I see your point about being able to conveniently skip tracks in rapid succession, in the case of actually browsing tracks. All I can say is hopefully it wouldn't be too much trouble to switch modes, particularly if one values the search and skip functions equally - which is why the manufacturers just should have given us the four buttons in the first place! I never could understand the minimalist approach to control of multiple functions. I so much prefer the Boeing 747 cockpit approach, or the classic English approach of directly controllable toggle switches on the dashboard - plenty of em! - for the various functions of the automobile, instead of the one-button-does-all approach. :)
Comment by Mark Terran (mterran) - Monday, 27 November 2006, 22:54 GMT
In an earlier comment on this page (Mark Terran (mterran) - Thursday, 23 November 2006, 05:31AM) - and in reference to an earlier, related project, I accidentally switched two characters and typed "P#1688," when I meant to type P#6188. This error is perpetuated in others' subsequent comments. My apologies to all and especially to sdoyon, who opened P#6188.
Comment by Stephane Doyon (sdoyon) - Tuesday, 28 November 2006, 02:29 GMT
So it's not just the issue of accidentally skipping tracks: you
actually feel that rewind (and ffwd) takes too long to engage. I was
a bit puzzled so I had a look at the code. Can an RB developper say
whether there's any reason the first rewind button action doesn't
move, you actually have to wait for a repeat?

This isn't perfectly clear to me because I'm blind and (so long as we
can't talk or beep while paused) I get absolutely zero feedback
during rewind/ffwd.

AFAICT from a quick read of the code, things happen like this:
-LEFT or RIGHT button press: do nothing, just wait and see whether
it'll be held.
-If a release comes within 0.3s then it's a "tap", so skip tracks.
-If the button is held 0.3s, then it's a long press. Pause audio and
go into rew/ffwd mode.
-In that mode we don't actually do much: we wait for key repeat
events and update the position offset each time.
-On release of the key, we reset and start playback from the
resulting time offset.

Now on entering the rew/fwding context (ffwd_rew()) we initialize
stuff but we don't actually move, we wait for the first button repeat
event.
AFAICT the first repeat event happens after a delay of 0.16s. So
that's a total of 0.46s of deliberate waiting before we've actually
moved by the minimum step, plus whatever time it takes to pickup
playback from the new location. Also consider that playback has
advanced 0.3s beyond the point where we decided to start rewinding.
Those are fairly short times, but perhaps for very intensive use it
might be annoying.
I don't see any reason for not making the first step right away on
entering ffwd_rew(). It might help a little bit for very short
rewinds. (The way it's done currently, releasing the key between 0.3s
and 0.46s probably produces only a stutter, and playback continues
from the same point.) I made a small patch that does this, but I
don't know if there's any point posting it here...

AFAICT repeat events happen progressively faster (the interval is
reduced by 0.01s each time) until the interval is only 0.05s.

If one wants to rewind by 5s, it takes
0.3 +0.16 +0.15 +0.14 +0.13 +0.12 = 1.0s of holding the rewind key.
But then you've actually gone back 4.7s, not really 5s.

Rewinding 15s requires holding the key for 1.71s.

At that point, it's updating 20times per second, and depending on
your settings, the acceleration will eventually kick in.

The irregular initial repeat intervals trick is probably nice for
scrolling down lists, but is it desirable in this case? Do I
understand that something more linear would be preferable? Or is this
quasi-exponential progression appropriate?

In any case, in order to implement a "true search" mode, and get rid
of the initial 0.3s delay that serves to recognize a repeat key, then
ffwd_rew() should be made to move according to current_tick and to
disregard key repeats and wait only for ACTION_WPS_STOPSEEK (key
release).

Mark Terran wrote:
> I see your point about being able to conveniently skip tracks in
rapid > succession, in the case of actually browsing tracks. All I
can say is > hopefully it wouldn't be too much trouble to switch
modes,
That seems to be the awkward point for me. For P#6188 I appropriated
the X5's OFF button as a mode toggle, but free buttons are scarce in
the while-playing-screen. I also introduced an option under the
playback menu, but that's really several clicks away... OK 18 button
presses to toggle...
Comment by Dan (Skyly) - Tuesday, 28 November 2006, 05:23 GMT
Eighteen button presses... ouch.

0.46 seconds.. it would be great if that could be abolished. So I think it should enter ff/rw instantly. Drop the 0.3 wait for a button hold, drop the 0.16 wait for the next step, just start seeking the moment the button makes contact. Its theoretically possible for instant seek in all situations, without losing the actual button-tap function that is being used at the time (be it seek or increment or whatever), so that's my response to Stephane.

So is this thread now about modes AND button timings?

My summary remains the same. The 3 modes, and button timings recreated to begin seeking instantly in all modes anyway.

I don't know what to suggest for less-buttoned players when it comes to switching modes. At 18 buttons to switch modes, Study mode with only 2 songs even sounds like a real hassle.


Comment by Mark Terran (mterran) - Tuesday, 28 November 2006, 05:59 GMT
With an Archos player in play mode, tapping the Play button toggles between play and pause. What about, in addition to this, pressing and holding the Play button in order to move directly to the new (rw/fwd) button-mode submenu, then select between the three modes which Dan has outlined by means of the directional buttons, and then press Play again to simultaneously select the desired mode and return to normal WPS (or, perhaps, the Play button twice at this point, once to select and visually verify the desired mode-change, and then again to simultaneously confirm and return to WPS)?

It wouldn't hurt the tap-to-toggle-between-play/pause function. Plus, the play and the two directional buttons are three buttons all players have. I don't know about other brands and models, but again in the case of the Archos player, the Play button, with the machine in play mode and using Rockbox, currently is only good for tap to toggle between play/pause function. IMHO this additional mode-submenu screen function would add a good and reasonably logical - and harmless - function to the play button and best of all, make it a lot easier to switch between the three rw/ffwd button-modes on the fly. Possibly nutty idea - I may be missing something - but thought I'd throw it out anyway.
Comment by Mark Terran (mterran) - Tuesday, 28 November 2006, 06:26 GMT
(quoting from 28 November 2006, 06:59AM) "...and then press Play again to simultaneously select the desired mode and return to normal WPS (or, perhaps, the Play button twice at this point, once to select and visually verify the desired mode-change, and then again to simultaneously confirm and return to WPS)?"

Or, at the button-mode submenu screen, pressing Play again to simultaneously select the desired mode and return to normal WPS and also sound superimposed single, double or triple confirmation beeps, to indicate mode 1, mode 2 or mode 3 resp. (and perhaps a little superimposed beep in the first place, indicating successful transition from WPS to button-mode submenu selection-mode/screen. Not really even essential for blind use given the small number of button-presses using this scheme [28 November 2006, 06:59AM], but...
Comment by Dan (Skyly) - Tuesday, 28 November 2006, 15:20 GMT
I wouldn't suggest holding play as a way of entering a mode select screen, because like the as-yet-unused record button, I believe holding play has alot in the works already. I think "display playlist" is the most likely command to land on the play button. Even if not... is this valuable enough to warrant its own button, because they are expensive real estate, even on the well endowed players (heh).

A second and probably futile argument against it is that this would force the play button to require delay simply to pause. Needing to wait up to 0.3 seconds after pressing the button before pausing. Maybe its just me, but I don't like laggy controls at any point. And unlike the whole "instant seeking in any mode" suggestion, you couldn't get away with instant pausing then unpausing. As it stands, I haven't checked but I'm pretty sure pausing in the WPS already uses that check-for-tap hold anyway. The remote control definitely does, as hold-play on the remote accesses the pitch shift screen. Besides, I'd rather have something like instant playlist access there. I reckon we could think of a solution even for instant pausing though heh.. at some other time.



At the moment, the "A-B" button, or MODE button to some, accesses some menus. Tap it to enter the Main Menu, or hold it to enter the rather non-specific and non-versatile "Change repeat and shuffle modes and what you can view in the file browser" menu.

For one, I think removing the actual "A point B point" functionality from the A-B button on my H340 is plain dumb, but that's another story. But for two, I'm quite sure that in the "repeat mode/shuffle mode/file views" screen, the up button is unused. Down, left and right all cycles through stuff. Up could fit quite well here for cycling through the different seek modes. Assuming we keep what is currently in place, I think that's the perfect solution. (Just I'm not a big fan of what's currently in place heh).



Comment by Mark Terran (mterran) - Tuesday, 28 November 2006, 23:51 GMT
Personally I would accept a little reduction in convenience in track-skipping, even if it means having to press 18 buttons, if it meant having the OPTION of turning my rw/ffwd buttons into instantaneously-responsive, true search controls (no, Dan is not alone in not liking laggy controls, especially, AFAIC, when it comes to hundreds of brief rewinds in the course of intensive listening, studying, learning or transcribing sessions). I probably would find myself exploring other ways to quickly sample consecutive tracks. Dan mentioned the possibility of pressing and holding play (while playing) in order to get into the current playlist. Well, from there, couldn't I then press left or right in order to select the next or prev. track and then select it, and thereby sample the adjacent track. Could one then return from the playlist screen to WPS by either 1. press and hold, again, of the play button, or 2. an automatic return to WPS after a number of seconds. The delay before such an automatic return would allow one, while yet in this playlist screen, to very quickly and easily move yet again to an adjacent track (or further, depending on how many times the the left or right button is tapped) followed by a tap of the play button in order to select and play the new track. ASAIC, this would make rapid track-skipping (browsing tracks) easy and convenient enough!

My hope is that the choice of the three modes could be remembered by the machine while idle; the user could then decide which is the more desirable default among the three modes and just accept switching in the menu. Personally my choice would be setting the buttons to search; if I could access the playlist with a hold of the play button (while playing) as Dan has described and then easily navigate and select tracks from there, I would be more than thrilled.
Comment by Stephane Doyon (sdoyon) - Wednesday, 06 December 2006, 00:57 GMT
Quick question:

Mark Terran wrote:

> With an Archos player in play mode, tapping the Play button toggles
> between play and pause. What about, in addition to this, pressing and
> holding the Play button in order to move directly to the new (rw/fwd)
> button-mode submenu, [...]

I'm confused... looking at the key mappings, I thought a LONG PLAY would
bring you to the context menu, no?

In any case, we could of course put the ffwd/rew mode submenu under the
context menu, that'd cut down on the number of presses needed to go
change the mode... I'd make it just an ordinary menu, no beep scheme...

If I should try my hand at this, do you guys have dev environments setup,
are you able to try out patches?
Comment by Dan (Skyly) - Wednesday, 06 December 2006, 15:49 GMT
I can test patches. I'm currently using the mod player patch, and some other one you would think I'd remember, but I don't. I only use Cygwin and Windows XP though.

Perhaps the Archos doesn't have something to replicate an iriver's NAVI button, because that's what my H340 uses to access the context menu; NAVI. Hold-play does nothing on the main unit, but enters the pitch shift screen on the remote... I don't know why.

The context menu is a fine place to put the seek-mode-select option. However, two things to consider are:
1) Everything on the context menu exists somewhere else, so to follow the standard this would need a place somewhere else too. I would suggest under General Settings -> Playback. Put a line saying "Seek Mode" next to "Party Mode". Imo.
2) I liked my idea of using the Volume+ button to cycle through seek modes in the "shuffle/repeat/fileview" screen. Your thoughts on that? Its the screen you arrive at by holding A-B on an iriver in the WPS.


I assume you wouldn't be trying to implement the instant-seek-in-all-modes stuff I was talking about earlier (where it seeks instantly no matter what mode you're in, but undoes the seek and just skips if a button tap is detected instead). Its off topic, and probably needs more discussion anyway.


Comment by Stephane Doyon (sdoyon) - Wednesday, 06 December 2006, 18:33 GMT
Dan (Skyly) wrote:

> 1) Everything on the context menu exists somewhere else, so to follow
> the standard this would need a place somewhere else too. I would
> suggest under General Settings -> Playback. Put a line saying "Seek
> Mode" next to "Party Mode". Imo.

Yes, that's where I put the setting for my tracklock patch, only next to
"Fast-Forward/Rewind" seemed to make more sense.

> 2) I liked my idea of using the Volume+ button to cycle through seek
> modes in the "shuffle/repeat/fileview" screen. Your thoughts on that?
> Its the screen you arrive at by holding A-B on an iriver in the WPS.

UP is not free in that screen AFAICT. Both
UP and DOWN are used to cycle through the "Show Files" options. Adding a
fourth option into the quickscreen would be another project... Perhaps
exchanging one of those options for the rewind mode might be an avenue to
consider, I never use the repeat function myself, but then that'd be yet
another thing to configure as some doubtless feel the repeat option
matters to them.

> I assume you wouldn't be trying to implement the
> instant-seek-in-all-modes stuff I was talking about earlier (where it
> seeks instantly no matter what mode you're in, but undoes the seek and
> just skips if a button tap is detected instead).

Sorry but frankly that doesn't make much sense to me. Firstly, seeking
isn't really work, it's just waiting to see how long you'll hold the
button down and when you release it THEN jump to the appropriate
place. It's not like there's something useful we can do while we wait. If
we are in a mode where a tap is to be recognizable, I think the existing
0.3s delay is fine. With your proposal, AFAICT, a tiny seek just could
not be requested anyway, since you must hold the button long enough for
it not to be counted as a tap.

And if I had the UI react immediately, such as pausing music as soon as
LEFT/RIGHT is pressed, then if the command ends up being a skip then
it'll probably sound like a stutter, which isn't very nice considering
all the trouble we go through with crossfading and everything...
Comment by Mark Terran (mterran) - Thursday, 07 December 2006, 00:46 GMT
Stephane Doyon wrote:

> Quick question:

> Mark Terran wrote:

>> With an Archos player in play mode, tapping the Play button toggles
>> between play and pause. What about, in addition to this, pressing and
>> holding the Play button in order to move directly to the new (rw/fwd)
>> button-mode submenu, [...]

> I'm confused... looking at the key mappings, I thought a LONG PLAY would
> bring you to the context menu, no?

I was looking at the large box at section 4.3.1 of the Archos Player manual. In play mode I don't see a long play, only a tap of play to toggle between play and pause.
Comment by Dan (Skyly) - Friday, 08 December 2006, 03:39 GMT
Responding to Stephane,

1) Okay.
2) Sorry, I didn't realise UP was unused in the shuffle/repeat/file view screen. I still support the idea, for that very reason really. RIGHT cycles through repeat modes while LEFT cycles through shuffle modes, so I just assumed DOWN (and only DOWN) cycled through file views. Removing the current UP functionality (cycling the other way through file views) is a small loss that I personally wouldn't notice anyway, while replacing it with a new set of options (the seek mode select) is a definite plus.

It could be argued that if the UP button was to be used for something new on that screen, there might be a more deserving feature to stick there. So I agree that it is another project; it would need its own consideration. Fair enough.



No time right now so I'll have to consider the instant seeking stuff later. However, everything we have discussed about the seek modes and their implementation sounds great to go ahead with if you (or anyone else reading) is feeling up to it.
Comment by Dan (Skyly) - Friday, 08 December 2006, 03:40 GMT
EDIT

...
2) Sorry, I didn't realise UP *WASN'T* unused....

Comment by Stephane Doyon (sdoyon) - Thursday, 14 December 2006, 05:36 GMT
Mark Terran wrote:

> I was looking at the large box at section 4.3.1 of the Archos Player manual.
> In play mode I don't see a long play, only a tap of play to toggle between
> play and pause.

I guess it's missing. The very next section presents the WPS context
menu... Couldn't you just have tried it?

Well, no one commented on linear vs pseudo-exponential initial
progression... and seems we have only two interested persons and only one
of those ready to try patches...

Still after discussing this to death, it would be a pity not to show some
code, so here's a first stab. I guess this makes this a patch rather than
a feature request... It's still rough, but that's all the time I have for
now.

I've added one quirk: in study mode, doing a left tap followed closely by
a LONG RIGHT wil skip to the next track, and the reverse to go
backward. Inspired from the next/prev directory functionality. The
"counter-gesture" is a bit convoluted but at least it's a way to skip
tracks without having to go change the seek mode.
Comment by Dan (Skyly) - Thursday, 14 December 2006, 10:16 GMT
Dammit, Firefox just nuked my post.

Basically, sorry I didn't consider that delay-between-ticks suggestion you made.
I do think the diminishing delay is not the best thing for those whom I will dub 'miniseekers', because a standard delay between ticks will be absorbed subconsciously, that is, it will be easier for them to increase their skill at miniseeking.

I'd happily see it set to 0.05s from the moment it begins. Long seeks still have acceleration features to help with that, while miniseekers will have instant seeking that is as tight as it gets.



Downloading the patch now, will get back to you.
Comment by Dan (Skyly) - Friday, 15 December 2006, 09:28 GMT
To start off with, big thanks for doing this! I quite like prolonged discussions, especially when something eventuates, so your efforts have made this quite enjoyable for me. I don't think I have a way to return the favour, except by hopefully being of some benefit with testing.

I went looking for the option in the Main Menu, so the first thing I noticed was that it wasn't there heh. Check the Context Menu, there we go.
Half an hour later I went to check my FF/RW settings and tripped over the Seek mode option. Woops. Hmm. Appropriate grouping but the current Playback menu listing doesn't fit so well imho. "Fast-forward/Rewind" is so specific that it makes me think of the actual FF/RW settings, as if the seek mode is too big an option for that heading. The grouping is good though, and you have saved a line on the Playback menu (perfect for the font I use), so I like how you have done it, but would happily see the current listing of "Fast-forward/Rewind" edited to say something else. I would suggest "Seeking" or simply "Seek".

1) Listing in the Playback menu could have a new title. The layout is good though.

Accessing the "Fast-forward/Rewind" option, a few things pop out. Firstly, "Study hop step" is written in sentence case, while "FF/RW Min Step" is written with each word capitalised. Needs a standard. Secondly "hop step" sounds a bit strange... howabout "Study increment" or "Study mode increment"? Thirdly, I think the FF/RW step and accel settings should be the last 2 options, not the middle two. I don't know, feels neater. What I do know, is that I'm being anal, sorry.

2) Listing need to be all sentence case or all capitalised.
3) "Hop step" reminds me of chalk and pebbles and alleyways.
4) FF/RW options shifted to the last 2 positions?

I think you chose the best placing for it in the Context Menu. Up top it would have interfered with Playlist access; any lower and it would have gotten between the user and their UQ settings. Where it is, its out of the way of the most accessed features but still only 3 taps away.

Accessing the Seek Mode options, the first one, "Traditional skip and seek" stood out to me as quite descriptive, while Study mode only has the one word, "Study". I know I'm picking at the details here. I don't mind it staying how it is, I'm just saying that it doesn't have a consistent feel I look for in a menu. I do realise that I just discussed the "feel" of 3 lines of text. I would suggest either

Seek and skip
Instant seek
Study

or

Traditional
Instant
Study

5) While I don't mind it staying how it is, I am happy to discuss the listing titles.

Moving on to the implementation. One thing I'm noticing alot is the "What mode am I in?" You have to actually go back to the mode select to find out. Not your fault or problem, just pointing it out. If this is happily finalised, it would be nice to work on getting it featured in the WPS tags or something.

6) WPS info could be a later consideration.

Okay. Traditional mode is as expected. A little playing around finds no bugs that weren't already there. I didn't go too hard on this though, just switching between pause and play and double tapping and the like. I already had a few bugs and crashes due to Rockbox's usual instability, so I tired of this pretty quickly.

Instant mode appears to be working fine. I see that Rockbox's delay in resuming playback comes into play here, kind of annoying but oh well. I would be interested in the minimum step being less than 1 second for playing with this mode, but don't know if the resuming delay would make it pointless. Track skipping when paused works nicely, as does directory skipping, while non-paused playback gives nothing but pure instant seeking. Yay. I forgot that I still need to consider my instant-seek-always-then-possibly-revert-to-a-tap suggestion. It could at least be applied when paused, but I do want to think about that later.

7) Do you know much about why Rockbox delays so much before resuming after a seek? I imagine this can't be improved.... but I also wonder why Rockbox works this way when the original firmware resumes pretty much dead-on (albeit with less control over seeking speed).
8) Instant-seek-always at least when paused could be possible. But feel free to ignore.

Study mode works nicely when playing. A double tap even will respond exactly as expected. You can go nuts with the RW and FF buttons and it stays on top of things. I like that you haven't put the extra track skipping feature in while it is playing.
When paused, I'm noticing that the odd extra second is leaking through. For example, if I am paused on 1:00, with 20 second increments set for Study mode, tapping FF six times will land on 3:02 instead of 3:00.
The tap left hold right feature for track skipping is nice. I'm glad you chose that over tap-right-hold-right. One thing I would suggest to aid track skipping in Study mode even more.. allow continued holding to continue track skipping. Give it a delay of 0.3 - 0.4 seconds or so; something that's slow enough for the user to respond to but fast enough to make the next ten-ish tracks most easily accessible this way. Anything further and they can always use the playlist.

9) Study mode is leaking a little.
10) Track skipping in study mode is great the way you've done it. Repeated skipping could be added.

That's it for now. Thanks again for implementing it. Sorry to be so anal, but I have this thing with things I like being as good as possible. I wouldn't like this to be commited with the menu options still looking (imo) less than perfect.

Comment by Mark Terran (mterran) - Friday, 15 December 2006, 14:12 GMT
On Thursday, 14 December 2006, 06:36AM, Stephane Doyon (sdoyon) wrote:

> Mark Terran wrote:

>> I was looking at the large box at section 4.3.1 of the Archos Player manual.
>> In play mode I don't see a long play, only a tap of play to toggle between
>> play and pause.

> I guess it's missing. The very next section presents the WPS context
> menu... Couldn't you just have tried it?

Well, I couldn't; recently, my player went missing (pretty stupid eh?). I have embarked on a campaign to replace it swiftly if possible. Meanwhile I was reduced to consulting the Archos Player manual at section 4.3.1 instead of observing the menus hands-on. Plus, I had just gotten the unit, and so didn't yet know better aside from the manual. I only knew was that with Rockbox there was a small ray of hope that one day I might yet have a portable digital player with true, flexible, instantly responsive (so that they could keep up with intensive, concentrated study) mini-seek controls. Of course I am extremely frustrated right now not having the Archos player at hand and not being able to try this patch (and submit any comments regarding its use with this particular player, for what they may be worth), at a time when it looks like my dream of having these controls in a portable player just may be coming true! So at this point, what more can I say but THANKS for doing this and I am extremely eagre to try it and use it and enjoy it.
Comment by Dan (Skyly) - Wednesday, 20 December 2006, 16:08 GMT
One more question. Did you remove the extra 0.16s delay from traditional mode, so that it begins seeking at 0.3s instead of 0.46s?
Comment by Stephane Doyon (sdoyon) - Thursday, 21 December 2006, 20:49 GMT
Dan (Skyly) wrote:

> Basically, sorry I didn't consider that delay-between-ticks suggestion
> youm ade. I do think the diminishing delay is not the best thing for
> those whom I will dub 'miniseekers', because a standard delay between
> ticks will be absorbed subconsciously, that is, it will be easier for
> them to increase their skill at miniseeking.

That was my guess, and so I went for a constant delay.

> I'd happily see it set to 0.05s from the moment it begins.

Well it's not just the step, it's the frequency too. The original
behavior using button repetitions quickly comes up to 20 steps per
second. My patch makes it arbitrarily half that: 10 steps per second,
because I felt that it was too fast at the beginning, and I doubt anyone
can control the duration they press a button to much finer than 0.1s. I
might have thrown off some of the rewind step/speed tuning in doing that,
like that max step of 3% of the remaining time...

Anyway an initial step of 0.5s might allow for a slower start, which
might be useful. But I think it's a question of speed, not "resolution".

> To start off with, big thanks for doing this! I quite like prolonged
> discussions, especially when something eventuates, so your efforts have
> made this quite enjoyable for me.

Good to hear.

> Appropriate grouping but the current Playback menu listing doesn't fit
> so well imho. "Fast-forward/Rewind" is so specific that it makes me
> think of the actual FF/RW settings, as if the seek mode is too big an
> option for that heading. The grouping is good though, and you have
> saved a line on the Playback menu (perfect for the font I use), so I
> like how you have done it, but would happily see the current listing of
> "Fast-forward/Rewind" edited to say something else. I would suggest
> "Seeking" or simply "Seek".

I think "Fast-forward/Rewind" should be pretty clear/obvious for most
people, while "Seeking" would not be.

I suppose the problem was mostly my not having explained where things
were. If this gets committed then we would document it in the manual, and
so most people would probably retain a vague notion of what it is.

> pop out. Firstly, "Study hop step" is written in sentence case, while
> "FF/RW Min Step" is written with each word capitalised. Needs a
> standard.

Ah good point. That's the type of thing I tend to miss, since I see it
written only in the language file, and later only hear it
spoken :-). Here's a new patch with that fixed.

> Secondly "hop step" sounds a bit strange... howabout "Study increment"
> or "Study mode increment"?

OK whatever :-).

> Thirdly, I think the FF/RW step and accel settings should
> be the last 2 options, not the middle two. I don't know, feels
> neater. What I do know, is that I'm being anal, sorry.

My reasoning was that they apply to all seek modes, while study
increment applies only in one specific mode... but you can argue
differently I guess.

> I think you chose the best placing for it in the
> Context Menu. Up top it would have interfered with Playlist access; any
> lower and it would have gotten between the user and their UQ
> settings. Where it is, its out of the way of the most accessed features
> but still only 3 taps away.

Exactly how I had reasoned it. Glad you agree.

> Accessing the Seek Mode options, the first
> one, "Traditional skip and seek" stood out to me as quite descriptive,
> while Study mode only has the one word, "Study". I know I'm picking at
> the details here.
...
> I would suggest either
> Seek and skip
> Instant seek
> Study
> or
> Traditional
> Instant
> Study

Bah... I don't particularly mind. Here I've renamed "Study" to "Study
Mode" just so it looks more balanced. You have to have read an
explanation to know what it does anyway.

> Moving on to the implementation. One thing I'm
> noticing alot is the "What mode am I in?" You have to actually go back
> to the mode select to find out. Not your fault or problem, just
> pointing it out. If this is happily finalised, it would be nice to work
> on getting it featured in the WPS tags or something.

Oh yes, I forgot to mention that. I had mentioned it in P#6188. Dunno if
it should be in the WPS or status bar or whatever. Never having seen them
and not having read the code, I don't have much of an opinion and will
leave that to someone who knows better.

> Instant mode appears to be working fine.

To me that was the biggest new thing about this whole patch.

> I see that Rockbox's delay in resuming playback comes into play here,
> kind of annoying but oh well. I would be interested in the minimum step
> being less than 1 second for playing with this mode, but don't know if
> the resuming delay would make it pointless.

Not sure exactly what you mean here. I don't think the rewind minimum
step has any importance here. Do you really mean to rewind by less than
1s? As I said above, the step rate is a more important factor I
think.

The question of how long it takes to restart playback is interesting, and
critical to make this thing useful. Having played with it a little bit, I
find that a low bitrate ogg file gives me a pretty instantaneous restart,
but a high bitrate mp3 has a delay of maybe a third to half a second,
which isn't very nice.

> Track skipping when paused
> works nicely, as does directory skipping, while non-paused playback
> gives nothing but pure instant seeking. Yay.

Good.

> 7) Do you know much about why Rockbox delays so much before resuming
> after a seek?

I haven't read enough of the code, but I would guess the codec takes too
big a chunk of audio to decode and we're waiting for it. If it took a
smaller initial bite, we might have better response, perhaps. Only
guessing. And I'm not to familiar with how the buffering is done...

> I imagine this can't be improved....

Oh probably it can, but not so easily.

> Study mode works nicely when playing. A double tap even will respond
> exactly as expected. You can go nuts with the RW and FF buttons and it
> stays on top of things.

I use that all the time.

I have encountered an issue however with it refusing to hop backwards
sometimes. I think it happens when resuming a bookmark. Needs more
investigation but I'm inclined to think the bug might be outside this
patch. I believe I glimpsed a bug report about wrong elapsed time in
resuming long tracks... might be related.

> I like that you haven't put the extra track
> skipping feature in while it is playing. When paused, I'm noticing
> that the odd extra second is leaking through. For example, if I am
> paused on 1:00, with 20 second increments set for Study mode, tapping
> FF six times will land on 3:02 instead of 3:00.

Hmm funny. Well it tells the codec to seek to that point, the codec does
it's best. It's sure to be slightly off because it must round to the
nearest frame, but I would have expected a much smaller error. Of course
some codecs might rely on seeking information that would be less precise,
FLAC I think...? Not entirely sure how they all handle VBR... will
definitely have to go read that code :-). But I probably can't do much
about this. What type of files were you playing?

> The tap left hold right feature for track skipping is nice. I'm glad
> you chose that over tap-right-hold-right. One thing I would suggest to
> aid track skipping in Study mode even more.. allow continued holding to
> continue track skipping. Give it a delay of 0.3 - 0.4 seconds or so;
> something that's slow enough for the user to respond to but fast enough
> to make the next ten-ish tracks most easily accessible this
> way.

Hmm interesting idea. I don't think I'd use it much myself, as you have
to know what's coming up. The skip directory and this key sequence are
already done with a hack in the code, I'm hesitant to add too much
to it :-).

> Anything further and they can always use the playlist.

or file browser.

> Thanks again for implementing it. Sorry to be so anal, but I have this
> thing with things I like being as good as possible. I wouldn't like
> this to be commited with the menu options still looking (imo) less than
> perfect.

You're worried about this being committed too soon? <cough> That's rather
optimistic I think. It's the other way around. You'll need to go lobby
for this on IRC if you hope to see it committed.

Mark Terran (mterran) wrote:

> Of course I am extremely frustrated right now not having the Archos
> player at hand and not being able to try this patch (and submit any
> comments regarding its use with this particular player, for what they
> may be worth), at a time when it looks like my dream of having these
> controls in a portable player just may be coming true! So at this
> point, what more can I say but THANKS for doing this and I am extremely
> eagre to try it and use it and enjoy it.

Well, good luck getting yourself a player, and hope you enjoy it. It's
not perfectly responsive, but hopefully it's improved.

Dan (Skyly) wrote:

> One more question. Did you remove the extra 0.16s delay from
> traditional > mode, so that it begins seeking at 0.3s instead of 0.46s?

Yes I did. This also applies to study mode, and instant seek mode when
paused. I had hoped you would have noticed the difference. Guess it's not
that big a thing then :-).

Well I hope you enjoy this. To me it doesn't bring much beyond what I
had in P#6188 aside from tydying up a few loose ends... As I said, if
you mean to have this committed, you'll need to convince RB developers on
IRC.
Comment by Dan (Skyly) - Friday, 22 December 2006, 01:30 GMT
Will reply to the rest later, but yes, I did notice the delay change from 0.46 to 0.3. That's why I came back for the second reply, just to be sure. Definitely a good thing too.

Loading...