Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 11 FirstFirst 12345 ... LastLast
Results 21 to 30 of 102
  1. #21
    Senior Member
    Join Date
    Sep 2006
    Location
    Zurich, Switzerland
    Posts
    794
    Quote Originally Posted by Philip Meyer View Post
    I had a play with your patch on a Transporter. Certainly makes more sense having had a play with it, rather than just reading through your proposal notes. I hadn't quite grasped the difference between audio feedback when there was a speed multiplier, and when using the scanner to position the playback position. It's working well.
    Great. Thanks for trying it out.

    1. If I ramp up the playback speed multiplier to eg. >> x8, and then press rewind, it immediately goes into << x2. I think it's better to ramp down to x4, x2, normal, upon each press of the REW button as it used to do. I think Pause can be pressed to return the time to normal speed (but paused), and Play could return to normal speed and continue playback at the new position (but still in the scanner).
    I have not changed the existing operation in this regard. In fact I copied the code verbatim. It is really hard to work out what to do with Pause - that is, what is the perfect operation - but I don't think that it matters that much.

    2. If I turn the knob clockwise, I can scan to almost the end of the track (doesn't quite fill the bar). If I leave the knob for a second so that playback resumes, it transitions to the next track, but the scanner doesn't show the track length details for the next track. On occasions when track transitions occured in the scanner, I found the knob resistance to initially be firm, but then it corrects itself - like the resistance is lagging behind the visual display.
    I don't have a transporter so I have no direct experience of these issues. The track boundary issues have yet to be sorted out.

    3. Due to the divisions into 100th's of the length of the track, it's not possible to set an exact playback location. Not sure if that's a concern - I'll try it with a long track later (eg. 2 hour podcast) to see what it's like then.
    Well it is not exactly divisions of 100ths. The minimum division is 1s, which may result in less than 100 divisions. The maximum division is 5s, which may result in (many) more than 100 divisions. Between 1s and 5s you get 100 divisions scaled as necessary. With my testing I found that this gave reasonably good positioning in tracks anywhere from 1 to 60 minutes.

    For a transporter knob, I was thinking that perhaps the setting of the play position could be non-linear, so with slow movement it would change +/- 1 second, but when turning the knob faster, this would jump in 100th's. Ithink a normal remote would need to be linear as it is now though.
    Like I said, I don't have a transporter. I did note, however, that the INPUT.Bar mode, on which this is based, explicitly disables acceleration for the Transporter knob - perhaps I should enable it for this function. With the IR remote you get acceleration - why don't you try it.

    4. I think there would be some merit in showing the current song position as the user is scanning through the track, to show how far they have scanned. Possibilities are to show the area between old position and new position in a lower brightness, or to put a little marker in the control (eg a ^ pointing at the current playback position). After a second of inactivity, the music would play at the new location and the indicator would move too.
    Possibly over the top, but I'll try it.

    In fact, the scanner is acting as a general playback progress screen. Perhaps the scanner could also be invoked as a Now Playing screen. It could work more like an iPod, where each Now Playing press changes the display. "Now Playing" would initially display the normal now playing screen, a second press would display the scanner. In scanner mode, left/right keys could work like up/down.
    I think that Now Playing is already too overloaded. This new scanner is pretty easy to invoke from NP.

    Alan

  2. #22
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    Fast-forward/rewind resign

    On Mar 26, 2008, at 2:47 AM, Phil Meyer wrote:
    > 1. If I ramp up the playback speed multiplier to eg. >> x8, and then
    > press rewind, it immediately goes into << x2. I think it's better
    > to ramp down to x4, x2, normal, upon each press of the REW button as
    > it used to do. I think Pause can be pressed to return the time to
    > normal speed (but paused), and Play could return to normal speed and
    > continue playback at the new position (but still in the scanner).

    This is one reason why I think if you release the FWD/REW button it
    should stop scanning immediately.

    > 3. Due to the divisions into 100th's of the length of the track,
    > it's not possible to set an exact playback location. Not sure if
    > that's a concern - I'll try it with a long track later (eg. 2 hour
    > podcast) to see what it's like then. For a transporter knob, I was
    > thinking that perhaps the setting of the play position could be non-
    > linear, so with slow movement it would change +/- 1 second, but when
    > turning the knob faster, this would jump in 100th's. Ithink a
    > normal remote would need to be linear as it is now though.

    Right, the acceleration function that we use for scrolling long lists
    should kick in here.

    > 4. I think there would be some merit in showing the current song
    > position as the user is scanning through the track, to show how far
    > they have scanned. Possibilities are to show the area between old
    > position and new position in a lower brightness, or to put a little
    > marker in the control (eg a ^ pointing at the current playback
    > position). After a second of inactivity, the music would play at
    > the new location and the indicator would move too.

    The x2, x4 display really isn't that helpful, better to have a full-
    screen progress bar (like the volume bar) with a time position.


  3. #23
    Senior Member
    Join Date
    Jan 2006
    Posts
    225

    Fast-forward/rewind resign

    >>>>> radish <radish.36uatn1206467701 (AT) no-mx (DOT) forums.slimdevices.com> writes:

    > I think the issue is not whether it skips to the next track, it's
    > whether it starts playing if it were previously paused, e.g.:


    Yes, exactly.. I was complaining that if paused, pressing FWD/REV to
    skip to the next/previous track will unpause and resume playback.
    I'd always assumed that was a bug but from Dean's post it appears to
    be the intended behavior.

    greg

  4. #24
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    Fast-forward/rewind resign

    On Mar 26, 2008, at 6:27 AM, Greg Klanderman wrote:
    >
    >>>>>> radish <radish.36uatn1206467701 (AT) no-mx (DOT) forums.slimdevices.com>
    >>>>>> writes:

    >
    >> I think the issue is not whether it skips to the next track, it's
    >> whether it starts playing if it were previously paused, e.g.:

    >
    > Yes, exactly.. I was complaining that if paused, pressing FWD/REV to
    > skip to the next/previous track will unpause and resume playback.
    > I'd always assumed that was a bug but from Dean's post it appears to
    > be the intended behavior.



    It was the intended behavior, but we could re-categorize it as a bug
    if it's really counterintuitive for most people.



  5. #25
    Senior Member
    Join Date
    Jan 2006
    Posts
    225

    Fast-forward/rewind resign

    >>>>> dean blackketter <dean (AT) slimdevices (DOT) com> writes:

    > It was the intended behavior, but we could re-categorize it as a bug
    > if it's really counterintuitive for most people.


    Hi Dean,

    I'd be interested to know if you can recall your reasons for making it
    that way. It is counterintuitive to me, but I wouldn't want to make a
    change without broader support :-) Of the things I'd like to change in
    SC when/if I have the time, this is pretty low. The one time I really
    wished it worked the other way was trying to sync with a CD player to
    do an A/B test. Both have the least latency starting playback from
    paused but it is hard to get the SB paused at the start of a track.

    Greg

  6. #26
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    Fast-forward/rewind resign

    On Mar 26, 2008, at 7:08 AM, Greg Klanderman wrote:
    > I'd be interested to know if you can recall your reasons for making it
    > that way.

    It just seemed natural to me when I was testing the UI. I _think_ I
    tried a CD player and it had the same behavior, but that doesn't mean
    it was right.


    > It is counterintuitive to me, but I wouldn't want to make a
    > change without broader support :-)

    Agreed, I suspect if we changed this, we'd get complaints.

    > Of the things I'd like to change in
    > SC when/if I have the time, this is pretty low. The one time I really
    > wished it worked the other way was trying to sync with a CD player to
    > do an A/B test. Both have the least latency starting playback from
    > paused but it is hard to get the SB paused at the start of a track.

    Keep in mind that you can scroll through the current playlist and
    press PLAY on the item you want to start on.

    -dean

  7. #27
    Senior Member Philip Meyer's Avatar
    Join Date
    Apr 2005
    Location
    UK
    Posts
    5,596
    This is one reason why I think if you release the FWD/REW button it should stop scanning immediately.
    Awy has already implemented that type of behaviour through the up/down buttons to control scan position.

    The use of FWD/REW buttons within scanner is used to control real-time fast-forward/rewind. It's working well as it is at the moment:

    Press and hold FWD to invoke the scanner. Then each single press of FWD ramps up the playback speed (ie. fast-forward with real-time audio feedback). Similarly for REW.

    My only comment here is that FWD to x8 speed, followed by REW should reduce speed one notch to >> x4 rather than jump to << x2 speed.

    The x2, x4 display really isn't that helpful, better to have a full-
    screen progress bar (like the volume bar) with a time position.
    It's essential in my oppinion. I'm not able to try it again from here, but I thought the multiplier appeared on the top-line with the elapsed time, leaving the bottom line for a full line progress bar anyway.

  8. #28
    Senior Member
    Join Date
    Sep 2006
    Location
    Zurich, Switzerland
    Posts
    794
    Quote Originally Posted by Philip Meyer View Post
    The x2, x4 display really isn't that helpful, better to have a full-
    screen progress bar (like the volume bar) with a time position.
    It's essential in my oppinion. I'm not able to try it again from here, but I thought the multiplier appeared on the top-line with the elapsed time, leaving the bottom line for a full line progress bar anyway.
    Yes, the multiplier indication (speed and direction), if any, is included on the top line next to the numerical position.

  9. #29
    Senior Member
    Join Date
    Sep 2006
    Location
    Zurich, Switzerland
    Posts
    794
    Quote Originally Posted by awy View Post
    4. I think there would be some merit in showing the current song position as the user is scanning through the track, to show how far they have scanned. Possibilities are to show the area between old position and new position in a lower brightness, or to put a little marker in the control (eg a ^ pointing at the current playback position). After a second of inactivity, the music would play at the new location and the indicator would move too.
    Possibly over the top, but I'll try it.
    Alan
    Well I sort of tried it, by specifying that one end of the filled-in bit of the bar should be the actual playing point, and the other end should be the selected point. The remainder of the bar, both to left and right, is left unfilled. In the case that the UP/DOWN buttons have not been used to select the position - the normal case - this results in a single blip along the progress bar at the current playpoint. The bar expands, thus indicating the distance from the playpoint, when the UP/DOWN buttons are used.

    I think it looks terrible. My wife quite likes it. You can try it if you like and want to patch the code:

    Add the following line the the 'headerValue' inline subroutine in Plugin.pm:
    Code:
    $client->modeParam('mid', Slim::Player::Source::songTime($client));
    Alan.

  10. #30
    Senior Member radish's Avatar
    Join Date
    Apr 2005
    Location
    Red Bank, NJ
    Posts
    5,052
    While on the topic, what are people thinking in terms of audible feedback? One thing I'd _really_ like is pitched playback (like when fast-forwarding a tape), rather than the current approach of normal-speed snippets. I realise that the current approach is used in most CD/DVD players, and I quite understand why from an implementation point of view I just think it's much easier to find the place you're looking for when it's playing smurf-style than with the choppy audio.

    I'm thinking something on the server side to decimate samples out of the audio stream (thus increasing frequency and reducing duration) before sending it to the player. Obviously there's a number of problems with such an approach (such as how to deal with transcoded formats, reverse play, etc) but it'd still be cool

    I've heard such manipulation done very well in various music production / audio editing apps (Serato Scratch is simply amazing in that respect).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •