Fast-forward/rewind redesign

[awy]

(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]

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]

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]

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]

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]

Check out what song scanner plugin does. It delivers nice solution to the problem (IMNSHO).

K

[Deano]

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]

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]

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]

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.