Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 5 of 5
  1. #1
    Moser, Robert L. II
    Guest

    RE: Lyrics display

    > A few more requests/ideas if you're reworking that routine anyway...
    > - param for delay before scrolling starts (this is actually critical
    > for me)
    > - option to scroll across once only, then hold showing right-hand end
    > of string (don't add spaces, don't loop)
    > - option to scroll back and forth, bouncing the viewing
    > window between one end of the string and the other


    All these should be possible using combinations of animateSlideWindows with
    some additional code. The last option is already done in the animateFunky
    function.

    Note that the animateSlideWindows allows for setting your own frame rate.

    >
    > (well if you don't ask...!)
    >


    Keep right on asking. It's good to have a challenge.

    From another post:
    >> OK. I'll need to rework how I get the lyrics up then, since it's a
    >> patch to the bottom of Slim::Buttons::Playlist::nowPlayingModeLines at
    >> the moment. I really don't want to have to force the user to enter a
    >> new mode to see the lyrics (assuming there are lyrics in the song &&
    >> the preference to show them is on).


    > This would be Dean's call. I think he mentioned wanting it to be a
    > plugin at first. Patches to change server code, ultimately become his
    > choice to include or not.


    Note that even as a plugin, you can change the lines for the Now Playing
    mode. Have a function which sets $client->lines to your custom function
    (checking to see if you are in the now playing mode first). Then map a
    button in the now playing mode to call that function. You won't get the
    lyrics by default, but they'd only be a button press away.

  2. #2
    Kevin Deane-Freeman
    Guest

    RE: Lyrics display

    Quoting "Moser, Robert L. II" <Robert.Moser (AT) med (DOT) va.gov>:

    > > A few more requests/ideas if you're reworking that routine anyway...
    > > - param for delay before scrolling starts (this is actually critical
    > > for me)
    > > - option to scroll across once only, then hold showing right-hand end
    > > of string (don't add spaces, don't loop)
    > > - option to scroll back and forth, bouncing the viewing
    > > window between one end of the string and the other

    >
    > All these should be possible using combinations of animateSlideWindows with
    > some additional code. The last option is already done in the animateFunky
    > function.
    >
    > Note that the animateSlideWindows allows for setting your own frame rate.


    yes, I saw that one. However, if lyrics are to be displayed along with the "now
    playing" data, it needs to be scroled using the special case that allows the
    updates to line1. Were you thinking that this was part of the additional code?

    Of course, the other option here is to simply decide that the display isnt going
    to supply both lyrics AND progress data.

    IF the lyrics were done as a plugin, and registered as a screensaver, then what
    is the thinking for dealing with the wait until it engages? I would think
    either a button to start screenwaver mode, OR the plugin itself can effect the
    screensaver timeout. This way, it can be set to something like 5 seconds so that
    it can start as soon as the song gets going.

    -kdf

  3. #3
    Robert Moser II
    Guest

    Re: Lyrics display

    Kevin Deane-Freeman blurted out:
    > yes, I saw that one. However, if lyrics are to be displayed along with the "now
    > playing" data, it needs to be scroled using the special case that allows the
    > updates to line1. Were you thinking that this was part of the additional code?


    Yep, look at the animateScrollBottom function, which wraps around
    animateSlideWindows to provide a pause at the beginning. Now imagine a
    different wrapping function which periodically updates $$lineref[0].

    Note also that I am definitely not married to the animateScrollSingle1
    and animateScrollSingle2 functions. They work, but I've never really
    liked them. Mainly I backed off on those so as to avoid a feud with Rutt.

  4. #4
    Kevin Deane-Freeman
    Guest

    Re: Lyrics display

    Quoting Robert Moser II <rlmoser (AT) earthlink (DOT) net>:

    > Kevin Deane-Freeman blurted out:
    > > yes, I saw that one. However, if lyrics are to be displayed along with the

    > "now
    > > playing" data, it needs to be scroled using the special case that allows

    > the
    > > updates to line1. Were you thinking that this was part of the additional

    > code?
    >
    > Yep, look at the animateScrollBottom function, which wraps around
    > animateSlideWindows to provide a pause at the beginning. Now imagine a
    > different wrapping function which periodically updates $$lineref[0].


    ah yes, I see where you are going with this. I've been looking so closely at
    the "now playing" animations that I wasnt' reading far enough down to see how
    the normal scrollBottom is working. Generating the progress bar and elapsed
    time would seem to be costly, so I understand the need to make updates as
    infrequent as possible. How much of a hit would come from an update of simple
    static data? How awful would it be if this new wrapper didn't have a special
    case, and simply updated $line1 periodically regardless?

    > Note also that I am definitely not married to the animateScrollSingle1
    > and animateScrollSingle2 functions. They work, but I've never really
    > liked them. Mainly I backed off on those so as to avoid a feud with Rutt.


    I dont have the history with this stuff that you have, and certainly not the
    expertise, but I haven't been all warm and fuzzy about these either. I can't
    say how it could be fixed yet, but it just somehow strikes me as more
    complicated than it should be.

    -kdf

  5. #5
    Robert Moser II
    Guest

    Re: Lyrics display

    Kevin Deane-Freeman blurted out:
    > ah yes, I see where you are going with this. I've been looking so closely at
    > the "now playing" animations that I wasnt' reading far enough down to see how
    > the normal scrollBottom is working. Generating the progress bar and elapsed
    > time would seem to be costly, so I understand the need to make updates as
    > infrequent as possible. How much of a hit would come from an update of simple
    > static data? How awful would it be if this new wrapper didn't have a special
    > case, and simply updated $line1 periodically regardless?


    The goal is definitely to make it need to do as little as possible in
    the animation function since it has to do it 8-10 times a second.
    Procedure calls in general are more expensive than just working with
    local data. One thing you might look at is turning the special case
    scenario on its head and design for regular updates with a special case
    of doing no update.

    While working on it, you will probably want to add in some calls to
    Time::HiRes::time so that you can see just how long things are taking.
    If you dig deep in the archives of the Yahoo groups there was plenty of
    timing data being passed around, as well as good places to stick timing
    code.

    Most importantly, have fun with it.

Posting Permissions

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