Millwood;306389 Wrote: > How should the software "know" that you are done seeking? Remember, you > can seek by holding down the fwd key, or by pressing up/down (SB3) or > using the scroll wheel (Controller). After you press up, when are you > "done". The current answer is a time delay. What's your alternative?
First, on my 7.1 build (admittedly 2-3 weeks old), the FF/RW and the UP/DOWN buttons function identically, except one must use FF/RW to initiate the seek. Once the scanner is up, they work the same, at least I haven't noticed different speeds or accelerations or anything difference. I'm not even sure what the point is of the duplicated functionality. Why would I want to use the UP/DOWN buttons to seek? Point is, one must hold any of those buttons down to continue seeking. Thus the software knows the user is done seeking when the button is no longer being held down and thus can get rid of the scanner display. Similarly, the software can easily detect when the scroll wheel is no longer moving to again stop seeking and get rid of the display. Now to clarify, it isn't really the scanner display that bothers me, but rather the mode of operation changes when the scanner display is up. Thus, delays and additional button presses are introduced to get back to NORMAL CASE OPERATION, which is what I'm advocating be eliminated. Seeking is a transient operation which has easily detectable start and end points and I don't see the difficulty in getting the software to sync up with that. CD players do it; why can't SqueezeCenter et al. do it as easily too? Even if the UP/DOWN arrows worked differently than the FF/RW in that a single press instantiated a seek (say 2x speed) without being held down, detecting the end of a seek is not a problem. The seek ends when the user presses PLAY or PAUSE; easy! However, the problem is how to enable such a seek mode since the UP/DOWN buttons have meaning for both single presses and held presses. I don't claim to have THE solution to that problem but off the top of my head, why not the following: A non-button-hold seek could be started by a quick double tap of the UP/DOWN arrow. Alternatively, the double tap operation could be made on the FF/RW (in addition to the [single press:skip track] and [hold:seek] modes). I think overloading the FF/RW again makes for more intuitive sense for a user. Then, while the scanner is up, the UP/DOWN arrow keys could be used to change the speed from 0.25x, .5x, 1x, 2x, 4x, etc. The only issue I can see is that there may be difficulty in detecting a double tap from an IR remote; having never programmed for one, is it an issue or is it easy to implement? Having seeking operating as above, looks to be the best of all worlds, with none of the disadvantages. However, is this a non-hold seek discussion even relevant? AFAIK, this non-hold seek model isn't even included in the 7.1 current builds and I have no idea if it is even planned to be included. It really isn't a problem if it doesn't exist. :) I think that such a seek mode is unnecessary and feel that it is less advantageous than the hold model. Furthermore, trying to accommodate to both appears to be complicating the use of either. It would be easy to add the single press 2x seek using the arrows in the current model of bringing the scanner up until a timeout or explicit escape occurs. However, the current operation doesn't optimize for the common case of usage and that is why it is cumbersome to use. Instead, it complicated for flexibility (yet seemingly doesn't even offer that). I'd rather see one seek model be great, than have two different ones that are annoying to use. -- ctm ------------------------------------------------------------------------ ctm's Profile: http://forums.slimdevices.com/member.php?userid=17698 View this thread: http://forums.slimdevices.com/showthread.php?t=47250 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
