PDA

View Full Version : Fast-forward/rewind redesign



awy
2007-12-21, 02:32
(This is a repost of a message from the Developer forum as this topic probably deserves a wider audience.)

I am looking at changing, I hope improving, the design and implementation of the fast-forward (FFW) and rewind (REW) functionality in SqueezeCentre. There is considerable dissatisfaction with the current implementation, although I suspect that it probably meets the needs of some people just fine.

Let me start by recapping on the current functionality, as I understand it:


FFW mode can be entered by press-and-hold of the ">>" button on the remote. It will remain in FFW mode once the ">>" button is released. SC will start playing at 2X normal speed, where it will play 1s of audio, skip 1s, play 1s, .... A further press-and-hold of the ">>" button will increase this to 4X speed where only 1s out of every 4s is played. One can repeat this to 8X, 16X, ..., although at some point the server will probably run out of power to supply data at this rate.
REW mode can be entered by press-and-hold of the "<<" button on the remote and is otherwise the same as FFW mode.
If the now-playing screen was not displaying then it is bought up, switching to progress-bar mode if necessary.
The FFW/REW mode is exited by pressing the Pause or Play buttons.
If FFW/REW runs past the end or beginning of the track, then it continues with the next/previous track in the playlist.


This interface is much like that of VCR/DVD players and less like that of CD and portable-music players. Some find this unintuitive and have remapped the buttons so that FFW/REW is exited immediately upon releasing the relevant button, presumably only ever getting to 2X speed.

There is considerable doubt about whether being able to hear the 1s chunks of audio in these modes is actually of any use.

The implementation only works for sources through which one can seek. In practice, this is limited to local files which are not transcoded and which are in WAV, MP3 or FLAC format.

The implementation (called trick-mode internally) is pretty inefficient and somewhat hit-and-miss. Recent improvements have made it somewhat more reliable and so that it mostly works with synchronized players but did not address the core problems with the design. The implementation also has the problem that it affects many different parts of the SC software. It would be great to get rid of it.

Proposal:

Change the user-interface.
Remove the audio feedback.


User interface

Press-and-hold ">>" to enter FFW and release it to resume play. Similarly for REW.
Change the display to something like the input bar (currently used for volume and tone control) and advance a cursor along the bar proportional to the position in the track. On the right-hand end of the bar should be the total-length of the track and at the left-hand end should be the time of the current cursor position.
I anticipate some sort of acceleration if the button is held down. Perhaps start at about 3X and jump to 10X after 5s.
Resume playing from the position indicated by the cursor when the button is released.
Stop at either end of the track, and start playing at normal speed either from the beginning of the next track (FFW) or the current track (REW) when the button is released.


Much of this is based upon a plugin by kdf of these forums.

I would be pleased to get feedback on these proposals and additional or alternative suggestions.

Alan.

peter
2007-12-21, 03:01
awy wrote:
> I am looking at changing, I hope improving, the design and
> implementation of the fast-forward (FFW) and rewind (REW)
> functionality in SqueezeCentre. There is considerable dissatisfaction
> with the current implementation, although I suspect that it probably
> meets the needs of some people just fine.
>

I think this would be a great improvement. I hardly ever use the
FFWD/REW buttons at the moment because I find them very confusing. I'd
love to see the functionality you propose instead. Or why not make the
ffwd behavior configurable per player so we can all have our wish? It
seems your system should be easier to program than the current.

Regards,
Peter

cbemoore
2007-12-21, 04:41
Before going any further, I'd recommend reading Sean Adams' explanation of the current FFWD/REW design. He makes some very interesting points!

http://forums.slimdevices.com/showthread.php?t=36446

peter
2007-12-21, 04:49
cbemoore wrote:
> Before going any further, I'd recommend reading Sean Adams' explanation
> of the current FFWD/REW design. He makes some very interesting points!
>
> http://forums.slimdevices.com/showthread.php?t=36446
>

I read it but there doesn't seem to be anything that contradicts this
solution. Alan suggests a 'silent' ffwd/rew, basically like you would
lift the pickup from an old-fashioned record and place it somewhere
else. No sound while moving, just a visual indicator should surely make
this a lot easier.

Regards,
Peter

seanadams
2007-12-21, 09:03
Before going any further, I'd recommend reading Sean Adams' explanation of the current FFWD/REW design. He makes some very interesting points!

http://forums.slimdevices.com/showthread.php?t=36446

Most may not be aware that Alan was the person recently responsible for a major redesign of the multi-SB synchronization machinery for SC7, so he knows this corner of the code base now probably better than anyone... certainly better than me. :)

I agree that using a proportional bar would be much better than what we have now.

slimkid
2007-12-21, 09:29
Check out what song scanner plugin does. It delivers nice solution to the problem (IMNSHO).

K

Deano
2007-12-21, 09:54
Another Vote for Alan's suggestions! I too find the current solution unpredictable and therefore do not use it.

And if the multi-SB synch in SC7 that Alan worked on is anything to go by it will be brilliantly implemented.

In fact, I'd just like to say thank you to everyone for all your hard work. I'm running a nightly from 2 weeks ago on Vista. And it's working perfectly, very stable and I'm loving all the improvements.

Thanks again. D.

htrd
2007-12-21, 11:32
awy wrote:

> I would be pleased to get feedback on these proposals and additional or
> alternative suggestions.

It all looks good.

Is there any possibility this could be made to work for transcoded files
too? If only to avoid the inconsistency in behaviour.

I guess the implementation would involve spooling the output of the
transcoding process on disk just in case someone wanted to rewind in future
and, during a fast forward, spinning that process as fast as it can run
until it catches up with the new play position.

seanadams
2007-12-21, 12:43
awy wrote:

> I would be pleased to get feedback on these proposals and additional or
> alternative suggestions.

It all looks good.

Is there any possibility this could be made to work for transcoded files
too? If only to avoid the inconsistency in behaviour.

I guess the implementation would involve spooling the output of the
transcoding process on disk just in case someone wanted to rewind in future
and, during a fast forward, spinning that process as fast as it can run
until it catches up with the new play position.

For most (all?) formats we should be able to just seek proportionally to the designated point in the _source_ file, and just re-start transcoding from there.

The main reason transcoding does not work with the current ffw/rw architecture is because of complexities created by trying to play snippets of audio while scanning.

Wirrunna
2007-12-21, 13:51
For most (all?) formats we should be able to just seek proportionally to the designated point in the _source_ file, and just re-start transcoding from there.

The main reason transcoding does not work with the current ffw/rw architecture is because of complexities created by trying to play snippets of audio while scanning.

Include transcoded files and it will immediately get my vote and I suspect the vote of everyone who has their library in Apple lossless.

muvee69
2007-12-21, 16:05
+1


And I was told to lengthen my reply.
I totally agree to this. Love my SB.
The box, proning on top of my televison, interferes with my TV antenna signal. So... I listen more to music, and watch less television. :)

Philip Meyer
2007-12-22, 13:37
>I read it but there doesn't seem to be anything that contradicts this
>solution. Alan suggests a 'silent' ffwd/rew, basically like you would
>lift the pickup from an old-fashioned record and place it somewhere
>else. No sound while moving, just a visual indicator should surely make
>this a lot easier.
>
I don't understand why taking something away like that can make the functionality "easier". If no audio indicator makes it easier for you, then why not just mute the sound before fast forwarding?

Phil

Philip Meyer
2007-12-22, 13:53
>I agree that using a proportional bar would be much better than what we have now.
I disagree.

The way it works at the moment is better, because the user is in total control, deciding when to accelerate. An automatic acceleration in fast-forward speed is unpredictable (esp. without audio feedback). I guess it's the difference between a manual gearbox (transmission) and an automatic in a car.

My most frequent use for fast-forwarding is when I am listening to podcasts that I have downloaded and scanned into my music library. For example, Coverville. An episode of this podcast generally lasts 30mins to an hour. When I hear a bad song, I want to skip forward to the next. With no audio feedback, I would not know when to stop fast-forwarding. I'd have to look at the current playtime, fast-forward a bit, stop, listen and then fast-forward or rewind a bit. With an automatic acceleration in the FF/REW speed, this would be even worse. The functionality would be totally useless.

I think some form of audio feedback is essential, and in my opinion expected by those who are not techically aware - those that are moving from CD playback.

I also use KDF's Scanner plugin, so I have the best of both worlds. This is useful for long tracks, when I do know where I want to jump to, as it is quicker than fast-forwarding. However, I think this is the less-likely scenario. I can't think of many times when I have specifically needed to jump to a known position in a song, whereas I quite often want to skip over a passage in a track until the music changes (eg. a gap between the last song and a "hidden" track on a rip from CD).

I have no objection to making this new method an option, but I personally think the way it works now is better. Give the user the option to decide what method suits them best, or leave the functionality as it is (because it works), and fix other issues that are more high profile.

Phil

Philip Meyer
2007-12-22, 13:55
>In fact, I'd just like to say thank you to everyone for all your hard
>work. I'm running a nightly from 2 weeks ago on Vista. And it's working
>perfectly, very stable and I'm loving all the improvements.
>
Here here. I think SC7 is very good - very stable. I can recommend upgrading.

However, please don't break the FF functionality ;-)

peter
2007-12-22, 14:37
On Sat, 22 Dec 2007 20:37:55 +0000, "Phil Meyer"
<slim (AT) hergest (DOT) demon.co.uk> said:
> >I read it but there doesn't seem to be anything that contradicts this
> >solution. Alan suggests a 'silent' ffwd/rew, basically like you would
> >lift the pickup from an old-fashioned record and place it somewhere
> >else. No sound while moving, just a visual indicator should surely make
> >this a lot easier.
> >
> I don't understand why taking something away like that can make the
> functionality "easier". If no audio indicator makes it easier for you,
> then why not just mute the sound before fast forwarding?

I read Sean's explanation (in the quoted thread) on why it's difficult
to do ff's perfectly. It seemed leaving out audio would make it easier
*for the developers* to do a ff in the way I'd like to see it. Reading
this thread I'm not the only one. I find the current method confusing
and - for me - useless. I'd have no objection against a configurable
ff-scheme, but I imagine that goes against the first rule of coding:
Keep it simple.

Regards,
Peter

Philip Meyer
2007-12-22, 14:46
>For most (all?) formats we should be able to just seek proportionally
>to the designated point in the _source_ file, and just re-start
>transcoding from there.
>
Perhaps play audio feedback when playing non-transcoded, and don't play audio when playing transcoded files.

Display a progress bar when fast-forwarding or rewinding, but allow manual speed acceleration, as it is today.

I suggest a configuration setting:

FF/REW acceleration:
Manual
2 sec
5 sec
10 sec

where the acceleration time is the period of time that the button is held down before going up the next gear-change.

Manual would work like current functionality, where the speed increases after a FF button hold, but will not increase again until the user presses and holds FF again. Seeking will continue at the current multiplier rate until play is pressed to resume normal playback.

2, 5 or 10 sec acceleration would increase seek speed after the chosen period of time has elapsed whilst holding FF down. If the button is released, seeking is stopped and the track will resume normal playback.


Another problem to consider with the new FF proposal that the infra red control may not be dependable. If there's any interruption in signal, FF speed will be lost and the user would have to build-up to speed again.

Phil

Philip Meyer
2007-12-22, 15:08
>I read Sean's explanation (in the quoted thread) on why it's difficult
>to do ff's perfectly. It seemed leaving out audio would make it easier
>*for the developers*
>
I can't see how rewriting the implementation would be easier than doing nothing ;)

>I find the current method confusing and - for me - useless.
>
I can't understand why anyone would find the current implementation confusing. It is after all how many DVD players work. Seems quite logical to me, and there are audio and visual feedbacks as to what is happening too.

I've never needed to look up documentation to understand how it would work. Perhaps you could explain why it is confusing such that some documentation could be added to the Help->Remote Control Reference page?

Actually, I have another improvement suggestion that could be made to the current implementation to fit in with the suggested implementation.

At the moment, you press and hold FF to move into x2 playback/seek speed. Holding the button down any longer has no effect. Perhaps holding the button down longer could continue to increase the seek speed, x4, x8 etc, eg. just implement a FF.repeat action.

>I'd have no objection against a configurable ff-scheme, but I imagine that goes against the first rule of coding:
>Keep it simple.
>
There is no first rule of coding.

Phil

slimkid
2007-12-22, 18:00
There is no first rule of coding.
Phil

If there was the first rule of coding, then, I'd imagine it would be - the code has to do something useful and purposeful, preferably what the paying side asked for.

Good that this thread was started (kudos to the idea that the client is ultimate target of the product and keep it simple - ask them - what is that they really want). Shows that various people have different view on the subject. I too find the current solution rather useless, partially because of the fact that it's not consistent - SB does not react to the remote same way all the time; an then, pressing the play is hit and miss. Since I have discovered song scanner, I don't think I ever used the original way to FF. However, I can see a merit to Phil's view and for sure there are people using it the old way. So, I guess, there will have to be room made for both solutions, either as a configurable option or at the same time. I think that just integrating the song scanner, so that it is easier to access would be big step in the right direction. Because, the only drawback to it is the fact that it takes too many key strokes to get.

K

peterw
2007-12-22, 20:02
My most frequent use for fast-forwarding is when I am listening to podcasts that I have downloaded and scanned into my music library. For example, Coverville. An episode of this podcast generally lasts 30mins to an hour. When I hear a bad song, I want to skip forward to the next. With no audio feedback, I would not know when to stop fast-forwarding. I'd have to look at the current playtime, fast-forward a bit, stop, listen and then fast-forward or rewind a bit. With an automatic acceleration in the FF/REW speed, this would be even worse. The functionality would be totally useless.

I think some form of audio feedback is essential, and in my opinion expected by those who are not techically aware - those that are moving from CD playback.

How would you feel about DVR-like behavior? Press Fwd once and you jump ~30 seconds ahead (rough computation based on file size if not natively supported format?), pres Rew once and you jump ~10 seconds back. The UI should let users choose different Fwd and Rew jump amounts.

Perhaps even better -- momentary presses would have that DVR-like behavior, and held presses would have Alan's proposed behavior.


I also use KDF's Scanner plugin, so
I have the best of both worlds. This is useful for long tracks, when I do know where I want to jump to, as it is quicker than fast-forwarding. However, I think this is the less-likely scenario. I can't think of many times when I have specifically needed to jump to a known position in a song

I use my Squeezeboxes and a RadioShark AM/FM capture device to "time shift" radio programs. Often I have to stop playing a program mid-way. I use SongScanner to resume playback in these cases (I'd like to have something like MythTV's "saved position" functionality.)

-Peter

Mnyb
2007-12-22, 23:11
I have never undestood the ff function untill today :-)
It works even worse in an wifi setupp.

"Let me start by recapping on the current functionality, as I understand it:

* FFW mode can be entered by press-and-hold of the ">>" button on the remote. It will remain in FFW mode once the ">>" button is released. SC will start playing at 2X normal speed, where it will play 1s of audio, skip 1s, play 1s, .... A further press-and-hold of the ">>" button will increase this to 4X speed where only 1s out of every 4s is played. One can repeat this to 8X, 16X, ..., although at some point the server will probably run out of power to supply data at this rate."

I'm probably to fast ;-) i press >> nothing happens or it goes silent then a little later a sound snippet ? by then i've pressed play again. Confused as ever. Now i get it, I'm not patient enough to let the function kick in.

I will vote for a silent mode with a progress bar, and add alittle display for track time.

Philip Meyer
2007-12-23, 03:23
>If there were the first rule of coding, then, I'd imagine it would be -
>the code has to do something useful and purposeful, preferably what the
>paying side asked for.
>
That's not a rule of coding - that's the role of requirements capture and design :-)

>Good that this thread was started (kudos to the idea that the client is
>ultimate target of the product and keep it simple - ask them - what is
>that they really want).
Yes, I agree that it is good to ask in the forum how the community want functionality to work. However, that is not going to capture a large proportion of the user base, and only forum readers who have a problem with the current functionality will respond. How many users are there that don't read the forum, and how many users actually like the current functionality? So far there have been 8-10 replies, some of which agree that new functionality (or the proposed removal of functionality) should be optional.

>I too find the current solution rather useless,
>partially because of the fact that it's not consistent - SB does not
>react to the remote same way all the time; an then, pressing the play
>is hit and miss.
>
I'm not sure what problem you have - but sounds like this is nothing to do with FF functionality. What is not consistent? SB reacts to the remote the same way all the time for me - what varies for you? Sounds like you have dead batteries, if pressing play is hit and miss.

>Since I have discovered song scanner, I don't think I ever used the original way to FF.
That is a good useful plugin, but I still find the standard FF functionality more useful, most of the time.

>I think that just integrating the song scanner, so that it is easier to access would be big step in
>the right direction. Because, the only drawback to it is the fact that
>it takes too many key strokes to get.
>
This is already possible by creating a custom key map file. You can call up the song scanner from any chosen button (overriding FF.hold if you desire). I have changed play.hold on the now playing screen to take me directly into the song scanner.

I think the Song Scanner could be made a standard plugin (released and supported with SqueezeCenter) to sit alongside the current functionality. My vote would be for play.hold to be used to invoke the seek progress bar. The SavePlaylist plugin currently uses play.hold to get into that plugin, but I think Song Scanner would be a better use for the button. How often do people want to save the playlist?

Phil

Philip Meyer
2007-12-23, 03:50
>How would you feel about DVR-like behavior? Press Fwd once and you jump
>~30 seconds ahead (rough computation based on file size if not natively
>supported format?), pres Rew once and you jump ~10 seconds back. The UI
>should let users choose different Fwd and Rew jump amounts.
>
That would be even worse.

>Perhaps even better -- momentary presses would have that DVR-like
>behavior, and held presses would have Alan's proposed behavior.
>
The problem is the FF key will skip to next track if pressed briefly. The key must be held down to invoke some form of fast-forward behaviour.

I don't like having to hold down the button for long periods of time. Uses the battery power up, and would be less secure than current functionality.

I press.hold to start fast-forward, and then release the button. I press.hold FF again to ramp-up the speed. When I hear a change in the music (eg. the end of a long gap, crowd-noise between live songs, I press play to resume normal playback. Nothing confusing or difficult about that, and totally practical.

I compare the current fast-forward functionality to my Sky+ box for digital TV control, which is considered by many to be the best and most user-friendly PVR on the market. With that box, you press >>. This takes you into x2 playback speed. Press it again and you go to x5, then x15 and x30. Press play to resume playback. Exactly the same, except the SqueezeBox remote doesn't have a dedicated button, so you have to press FF.hold each time to go up to the next multiplier level. I can't imagine how bad it would feel if someone took away visual feedback from the Sky+ box and just provided a progress bar or an arbitrary jump <n> seconds into the future.

>I use my Squeezeboxes and a RadioShark AM/FM capture device to "time
>shift" radio programs. Often I have to stop playing a program mid-way.
>I use SongScanner to resume playback in these cases (I'd like to have
>something like MythTV's "saved position" functionality.)
>
Yes, that is kind of when I use the SongScanner; if I have stopped a long song/podcast and know what position I want to resume from. However, there is also a bookmark plugin, that allows you to save the song and position as a bookmark, so you can instantly resume from that position.

Phil

Philip Meyer
2007-12-23, 04:00
>I'm probably to fast ;-)
>
Slow down and chill out then ;-)

>i press >> nothing happens or it goes silent
>then a little later a sound snippet ? by then i've pressed play again.
>Confused as ever. Now i get it, I'm not patient enough to let the
>function kick in.
>
There would be no difference with the new proposed functionality - you would still have to learn how to hold a button down for long enough. Longer in fact, because as soon as you release, it would stop fast-forwarding, so you better learn to have more patience :-)

Phil

ntom
2007-12-23, 05:01
Tend to agree with an earlier poster: need to be able to hear what you are skipping for this to be useful. Currently I find that the lack of responsiveness is the biggest cause of frustration but I like being able to skip forward or backwards in a track. I agree if this is a problem on transcoded data then drop the audio for this -but then I only use FLAC & occasionally MP3!

I would like to see current situation where each FFWD press speeds it up, but would be nice if FRWD stepped the speed back down so could control speed.....doesn't seem to do that now.

Philip Meyer
2007-12-23, 05:25
>There is considerable dissatisfaction with the current implementation, although I suspect that it probably
>meets the needs of some people just fine.
>
Can you recap what features of the current functionality users are dissatisfied with? Maybe there's just a lack of information on how it works and people need some extra words in the documentation.

Are users actually saying that they don't like the sound made when fast-forwarding, or is that just an internal thing because Logitech want to make the software easier to understand?

Do users understand that they have to hold the FF button down?
Do users understand that they can release and hold again to go faster?
Do users understand that they have to press play to resume normal playback?

I'm trying to understand where the dissatisfaction is.

>Let me start by recapping on the current functionality, as I understand
>it.
>From this statement it does sound like there's no written documentation. I can't find my original user manual. I've looked in the Help->Remote Control Reference, and all it says is "Press and hold FWD to scan forward through the current song."

Whilst that statement is not untrue, it doesn't really detail the whole functionality. Your recap of the functionality was really good - and at least one user replying to this thread now undertands how it is meant to work. I suggest that as part of the rework (if anything has to be done), you also consider writing some details into the help reference, and eventually it would be good if Logitech release a better user manual for new products.

>There is considerable doubt about whether being able to hear the 1s
>chunks of audio in these modes is actually of any use.
>
Really? Where does the doubt come from?

I find it very useful, and I would find it useless without. Most other playback devices have audio feedback - CD players and mp3 players. Take for example the industry standard for mp3 playback devices - the iPod. If you press and hold the >> button on an iPod, it will fast forward, playing chuncks of audio in exactly the same way as the SqueezeBox fast-forward implementation.

Comparing to VCR/DVD/PVR devices, they all show a visual feedback when fast forwarding through video. Video players often had two mechanisms too. Fast-forward when playing will give a visual feedback, so you know when to stop fast-forwarding through adverts, for example. When stopped, fast-forward would go faster, showing a time position, so you can set playback at a particular point in time.

The iPod also has two mechanisms for seeking through a song.
1. Press and hold >> to fast-forward with audio feedback.
2. Press the middle circular button to go to a song progress bar. The wheel is then used to set a specific position within the song. The music plays at normal speed whilst you are selecting a new playback position (whilst the user continues to move finger around the wheel). When the user stops moving for a second or so, playback will automatically resume at that position.

To me, this is also how the Squeezebox should work by default out of the box, as a large user base would be most familiar with this functionality.

Your suggestion is like (1) and (2) above merged together, but in my opinion the audio feedback is crucial for this type of seeking, otherwise it's pointless.

>The implementation (called trick-mode internally) is pretty inefficient
>and somewhat hit-and-miss. Recent improvements have made it somewhat
>more reliable
Seems to work flawlessly under SC7.0 beta for me, on both wireless players (SB2 and Transporter) that I have.

I used to have a FF problem on my SB3, but to be honest I had loads of problems in general with wifi and the player rebooting, etc. It needs to go back for repair.

The song scanner plugin in like (2) above, except that it by default it is awkward to navigate to, and return back to the now playing screen. This could be improved.

>The implementation also has the problem that it affects many different parts of the SC
>software. It would be great to get rid of it.
>
True, but that's probably true for lots of other important bits of functionality - you can't just remove something because it hasn't been implemented well, and not replace it with something else. Eg. many people have unreliable wifi problems, but that doesn't mean that wifi should be disabled on all players!


Can I suggest that you try to support both seeking methods, like an iPod does:

1. Press and hold FF to fast-forward through a song, similar to your suggestion, but with audio feedback.
2. Press and hold play to bring up a progress bar, where left/right buttons set the current playback position. Automatically resume playback when left/right are not pressed any more, or press play to resume.


I suggest that the above could be the new default settings, but I would also like to see some configuration options to tweak the functionality (not sure whether the settings would be SqueezeCenter or player specific though). Could be advanced settings that most users would not need to go near. They would be a bit like setting the scroll rate in player display settings - most users won't need to tinker with the defaults.

"Fast-Forward acceleration time":
Select "<n> seconds", for the time FF is held down before ramping the playback speed up to the next multiplier. eg. default to "5 seconds". I'd like to have "0 seconds" mean manual acceleration, which would work like current functionality (each ff.hold would manually change up a gear).

"Fast-Forward multipliers":
Select a list of multipliers that fast-forward can go through: eg. default to x2, x5, x10, x20.

Possibly some other option to decide what should be displayed when fast-forwarding in method (1): "No display", "Display progress bar" or "Display time/time remaining".

Phil

Philip Meyer
2007-12-23, 05:28
>I would like to see current situation where each FFWD press speeds it
>up, but would be nice if FRWD stepped the speed back down so could
>control speed.....doesn't seem to do that now.

The current functionality uses repeated press-and-hold FWD presses to speed up, use repeated REW presses to slow down or go backwards. Press play at any time to resume playback instantly.

Phil

peterw
2007-12-23, 10:18
>Perhaps even better -- momentary presses would have that DVR-like
>behavior, and held presses would have Alan's proposed behavior.
>
The problem is the FF key will skip to next track if pressed briefly. The key must be held down to invoke some form of fast-forward behaviour.

Anybody have a good rock I can hide under?

Yeah, about the only time my "even better" suggestion would make *any* sense would be if there was only one item in the playlist, which is the case when I listen to most radio programs (but most of the time I have normal music playlists, duh).

My "even better" might be another good plugin to write that would wrap the Fwd/Rew keys and only change the behavior for single item playlists -- "JumpSkip", maybe, to continue my camel case naming? :-)

-Peter

peter
2007-12-23, 12:49
On Sun, 23 Dec 2007 10:50:58 +0000, "Phil Meyer"
<slim (AT) hergest (DOT) demon.co.uk> said:

> I compare the current fast-forward functionality to my Sky+ box for
> digital TV control, which is considered by many to be the best and most
> user-friendly PVR on the market. With that box, you press >>. This
> takes you into x2 playback speed. Press it again and you go to x5, then
> x15 and x30. Press play to resume playback. Exactly the same, except
> the SqueezeBox remote doesn't have a dedicated button, so you have to
> press FF.hold each time to go up to the next multiplier level. I can't
> imagine how bad it would feel if someone took away visual feedback from
> the Sky+ box and just provided a progress bar or an arbitrary jump <n>
> seconds into the future.

Video is much different from audio in this respect. But I'd prefer a
timeline that I can move to any position of anyway. Like in Windows
mediaplayer or any other computer mediaplayer that I know of. None have
speed up play speed to move to a different location.

Regards,
Peter

peter
2007-12-23, 12:51
On Sun, 23 Dec 2007 11:00:41 +0000, "Phil Meyer"
<slim (AT) hergest (DOT) demon.co.uk> said:
> >I'm probably to fast ;-)
> >
> Slow down and chill out then ;-)
>
> >i press >> nothing happens or it goes silent
> >then a little later a sound snippet ? by then i've pressed play again.
> >Confused as ever. Now i get it, I'm not patient enough to let the
> >function kick in.
> >
> There would be no difference with the new proposed functionality - you
> would still have to learn how to hold a button down for long enough.
> Longer in fact, because as soon as you release, it would stop
> fast-forwarding, so you better learn to have more patience :-)

It's much like the way the volume up/down buttons work. Except now the
display bar indicates the location inside the current track.

Regards,
Peter

Philip Meyer
2007-12-23, 13:04
>It's much like the way the volume up/down buttons work. Except now the
>display bar indicates the location inside the current track.
>
Not really. Volume up/down is instant - as soon as you start to press the volume up key, it will start to raise the volume. However, you'll still have to hold the FWD button down to fast-forward, as a short press would skip to the next track.

cbemoore
2007-12-23, 16:07
The problem is the FF key will skip to next track if pressed briefly. The key must be held down to invoke some form of fast-forward behaviour.

Here's a controversial suggestion, but the more I think about it the more sense it seems to make. Why not reverse the current logic so that a brief press of FF or RW increases or decreases the speed, and a long press skips to the previous or next track?

This would be much more intuitive to me than the current behaviour. It would also make it much easier to seek within a track, since you would be able to control the 'seek' speed with brief presses instead of long presses.

Anyone agree, or is it a stupid idea?

Chris

Philip Meyer
2007-12-23, 17:17
>Why not reverse the current logic so that
>a brief press of FF or RW increases or decreases the speed, and a long
>press skips to the previous or next track?
>
It did cross my mind too for a split second, as I often navigate through the now playing list to choose a song to skip to, rather than using the remote FWD key anyway.

However, that would be a rather radical change that would catch many users out unaware. Perhaps an option could be added to swap the key actions. There's no reason why the FF single and hold actions can't be reversed via a custom key map file either.

Phil

erland
2007-12-23, 17:28
Here's a controversial suggestion, but the more I think about it the more sense it seems to make. Why not reverse the current logic so that a brief press of FF or RW increases or decreases the speed, and a long press skips to the previous or next track?

This would be much more intuitive to me than the current behaviour. It would also make it much easier to seek within a track, since you would be able to control the 'seek' speed with brief presses instead of long presses.

Anyone agree, or is it a stupid idea?

Chris
Not stupid, but I still don't like it.
I've so far never used the fwd/rew functionality, but I regularly choose to skip a track when something bad comes up in a random playlist. Skipping track should be easy to access.

I think the main issues here is really that the remote misses some buttons. Most remote controls for CD and DVD players have separate buttons for fwd/rev and next/prev track, the SB uses the same buttons which causes the user interface to be a bit strange.

peter
2007-12-24, 00:58
On Sun, 23 Dec 2007 15:07:14 -0800, "cbemoore"
<cbemoore.322hen1198451401 (AT) no-mx (DOT) forums.slimdevices.com> said:
>
> Phil Meyer;251058 Wrote:
> > The problem is the FF key will skip to next track if pressed briefly.
> > The key must be held down to invoke some form of fast-forward
> > behaviour.
>
> Here's a controversial suggestion, but the more I think about it the
> more sense it seems to make. Why not reverse the current logic so that
> a brief press of FF or RW increases or decreases the speed, and a long
> press skips to the previous or next track?
>
> This would be much more intuitive to me than the current behaviour. It
> would also make it much easier to seek within a track, since you would
> be able to control the 'seek' speed with brief presses instead of long
> presses.
>
> Anyone agree, or is it a stupid idea?

Changing tracks *is* intuitive, I would suggest keeping that the way it
is.

Regards,
Peter

devaneyk
2008-02-29, 06:52
this is an excellent idea. I think the current FF/REW is the poorest part of the system. On my SB3 the loud cracking and jumping that often happens makes it virtually unusable. I would agree with the audio mute feature as this would prevent this. Keeping it simple and reliable with just the progress bar would be great.

muvster
2008-03-02, 05:32
The one thing I really miss at the moment is the ability to jump around in transcoded material by clicking in the SqueezeCenter track timeline (like I can for native streams). Whatever changes are made to FF/REW functionality, I'd be very happy if only support for that was added.

I agree that the current FF/REW functionality is a bit awkward, mostly because of the dual skip/scan functions of the remote control buttons and the stop-start audio feedback. But I'd be more than happy to use Song Scanner for my scanning needs, as long as I get to jump through transcoded tracks.


Thanks for a wonderful product by the way (I'm a new SB3 owner). I haven't been this excited about a piece of technology since I don't know when.

Jeff Flowerday
2008-03-07, 18:06
Have any decisions been made on this?

I'd prefer silent with a progress bar as well. All my files need to be transcoded so I'm biased.

But as the above poster says if I have use timeline that would work for me as well. Just need some way to move around transcoded files.


Thanks,
Jeff

kdf
2008-03-07, 18:14
>
> Have any decisions been made on this?

nothing public. I supposed awy could answer this if he's not busy with
everything else.

> I'd prefer silent with a progress bar as well. All my files need to be
> transcoded so I'm biased.

You are still out of luck with the current implementation. A progress bar
is still only a GUI. The goToTime() function is the real workhorse in the
current implementation and in the SongScanner plugin on which the new
proposed UI is based. gotoTime() cannot jump through any transcoded
stream.

It would require a new api, common to all transcoding applications that
allows resetting the stream pointer.

-kdf

smc2911
2008-03-07, 19:55
The iPod also has two mechanisms for seeking through a song.
1. Press and hold >> to fast-forward with audio feedback.
2. Press the middle circular button to go to a song progress bar. The wheel is then used to set a specific position within the song. The music plays at normal speed whilst you are selecting a new playback position (whilst the user continues to move finger around the wheel). When the user stops moving for a second or so, playback will automatically resume at that position.Now that we have the SBC with a wheel, I'd love to see 2 implemented, in addition to retaining the current FF/REW functionality (or some variant thereof).

Jeff Flowerday
2008-03-07, 22:44
>
> Have any decisions been made on this?

nothing public. I supposed awy could answer this if he's not busy with
everything else.

> I'd prefer silent with a progress bar as well. All my files need to be
> transcoded so I'm biased.

You are still out of luck with the current implementation. A progress bar
is still only a GUI. The goToTime() function is the real workhorse in the
current implementation and in the SongScanner plugin on which the new
proposed UI is based. gotoTime() cannot jump through any transcoded
stream.

It would require a new api, common to all transcoding applications that
allows resetting the stream pointer.

-kdf


That's too bad.

Thanks,
Jeff

getprogs
2008-03-08, 01:42
But any FF/RW functionality that is usable with WMA files gets my vote! I have votet for the bug regarding the inability to scroll through transcoded files, but just want to add my 5C worth here as well (4 then? 3? 2...?)
I do not care about changing the way it works, I mean even having the ability is a major step up for me :-) (the alternative is to re-rip my +800 CDs, but then I would have to get them from remote storage first etc. etc.)

Apart from that: Still love the product, haven't found anything as good yet! (well - not for the price at least, although a transporter would be a nice addition to the stereo setup ;-)

awy
2008-03-08, 08:01
No, no decisions yet. I am thinking hard about the practicality or retaining the audio feedback, where possible. The current mechanism really is horrible but I can see that it has some use and there is clearly some support for it.

The 'press centre button to enter scan/select mode' sound interesting. Any further comments on this?

Alan.

amey01
2008-03-11, 19:11
Any way to move back and forward in a track would get my vote!! I'm actually in two minds whether audio feedback is useful or not - I personally don't care whether audio feedback is available or not. Even a system where you could type in a time as a "GoTo" field would be fantastic!!

Cobra2
2008-03-12, 10:31
I really hate the FF/RW function...It is the most useless feture when playing my music-collection. (most Flac).
And the DVD speed-x-factor adding x times with each push, is confusing.
I would rather have CD-type FF, even with "AM quality"(32-64+kbs) sound...

Arne K

slimkid
2008-03-12, 11:19
No, no decisions yet. I am thinking hard about the practicality or retaining the audio feedback, where possible. The current mechanism really is horrible but I can see that it has some use and there is clearly some support for it.

The 'press centre button to enter scan/select mode' sound interesting. Any further comments on this?

Alan.

hi,

Any consideration given to 'track scan' plugin type solution, just implementing it in a way that would jump to it and then get back to where the screen was before the action?

thks,

K

dickmc
2008-03-12, 13:54
I don't mind the current design that bad, but find it finicky to use. I do like the audio feedback.

I suggest the following:

1. Display the elapsed time of a song (minutes:seconds) on the player window in Slimserver. (I've always missed this.)

2. When the << or >> is clicked display the resulting speed and direction such as: 2X> 8X< and show the resulting elapsed time as the scan progresses.

3. When not scanning blank out the "2x>" type indicator.

Thanks

awy
2008-03-12, 23:08
1. Display the elapsed time of a song (minutes:seconds) on the player window in Slimserver. (I've always missed this.)


It does (in SC 7).



2. When the << or >> is clicked display the resulting speed and direction such as: 2X> 8X< and show the resulting elapsed time as the scan progresses.

3. When not scanning blank out the "2x>" type indicator.

Do you mean on the WebUI or the player display? On the player display that it pretty much what you get already.

dickmc
2008-03-13, 12:05
"Do you mean on the WebUI or the player display? On the player display that it pretty much what you get already."

On both the web interface and on the player. I am running 6.5. If 7 does this, I guess I have another reason for upgrading when it is stable. :-)

arainert
2008-03-15, 15:50
How do I just skip to the next/previous song?

a

awy
2008-03-25, 04:07
Here is a revised proposal based upon some of the feedback received and the experience of playing around with the implementation.

Proposal:


Press-and-hold ">>" (FWD) or "<<" (REW) to enter Scanner. The scanner is a modified version of kdf's Song Scanner plugin. It displays an input bar (as used for volume, etc.) on line 2 of the display and counters indicating current position and length of the current track. Once in scanner:
The track position counter and input bar track the current position in the track, so long as the UP or DOWN keys have not been used. The track continues to play.
Press UP/DOWN to go forward and back in the track position. The track position counter and input bar track the selected position. The unit of increment is a minimum of 1s, maximum of 5s. Tracks with 100s <= length <= 500s are divided into 100 steps. Progressive acceleration of the scrolling, when the UP or DOWN key is held, makes it practical to seek to a position in tracks of varying lengths, including (at least) up to an hour.
After using UP/DOWN, no further change for between 1-2s will automatically jump to the selected position and remain in the scanner.
Press FWD to enter 2X fast-forward mode. Repeated presses will successively double the scanning speed. Similarly with REW for rewind modes. The fast-forward/rewind mode and rate is indicated next to the position counters. UP/DOWN scrolling can still be used.
Press PLAY to resume normal PLAY and exit the scanner. Any fast-forward/rewind mode is stopped and play continues from the current position. Any pending position change from use of the UP/DOWN keys is invoked.
Press LEFT to exit scanner without applying any pending change. Any fast-forward/rewind mode remains operational.
The scanner will exit when the screen-saver kicks in or any other display mode is invoked.


Currently fast-forward/rewind modes continue across track boundaries in the current playlist. Is this really useful? It seems to me that it would be better if play would stop when either end of the track is reached.

This revised proposal keeps the audio feedback. There has been some support for this although I remain to be convinced that it is really useful. I will look for feedback once the new scanner version (described above) is available.

I would be pleased to get feedback on these revised proposals and additional or alternative suggestions.

Alan.

max.spicer
2008-03-25, 06:27
It sounds to me as if you are needlessly mixing the scanner mode and accelerated playback modes. I think it would be much better if they were entirely separate. During playback, single presses of ffwd/rwd should trigger accelerated playback. Holding ffwd/rew when there is a current track (but not necessarily playing) should enter the scanner mode.


Press UP/DOWN to go forward and back in the track position.

Pressing Up/Down to move forward/back is somewhat counter-intuitive. Does left always have to exit a mode in the Squeezebox UI, or are there already some instances where this is not the case? Given that you enter scanner mode by holding ffwd/rew, it might make sense if during scanner mode you could use single presses of ffwd/rew to move the current position right/left. This would only be possible if the two modes were completely separate, as above.


After using UP/DOWN, no further change for between 1-2s will automatically jump to the selected position and remain in the scanner.

I can't decide whether I like this behaviour or not - I'd have to try it. My Humax PVR has a very similar scanner mode but it doesn't have the timeout. I'm trying to think if any other devices do similar.


Press FWD to enter 2X fast-forward mode. Repeated presses will successively double the scanning speed. Similarly with REW for rewind modes. The fast-forward/rewind mode and rate is indicated next to the position counters. UP/DOWN scrolling can still be used.

I don't think this makes sense when in scanner mode, but fully agree for playback mode. What happens when you reach maximum speed? Does it cycle back to slow speed? Does the cycle first go to 1x? What does the pause button do?


Press PLAY to resume normal PLAY and exit the scanner. Any fast-forward/rewind mode is stopped and play continues from the current position. Any pending position change from use of the UP/DOWN keys is invoked.

Does it make sense to be in scanner mode whilst ffwd/rewind is in effect, or would it be better to have scanner mode cancel ffwd/rewind? I'm not sure. Otherwise, good.


Press LEFT to exit scanner without applying any pending change. Any fast-forward/rewind mode remains operational.

See above.


The scanner will exit when the screen-saver kicks in or any other display mode is invoked.

Good.


Currently fast-forward/rewind modes continue across track boundaries in the current playlist. Is this really useful? It seems to me that it would be better if play would stop when either end of the track is reached.

Agreed.


This revised proposal keeps the audio feedback. There has been some support for this although I remain to be convinced that it is really useful. I will look for feedback once the new scanner version (described above) is available.

I don't like the audio feedback, but that's mainly due to how it's implemented. Audio feedback is a good thing and many devices do it much better. The current method basically sounds like a skipping cd, which is horrible. I've used devices that do this much better, but can't remember how they do it right now, or which devices!

Hope that's helpful!

Max

awy
2008-03-25, 07:05
It sounds to me as if you are needlessly mixing the scanner mode and accelerated playback modes. I think it would be much better if they were entirely separate.

Thanks Max.

The original proposal was simply to get rid of the accelerated playback modes. There has been quit a lot of support for that and some dissent. The revised proposal keeps the accelerated playback.

Yes, this does mix the two modes but I suggest that this is not needless. On the contrary both the scanner and accelerated playback modes are tools to solve the same problem - get from here to there within a playing track. This new design puts them both in the same UI and makes it easy to use either or both.


During playback, single presses of ffwd/rwd should trigger accelerated playback. Holding ffwd/rew when there is a current track (but not necessarily playing) should enter the scanner mode.

There is no FFWD button, only a FWD button. During playback, this has the function to skip to the next track. I do not propose to change this.



Press FWD to enter 2X fast-forward mode. Repeated presses will successively double the scanning speed. Similarly with REW for rewind modes. The fast-forward/rewind mode and rate is indicated next to the position counters. UP/DOWN scrolling can still be used.I don't think this makes sense when in scanner mode, but fully agree for playback mode. What happens when you reach maximum speed? Does it cycle back to slow speed? Does the cycle first go to 1x? What does the pause button do?

Entering scanner mode starts at 1X (that is, normal play). At maximum rate (256X/-256X) further presses have no effect. This is the same as the current accelerated playback functionality.

I'm not sure what the PAUSE button does. I think that it should do Pause/Unpause, with Unpause always being at normal speed.

I agree about the UP/DOWN vs. LEFT/RIGHT thing. It would probably be possible to change but I don't think that it is a sufficiently big deal.

Alan.

slimkid
2008-03-25, 09:51
hi awy,

I like your proposal, well thought of, well rounded.

The only thing, about left/right vs up/down buttons. Are you planning on making it available in .map file? That way anybody can adjust it to their liking On SB it's common to use left/right buttons to traverse up and down the menu structure, so up/down buttons make sense for scanner. For example I'd expect that left arrow takes me back up the hierarchy or jump back where I started from.

thks.

K

Mark Lanctot
2008-03-31, 08:53
I don't like the audio feedback, but that's mainly due to how it's implemented. Audio feedback is a good thing and many devices do it much better. The current method basically sounds like a skipping cd, which is horrible. I've used devices that do this much better, but can't remember how they do it right now, or which devices!

One thing which would help is to reduce the volume from full during scan. See this very, very old bug:

http://bugs.slimdevices.com/show_bug.cgi?id=39

MelonMonkey
2008-03-31, 09:33
Is this circle-jerk ever going to end and see Fast-Forward and Rewind implemented for the Squeezebox? It takes all of a second for anyone familiar with other audio equipment to realize that functionality is completely missing.

The design goal is pretty straight forward, so I don't understand how so much time can be wasted talking about it when it can better be spent on the engineering to achieve that goal.

Single press of FWD or REW buttons - skips to Next or Previous tracks. (We have this now)
Long-Press (press and hold) of FWD or REW - Fast-Forwards or Rewinds through current track. (This still needs to be implemented)

That's the basic functional premise and user-interaction. The only other design elements are visual presentation and audible presentation, neither of which actually change the basic design and functionality.

Once the functionality has been engineered (it should be done in such a way as to not disallow the playback of partial audio), the presentation design can be decided and possibly spread over a number of options. Such as auditory feedback on/off (some CD players for instance let you hear accelerated audio while others don't), temporarily replace display with large-format progress bar so you can clearly see where you are in the song, etc.

cliveb
2008-03-31, 09:44
Overall I like awy's proposal, but have a suggestion for an additional feature. When in scanner mode, it would be useful to be able to enter a time offset into the track using the numeric keypad on the remote. I used to have a CD player that allowed for this, and it was the most efficient way to get to a certain known place.

Of course, on the Controller there is no numeric keypad (or up & down keys), so I'm assuming that when in scanner mode using the SBC, the wheel would be used to select the position within the track.

mvalera
2008-03-31, 16:05
Melon,

Please have a little patience, messing with FF/RW was never going to be a part of the 7.0 release, and that just came out a few weeks ago. This thread is part of the developers specing out what is going to happen down the line for a future release.

Also please watch you language, your last post was flagged by several users for foul language. I don't want to close the thread.

Thanks,

Mike

JJZolx
2008-03-31, 16:15
The design goal is pretty straight forward, so I don't understand how so much time can be wasted talking about it when it can better be spent on the engineering to achieve that goal.

You must be new. This is nothing compared to ~~~~> http://bugs.slimdevices.com/show_bug.cgi?id=112

It's like a 15 page proposal to change a light bulb.

;-)

MelonMonkey
2008-03-31, 21:17
Not new, I just want to see the idea get some traction. It's pointless to keep discussing the same thing over and over when there has already been (in this or other threads) a consensus of what needs to be done.

I'm not sure what foul language Mike was talking about nor why he seems to think I mentioned anything about SC7. Maybe I'm frustrated that despite numerous emails through official customer support channels not one reply has ever arrived... Maybe the customer support staff are out buying dictionaries to check everyone's language use. Better get different languages/regions because not everyone here is from the Southern US.

I'm of course blown away that this wasn't made a priority to be included sometime before SS4, but that's another story. I was going to make the lightbulb analogy originally but didn't want to go there. ;)

Mark Lanctot
2008-04-01, 07:18
I'm not sure what foul language Mike was talking about


Is this circle-jerk ever going to end

It's a pretty obscene connotation and shows a lack of respect for the developers.

Also, why not talk about what is desired BEFORE the feature is implemented? Get it right before releasing it? You think there's a lot of talk about it now, what would it be like if it was released and didn't meet the needs of the users?

Best get your ideas in right now...in a more constructive way.

Philip Meyer
2008-04-14, 15:52
>Is this circle-jerk ever going to end and see Fast-Forward and Rewind
>implemented for the Squeezebox? It takes all of a second for anyone
>familiar with other audio equipment to realize that functionality is
>completely missing.
>
Existing functionality works fine for me; in fact I found it extremely useful rather than a play thing, and quite similar to other audio equipment and some software apps.

What is being proposed is a change to the functionality, not to implement missing functionality. If you find that fast-forward is currently completely missing, maybe you are using transcoded audio (the change doesn't fix that)?

Phil

getprogs
2008-04-15, 11:51
Cheers,
Even though I am not using transcoded audio (WMA was implemented in HW in some 6.x release, cant really remember when) FF/RW does not work for WMA.

I would prefer any sort of functionality than the none-at-all that I currently have, so looking into this is a very welcome suggestion! And without sounding too much like a brown-noser I think it is fantastic to have a developer discussing this with the entire community - not something I am used to (yes, you are right - I am using Microsoft products ;-)

So: Listen with caution to both sides of the story (both the ones telling you the functionality is stupid/idiotic/whatever and the one telling you it is fantastic) and keep up the good work!

Ben Sandee
2008-04-15, 12:23
On Tue, Apr 15, 2008 at 1:51 PM, getprogs <
getprogs.37x9ln1208285701 (AT) no-mx (DOT) forums.slimdevices.com> wrote:

>
> Cheers,
> Even though I am not using transcoded audio (WMA was implemented in HW
> in some 6.x release, cant really remember when) FF/RW does not work for
> WMA.


Are you using WMA-lossless? This is not supported in the firmware and
requires transcoding, AFAIK.

Ben

Wirrunna
2008-04-17, 22:46
I was programming my Logitech Harmony Remote for a new DVD player when I remembered this thread.

Slim Devices is now a Logitech company, how about replacing the Slim Remote with a Harmony 525 (or similar) pre programmed for SC, modify SC to respond to a third remote, (JVC, Classic Slim and now Harmony) and add FF RW etc in SC to work like a VCR now that the full complement of |<< << >> >>| buttons are available.

The marketing guys could wax lyrical about reducing the number of remotes while increasing the integration of SC into the home entertainment area, the production guys would have one less orphan remote to make and the programmers would have a bunch more programmable soft keys and best of all the humble user would (unless he/she has already done so) have one less single device remote cluttering up the lounge.