PDA

View Full Version : RE: Lyrics display



Moser, Robert L. II
2003-12-05, 14:35
> 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.

Kevin Deane-Freeman
2003-12-05, 22:32
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

Robert Moser II
2003-12-06, 12:43
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.

Kevin Deane-Freeman
2003-12-06, 13:15
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

Robert Moser II
2003-12-06, 13:44
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.