PDA

View Full Version : uninitialized value Slim/Buttons/Playlist.pm line 190



Richard Purdie
2003-11-29, 11:02
Use of uninitialized value in numeric eq (==) at Slim/Buttons/Playlist.pm
line 190.

I'm still getting this as of current CVS as per my original report. I've
done some more digging.

When the server goes into screensaver mode, it calls pushMode which pushes a
new hash reference onto $client->modeParameterStack. If nothing is passed,
it defaults to an empty hash reference.

This means when in screensave mode, browseplaylistindex is not defined which
leads to the above error message. When the player is woken up, it popModes
off the screensaver mode, browseplaylist is back and everything is happy
again.

Should pushMode default to a copy of the existing hash, overwriting any
values it's passed?

RP

Robert Moser II
2003-11-29, 11:49
Richard Purdie blurted out:
> This means when in screensave mode, browseplaylistindex is not defined which
> leads to the above error message. When the player is woken up, it popModes
> off the screensaver mode, browseplaylist is back and everything is happy
> again.
>
> Should pushMode default to a copy of the existing hash, overwriting any
> values it's passed?

I would say that the Screensaver mode should initialize any values it
needs in setMode. Copying the current modestackparameter hash by
default would only be useful if the two modes used the same parameters,
which I don't think is the case most of the time.

Richard Purdie
2003-11-29, 12:26
> > Should pushMode default to a copy of the existing hash, overwriting any
> > values it's passed?
>
> I would say that the Screensaver mode should initialize any values it
> needs in setMode. Copying the current modestackparameter hash by
> default would only be useful if the two modes used the same parameters,
> which I don't think is the case most of the time.

I knew there had to be something somewhere which set variables like that - I
just couldn't find it :). Perl isn't my best lanugage...

Adding :

if (defined(${$client->modeParameterStack(-2)}{'browseplaylistindex'})) {

Slim::Buttons::Playlist::browseplaylistindex($clie nt,${$client->modeParamete
rStack(-2)}{'browseplaylistindex'})
}

to the function SetMode in Slim/Buttons/ScreenSaver.pm gets rid of the
error. Whether this is the right way to fix it or not remains to be seen.

RP

Robert Moser II
2003-11-29, 12:42
Richard Purdie blurted out:
> I knew there had to be something somewhere which set variables like that - I
> just couldn't find it :). Perl isn't my best lanugage...
>
> Adding :
>
> if (defined(${$client->modeParameterStack(-2)}{'browseplaylistindex'})) {
>
> Slim::Buttons::Playlist::browseplaylistindex($clie nt,${$client->modeParamete
> rStack(-2)}{'browseplaylistindex'})
> }
>
> to the function SetMode in Slim/Buttons/ScreenSaver.pm gets rid of the
> error. Whether this is the right way to fix it or not remains to be seen.
>
> RP


In the version I checked in, I initialize it to the currently playing
song like this:
Slim::Buttons::Common::param($client
,'browseplaylistindex'
,Slim::Player::Source::currentSongIndex($client));

Richard Purdie
2003-11-29, 12:51
> In the version I checked in, I initialize it to the currently playing
> song like this:
> Slim::Buttons::Common::param($client
> ,'browseplaylistindex'
> ,Slim::Player::Source::currentSongIndex($client));

What happens if you're browsing the playlist and the screensaver comes on?

If you were browsing item 16 and item 7 was playing, browseplaylistindex
would be 16 and currentSongIndex() would return 7. Both would be 7 when the
screensaver was shown.

I don't think it makes much different to be honest as long as it's set to
something but I don't know the server well enough to know...

RP

Richard Purdie
2003-11-29, 15:45
> In the version I checked in, I initialize it to the currently playing
> song like this:
> Slim::Buttons::Common::param($client
> ,'browseplaylistindex'
> ,Slim::Player::Source::currentSongIndex($client));

As browseplaylistindex isn't really needed in screensaver mode I wonder if
it would be easier to reword the if statement so it didn't use the variable
when the screensaver was active? This would solve all the problems... :)

The attached patch rp3.diff does this.

(and we may as well take out the bit of code added to ScreenSaver.pm as I
suspect it may cause trouble in the future)

RP

Phil Barrett
2003-12-03, 11:05
Attached is my first patch, which adds display of song lyrics.

Currently it only supports ALC format lyrics from two sources:
- Embedded ALC data as created by Visual MP3
(http://www.iprogramdev.com/vmp3/download.htm)
- An .alc file with the same basename as the .mp3 (or .flac or
whatever) - download files from http://www.iprogramdev.com/alc/

Other lyric file formats can be added if requested.

There is one known bug - if a lyric is long enough to trigger
scrolling, it will keep coming back long after it's been replaced by
later lyrics. It's no doubt due to the special-case playlist animation
code, and I don't want to delve too deeply into Display::Animation -
can anyone suggest a fix?

Also I guess a preference to turn off lyrics would be a good idea.

Phil

PS Any other problems, blame my stinking cold!

Kevin Deane-Freeman
2003-12-03, 11:27
Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> Attached is my first patch, which adds display of song lyrics.
>
> Currently it only supports ALC format lyrics from two sources:
> - Embedded ALC data as created by Visual MP3
> (http://www.iprogramdev.com/vmp3/download.htm)
> - An .alc file with the same basename as the .mp3 (or .flac or
> whatever) - download files from http://www.iprogramdev.com/alc/
>
> Other lyric file formats can be added if requested.
>
> There is one known bug - if a lyric is long enough to trigger
> scrolling, it will keep coming back long after it's been replaced by
> later lyrics. It's no doubt due to the special-case playlist animation
> code, and I don't want to delve too deeply into Display::Animation -
> can anyone suggest a fix?

off the top of my head, the bug is due to the amimation as you suspect. I
believe, once the amimation is started, the process continues on its own until
the scroll is completed. This means for long lyrics, it will keep runing for a
long time. the proper place to interrupt is during the pause. Otherwise, you
have to stop the animation timer cycle. Try using
Slim::Display::Animation::killAnimation($client);

-kdf

Phil Barrett
2003-12-03, 12:45
On 3 Dec 2003, at 18:27, Kevin Deane-Freeman wrote:
> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
>> There is one known bug - if a lyric is long enough to trigger
>> scrolling, it will keep coming back long after it's been replaced by
>> later lyrics. It's no doubt due to the special-case playlist animation
>> code, and I don't want to delve too deeply into Display::Animation -
>> can anyone suggest a fix?
>
> off the top of my head, the bug is due to the amimation as you
> suspect. I
> believe, once the amimation is started, the process continues on its
> own until
> the scroll is completed. This means for long lyrics, it will keep
> runing for a
> long time. the proper place to interrupt is during the pause.
> Otherwise, you
> have to stop the animation timer cycle. Try using
> Slim::Display::Animation::killAnimation($client);

Slight problem is that I store no state - the current lyric is looked
up each time the timer is updated. I tried using killAnimation whenever
I sent a non-scrolling lyric, but that didn't work, so I didn't explore
any further. What's odd is that the first scrolling lyric keeps coming
back throughout the song, even though line2 is replaced numerous times.

Phil

Kevin Deane-Freeman
2003-12-03, 13:33
Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> On 3 Dec 2003, at 18:27, Kevin Deane-Freeman wrote:
> > Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
> >> There is one known bug - if a lyric is long enough to trigger
> >> scrolling, it will keep coming back long after it's been replaced by
> >> later lyrics. It's no doubt due to the special-case playlist animation
> >> code, and I don't want to delve too deeply into Display::Animation -
> >> can anyone suggest a fix?
> >
> > off the top of my head, the bug is due to the amimation as you
> > suspect. I
> > believe, once the amimation is started, the process continues on its
> > own until
> > the scroll is completed. This means for long lyrics, it will keep
> > runing for a
> > long time. the proper place to interrupt is during the pause.
> > Otherwise, you
> > have to stop the animation timer cycle. Try using
> > Slim::Display::Animation::killAnimation($client);
>
> Slight problem is that I store no state - the current lyric is looked
> up each time the timer is updated. I tried using killAnimation whenever
> I sent a non-scrolling lyric, but that didn't work, so I didn't explore
> any further. What's odd is that the first scrolling lyric keeps coming
> back throughout the song, even though line2 is replaced numerous times.
>
The line is stored when you start an animation, so replacing the line doesn't
replace the animating information. You might want to try killAnimation
everything you put up a new line. I haven't had a chance to install your patch,
so I am going by the impression of what you are doing. I may have some time
later to try it out if that still isn't the trick.

-kdf

dean
2003-12-03, 13:58
I wonder if we should have a new animation routine that scrolls the
current lyrics continuously according to the timing information.


On Dec 3, 2003, at 12:33 PM, Kevin Deane-Freeman wrote:

> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
>
>> On 3 Dec 2003, at 18:27, Kevin Deane-Freeman wrote:
>>> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
>>>> There is one known bug - if a lyric is long enough to trigger
>>>> scrolling, it will keep coming back long after it's been replaced by
>>>> later lyrics. It's no doubt due to the special-case playlist
>>>> animation
>>>> code, and I don't want to delve too deeply into Display::Animation -
>>>> can anyone suggest a fix?
>>>
>>> off the top of my head, the bug is due to the amimation as you
>>> suspect. I
>>> believe, once the amimation is started, the process continues on its
>>> own until
>>> the scroll is completed. This means for long lyrics, it will keep
>>> runing for a
>>> long time. the proper place to interrupt is during the pause.
>>> Otherwise, you
>>> have to stop the animation timer cycle. Try using
>>> Slim::Display::Animation::killAnimation($client);
>>
>> Slight problem is that I store no state - the current lyric is looked
>> up each time the timer is updated. I tried using killAnimation
>> whenever
>> I sent a non-scrolling lyric, but that didn't work, so I didn't
>> explore
>> any further. What's odd is that the first scrolling lyric keeps coming
>> back throughout the song, even though line2 is replaced numerous
>> times.
>>
> The line is stored when you start an animation, so replacing the line
> doesn't
> replace the animating information. You might want to try killAnimation
> everything you put up a new line. I haven't had a chance to install
> your patch,
> so I am going by the impression of what you are doing. I may have
> some time
> later to try it out if that still isn't the trick.
>
> -kdf
>

Phil Barrett
2003-12-03, 14:23
On 3 Dec 2003, at 20:58, dean blackketter wrote:
> I wonder if we should have a new animation routine that scrolls the
> current lyrics continuously according to the timing information.

Maybe, but I think that the current song title animation routine should
be suitable, if it can just be adapted to cancel animation whenever a
new string is sent.

Phil

Kevin Deane-Freeman
2003-12-03, 14:26
Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> I wonder if we should have a new animation routine that scrolls the
> current lyrics continuously according to the timing information.

is that a hint? ;)
I can look into it since I've been digging around scrollBottom already.

-kdf
ps any thoughts on that last patch?

> On Dec 3, 2003, at 12:33 PM, Kevin Deane-Freeman wrote:
>
> > Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
> >
> >> On 3 Dec 2003, at 18:27, Kevin Deane-Freeman wrote:
> >>> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
> >>>> There is one known bug - if a lyric is long enough to trigger
> >>>> scrolling, it will keep coming back long after it's been replaced by
> >>>> later lyrics. It's no doubt due to the special-case playlist
> >>>> animation
> >>>> code, and I don't want to delve too deeply into Display::Animation -
> >>>> can anyone suggest a fix?
> >>>
> >>> off the top of my head, the bug is due to the amimation as you
> >>> suspect. I
> >>> believe, once the amimation is started, the process continues on its
> >>> own until
> >>> the scroll is completed. This means for long lyrics, it will keep
> >>> runing for a
> >>> long time. the proper place to interrupt is during the pause.
> >>> Otherwise, you
> >>> have to stop the animation timer cycle. Try using
> >>> Slim::Display::Animation::killAnimation($client);
> >>
> >> Slight problem is that I store no state - the current lyric is looked
> >> up each time the timer is updated. I tried using killAnimation
> >> whenever
> >> I sent a non-scrolling lyric, but that didn't work, so I didn't
> >> explore
> >> any further. What's odd is that the first scrolling lyric keeps coming
> >> back throughout the song, even though line2 is replaced numerous
> >> times.
> >>
> > The line is stored when you start an animation, so replacing the line
> > doesn't
> > replace the animating information. You might want to try killAnimation
> > everything you put up a new line. I haven't had a chance to install
> > your patch,
> > so I am going by the impression of what you are doing. I may have
> > some time
> > later to try it out if that still isn't the trick.
> >
> > -kdf
> >

Phil Barrett
2003-12-03, 14:33
Reviewing my patch, I now think that the lyrics code doesn't belong in
Info.pm - it should probably go into a new Music/Lyrics.pm. I'll take a
look at that tomorrow.

Phil

Phil Barrett
2003-12-03, 14:36
On 3 Dec 2003, at 20:58, dean blackketter wrote:
> I wonder if we should have a new animation routine that scrolls the
> current lyrics continuously according to the timing information.

I think I see what you mean now - varying the scroll speed so the
lyrics keep up with the song. Hmm. It really depends on whether people
use lyric files with long lines in them, or break them down into
shorter phrases.

Phil

dean
2003-12-03, 14:41
I agree, or even a plugin.

Also, we should try to factor this in as a new kind of Screensaver.

-dean

On Dec 3, 2003, at 1:33 PM, Phil Barrett wrote:

> Reviewing my patch, I now think that the lyrics code doesn't belong in
> Info.pm - it should probably go into a new Music/Lyrics.pm. I'll take
> a look at that tomorrow.
>
> Phil
>
>

dean
2003-12-03, 16:08
On Dec 3, 2003, at 1:36 PM, Phil Barrett wrote:

> On 3 Dec 2003, at 20:58, dean blackketter wrote:
>> I wonder if we should have a new animation routine that scrolls the
>> current lyrics continuously according to the timing information.
>
> I think I see what you mean now - varying the scroll speed so the
> lyrics keep up with the song. Hmm. It really depends on whether people
> use lyric files with long lines in them, or break them down into
> shorter phrases.

I'm not sure I get what you are saying. If we know the time of the
current lyric and the time of the next one, we can scroll smoothly to
make sure that all the text is seen. Should work with arbitrarily long
lines, right?

Kevin Deane-Freeman
2003-12-03, 16:26
Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

>
> On Dec 3, 2003, at 1:36 PM, Phil Barrett wrote:
>
> > On 3 Dec 2003, at 20:58, dean blackketter wrote:
> >> I wonder if we should have a new animation routine that scrolls the
> >> current lyrics continuously according to the timing information.
> >
> > I think I see what you mean now - varying the scroll speed so the
> > lyrics keep up with the song. Hmm. It really depends on whether people
> > use lyric files with long lines in them, or break them down into
> > shorter phrases.
>
> I'm not sure I get what you are saying. If we know the time of the
> current lyric and the time of the next one, we can scroll smoothly to
> make sure that all the text is seen. Should work with arbitrarily long
> lines, right?

Seems as if Dean is tlaking about scrolling the entire song lyric as one line,
timed such that the end of the line is reached at about the same time as then
end of the song. What Phil seems to be indicating is more like a karaoke feel,
where the song phrases pop up on te display in time to the phrase within the
song, scrolling to suit for some o fthe longer phrases. I'm not sure if thisis
possible since the server has no knowledge of the song phrasing, only the
overall duration. How many typical lyric formats are in use?

-kdf

Phil Barrett
2003-12-04, 12:09
On 3 Dec 2003, at 23:26, Kevin Deane-Freeman wrote:
> Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:
>> On Dec 3, 2003, at 1:36 PM, Phil Barrett wrote:
>>> On 3 Dec 2003, at 20:58, dean blackketter wrote:
>>>> I wonder if we should have a new animation routine that scrolls the
>>>> current lyrics continuously according to the timing information.
>>>
>>> I think I see what you mean now - varying the scroll speed so the
>>> lyrics keep up with the song. Hmm. It really depends on whether
>>> people
>>> use lyric files with long lines in them, or break them down into
>>> shorter phrases.
>>
>> I'm not sure I get what you are saying. If we know the time of the
>> current lyric and the time of the next one, we can scroll smoothly to
>> make sure that all the text is seen. Should work with arbitrarily
>> long
>> lines, right?
>
> Seems as if Dean is tlaking about scrolling the entire song lyric as
> one line,
> timed such that the end of the line is reached at about the same time
> as then
> end of the song. What Phil seems to be indicating is more like a
> karaoke feel,
> where the song phrases pop up on te display in time to the phrase
> within the
> song, scrolling to suit for some o fthe longer phrases. I'm not sure
> if thisis
> possible since the server has no knowledge of the song phrasing, only
> the
> overall duration. How many typical lyric formats are in use?

The lyric formats I support so far just have a list of lyric phrases,
each with the time they occur in the song. So yes, a karaoke feel. With
long lines which will need to be scrolled, we know how long they will
be shown for, since we know the time of the next lyric, so an
intelligent scroll should be possible.

But then again it should also be possible to concatenate all the lyric
strings together and scroll through them at a varying rate.

Phil

dean
2003-12-04, 12:20
On Dec 4, 2003, at 11:09 AM, Phil Barrett wrote:
> The lyric formats I support so far just have a list of lyric phrases,
> each with the time they occur in the song. So yes, a karaoke feel.
> With long lines which will need to be scrolled, we know how long they
> will be shown for, since we know the time of the next lyric, so an
> intelligent scroll should be possible.
>
> But then again it should also be possible to concatenate all the lyric
> strings together and scroll through them at a varying rate.


But where's the bouncing ball?

I think that this is a really neat feature... I'm psyched to see it in
the server release!

Kevin Deane-Freeman
2003-12-04, 12:37
Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

>
> On Dec 4, 2003, at 11:09 AM, Phil Barrett wrote:
> > The lyric formats I support so far just have a list of lyric phrases,
> > each with the time they occur in the song. So yes, a karaoke feel.
> > With long lines which will need to be scrolled, we know how long they
> > will be shown for, since we know the time of the next lyric, so an
> > intelligent scroll should be possible.
> >
> > But then again it should also be possible to concatenate all the lyric
> > strings together and scroll through them at a varying rate.
>
>
> But where's the bouncing ball?

careful what you wish for ;)

>
> I think that this is a really neat feature... I'm psyched to see it in
> the server release!

My concern is that once we do this, everyone and their cat will be wating it to
work with THEIR format. I'm still twitching everytimg I read "but I want cover
art done this way". Waht about embedded ID3 lyrics? What about a big txt file?
Using lyrics is totally new to me so maybe I'm assuming there is more diversity
that there really is, but it would be nice to be aware of what to avoid as we
start to write routines that require time information along with the lyrics in a
specific format.

Otherwise, it would appear a relatively easy thing to add a parameter to the
scroll routines that give an overall time, or pass the framerate directly after
the lyric module handles the math.

-kdf

-kdf

Phil Barrett
2003-12-04, 13:12
On 4 Dec 2003, at 19:37, Kevin Deane-Freeman wrote:
> Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:
>> But where's the bouncing ball?
>
> careful what you wish for ;)

It had crossed my mind!

> My concern is that once we do this, everyone and their cat will be
> wating it to
> work with THEIR format. I'm still twitching everytimg I read "but I
> want cover
> art done this way". Waht about embedded ID3 lyrics? What about a big
> txt file?
> Using lyrics is totally new to me so maybe I'm assuming there is more
> diversity
> that there really is, but it would be nice to be aware of what to
> avoid as we
> start to write routines that require time information along with the
> lyrics in a
> specific format.

I really don't think there's too many formats out there. I've done ALC
because it's easy to parse. The other one I looked at was
www.karaokeisland.com but it seems to be encrypted.

> Otherwise, it would appear a relatively easy thing to add a parameter
> to the
> scroll routines that give an overall time, or pass the framerate
> directly after
> the lyric module handles the math.

I can easily supply a lyric string and a time in seconds over which it
needs to be displayed. Critically, any scroll should never get as far
as repeating.

Phil

Roy M. Silvernail
2003-12-04, 13:38
On Thu, Dec 04, 2003 at 11:37:39AM -0800, Kevin Deane-Freeman wrote:

> My concern is that once we do this, everyone and their cat will be wating it to
> work with THEIR format. I'm still twitching everytimg I read "but I want cover
> art done this way". Waht about embedded ID3 lyrics? What about a big txt file?

Plugins. It's the best way to make the lyric (or cover art) handling
extensible. Plus, when someone cries about their favorite format not
being handled, you can just forward them a copy of the plugin writer's
handbook. :)
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
http://www.rant-central.com is the new scytale
Never Forget: It's Only 1's and 0's!
SpamAssassin->procmail->/dev/null->bliss

Kevin Deane-Freeman
2003-12-04, 13:57
Quoting "Roy M. Silvernail" <roy (AT) rant-central (DOT) com>:

> On Thu, Dec 04, 2003 at 11:37:39AM -0800, Kevin Deane-Freeman wrote:
>
> > My concern is that once we do this, everyone and their cat will be wating
> it to
> > work with THEIR format. I'm still twitching everytimg I read "but I want
> cover
> > art done this way". Waht about embedded ID3 lyrics? What about a big txt
> file?
>
> Plugins. It's the best way to make the lyric (or cover art) handling
> extensible. Plus, when someone cries about their favorite format not
> being handled, you can just forward them a copy of the plugin writer's
> handbook. :)

yes, I think that's why Dean is wishing for this particular Lyric module to be a
plugin. The server, however, does need to support the possible requirements of
such plugins.

-kdf

dean
2003-12-04, 14:37
On Dec 4, 2003, at 12:57 PM, Kevin Deane-Freeman wrote:
>> Plugins. It's the best way to make the lyric (or cover art) handling
>> extensible. Plus, when someone cries about their favorite format not
>> being handled, you can just forward them a copy of the plugin writer's
>> handbook. :)
>
> yes, I think that's why Dean is wishing for this particular Lyric
> module to be a
> plugin. The server, however, does need to support the possible
> requirements of
> such plugins.

Exactly. Let's make it a plugin and then add what we need to support
the new features of such a plug-in (like an API to replace the
screensaver, scrolling enhancements, etc...)

-dean

Kevin Deane-Freeman
2003-12-05, 00:14
Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

>
> I can easily supply a lyric string and a time in seconds over which it
> needs to be displayed. Critically, any scroll should never get as far
> as repeating.

When you get the next version ready, plugin or not, let me know what you require
as far as animation and I can help out with support. If you have sample files,
I could use that as well. I tried to download an alc from one of the links you
posted and it appeared to be binary instead of text so I wasnt sure if it was
the right thing.


cheers,
kdf

Phil Barrett
2003-12-05, 02:00
On 5 Dec 2003, at 07:14, Kevin Deane-Freeman wrote:
> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
>> I can easily supply a lyric string and a time in seconds over which it
>> needs to be displayed. Critically, any scroll should never get as far
>> as repeating.
>
> When you get the next version ready, plugin or not, let me know what
> you require
> as far as animation and I can help out with support.

Will do. Thanks a lot.

> If you have sample files,
> I could use that as well. I tried to download an alc from one of the
> links you
> posted and it appeared to be binary instead of text so I wasnt sure if
> it was
> the right thing.

It is binary, so you're probably OK. But I'll certainly find/invent and
add support for a simple text format too.

Phil

Phil Barrett
2003-12-05, 13:25
This morning, I wrote:
> On 5 Dec 2003, at 07:14, Kevin Deane-Freeman wrote:
>> If you have sample files,
>> I could use that as well. I tried to download an alc from one of the
>> links you
>> posted and it appeared to be binary instead of text so I wasnt sure
>> if it was
>> the right thing.
>
> It is binary, so you're probably OK. But I'll certainly find/invent
> and add support for a simple text format too.

A little googling revealed several suitable formats, so definitely no
need to invent another.

I've now written support for the following:

ALC embedded
..alc file
..lrc file
LYRICS3 1.00 embedded (untested)
LYRICS3 2.00 embedded (untested)

If I can abuse the plugin architecture to just load a .pm without
changing anything else (i.e. no new menu entries etc), I'll make it
easy for others to add support for their favourite format.

Phil

Kevin Deane-Freeman
2003-12-05, 13:44
Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> This morning, I wrote:
> > On 5 Dec 2003, at 07:14, Kevin Deane-Freeman wrote:
> >> If you have sample files,
> >> I could use that as well. I tried to download an alc from one of the
> >> links you
> >> posted and it appeared to be binary instead of text so I wasnt sure
> >> if it was
> >> the right thing.
> >
> > It is binary, so you're probably OK. But I'll certainly find/invent
> > and add support for a simple text format too.
>
> A little googling revealed several suitable formats, so definitely no
> need to invent another.
>
> I've now written support for the following:
>
> ALC embedded
> .alc file
> .lrc file
> LYRICS3 1.00 embedded (untested)
> LYRICS3 2.00 embedded (untested)
>
> If I can abuse the plugin architecture to just load a .pm without
> changing anything else (i.e. no new menu entries etc), I'll make it
> easy for others to add support for their favourite format.
>
> Phil

Cool!

I've been playign around with the animation module a bit. I wanted to do some
destructive testing to see how badly it might fall apart if abused. I am hoping
to get enough time this weekend to patch in an optional param for scrollBottom
to control the framerate. Which makes the most sense?

1) specify overall time, and make the animation routine calculate the framerate.
2) calculate the framrate at the source, and supply raw framerate as the param
3) specify the param as a multiple of the standard framerate.

I'm personally partial to 2 since it is less work for the animation module.

You can then use the following code in your setMode to scroll the lyric lines:

my $rate = $timeToNextLyric / $numberOfCharsToScroll;
$client->lines(\&linesFunction);
my $linefunc = $client->lines();
Slim::Display::Animation::scrollBottom($client,&$linefunc($client),1,$rate);

The 3rd param triggers the special case for "now playing" animation which
updates the top line while the bottom scrolls. use 0 for static top lines.

-kdf

Phil Barrett
2003-12-05, 14:05
On 5 Dec 2003, at 20:44, Kevin Deane-Freeman wrote:
> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
>> I've now written support for the following:
>>
>> ALC embedded
>> .alc file
>> .lrc file
>> LYRICS3 1.00 embedded (untested)
>> LYRICS3 2.00 embedded (untested)

And, shortly, ID3 SYLT as well, which is recommended to encode lyrics
at the syllable level ... bring on the bouncing ball!

> Cool!
>
> I've been playign around with the animation module a bit. I wanted to
> do some
> destructive testing to see how badly it might fall apart if abused. I
> am hoping
> to get enough time this weekend to patch in an optional param for
> scrollBottom
> to control the framerate. Which makes the most sense?
>
> 1) specify overall time, and make the animation routine calculate the
> framerate.
> 2) calculate the framrate at the source, and supply raw framerate as
> the param
> 3) specify the param as a multiple of the standard framerate.
>
> I'm personally partial to 2 since it is less work for the animation
> module.

2 is fine with me.

> You can then use the following code in your setMode to scroll the
> lyric lines:
>
> my $rate = $timeToNextLyric / $numberOfCharsToScroll;

Can I assume something like $rate = 0 means don't scroll at all, and
$rate < 0 means use default scroll speed?

> $client->lines(\&linesFunction);
> my $linefunc = $client->lines();
>
> Slim::Display::Animation::
> scrollBottom($client,&$linefunc($client),1,$rate);
>
> The 3rd param triggers the special case for "now playing" animation
> which
> updates the top line while the bottom scrolls. use 0 for static top
> lines.

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).

Phil

Phil Barrett
2003-12-05, 14:22
>> I've been playign around with the animation module a bit. I wanted
>> to do some
>> destructive testing to see how badly it might fall apart if abused.
>> I am hoping
>> to get enough time this weekend to patch in an optional param for
>> scrollBottom
>> to control the framerate.

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

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

Kevin Deane-Freeman
2003-12-05, 14:24
Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:


> Can I assume something like $rate = 0 means don't scroll at all, and
> $rate < 0 means use default scroll speed?

I suppose that makes as good sense as anything. undef would also lead to default.

> > $client->lines(\&linesFunction);
> > my $linefunc = $client->lines();
> >
> > Slim::Display::Animation::
> > scrollBottom($client,&$linefunc($client),1,$rate);
> >
> > The 3rd param triggers the special case for "now playing" animation
> > which
> > updates the top line while the bottom scrolls. use 0 for static top
> > lines.
>
> 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.

-kdf

Kevin Deane-Freeman
2003-12-05, 14:29
Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> >> I've been playign around with the animation module a bit. I wanted
> >> to do some
> >> destructive testing to see how badly it might fall apart if abused.
> >> I am hoping
> >> to get enough time this weekend to patch in an optional param for
> >> scrollBottom
> >> to control the framerate.
>
> A few more requests/ideas if you're reworking that routine anyway...
> - param for delay before scrolling starts (this is actually critical
> for me)
right now, that is hardcoded. I have been pondering a patch to make this a
setting, since some users have asked for it to be configurable. Up to Dean to
allow it tho :)

> - option to scroll across once only, then hold showing right-hand end
> of string (don't add spaces, don't loop)
It wouldn't be too hard to create a separate routine, scrollBottomOnce() to do this.

> - option to scroll back and forth, bouncing the viewing window between
> one end of the string and the other
I think that's already in there, at least for top line, but I have yet to see it
in action.

-kdf

dean
2003-12-05, 15:56
On Dec 5, 2003, at 1:24 PM, Kevin Deane-Freeman wrote:
>> 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.

I'd like it to use our plugin mechanism (i.e. drop a file in the
plugins folder), but it doesn't have to be a "mode". This will
probably need an API to allow for a plugin to register a screensaver.

That said, it probably makes sense to have the screensavers implemented
as modes that automatically get pushed when the user is idle and popped
when the user presses a button.

You could also use this mechanism to build a player menu that let you
browse screensavers....

-dean

Kevin Deane-Freeman
2003-12-06, 18:22
This is turning out to be a little more complicated that I thought. :)
At some point, this will need a rewrite, but I'm trying to add the lyric support
first. The scrollbottom function now has two new params, but they are not at
the end. Turns out this can't be done since the &$linefunc($client) isn't a
consistent number of args. Thus, params are now:
scrollbottom($client,$interlace,$rate,$line1,$line 2,$overlay1, $overlay2)
interlace is either 1 or 0 and is used to force the "now playing" special case.;
rate is the frame delay time (default 0.15). Negative or undef will revert to
default.
using Zero to indicate no-scrolling is not yet implemented. I'm not sure it
makes sense, since short lines wont scroll anyway. Is there a time when you
would want a long line NOT to scroll?

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> A few more requests/ideas if you're reworking that routine anyway...
> - param for delay before scrolling starts (this is actually critical
> for me)

this is next on the list. The fastest way to do this, i think, without adding
YET another parameter to bounce around the animation module, is to turn this
into a client pref. The downside to this is that you have to remember to set it
BACK to the normal pause when you are done with the lyrics, or exit the lyric
display mode.

-kdf

Phil Barrett
2003-12-07, 04:34
On 7 Dec 2003, at 01:22, Kevin Deane-Freeman wrote:
> using Zero to indicate no-scrolling is not yet implemented. I'm not
> sure it
> makes sense, since short lines wont scroll anyway. Is there a time
> when you
> would want a long line NOT to scroll?

Good question. I guess you could just as easily manually truncate it
and not worry.
You might also want to reserve negative rates for future 'reverse'
scrolling?

>> A few more requests/ideas if you're reworking that routine anyway...
>> - param for delay before scrolling starts (this is actually critical
>> for me)
>
> this is next on the list. The fastest way to do this, i think, without
> adding
> YET another parameter to bounce around the animation module, is to
> turn this
> into a client pref. The downside to this is that you have to remember
> to set it
> BACK to the normal pause when you are done with the lyrics, or exit
> the lyric
> display mode.

Sounds reasonable. But without this control (and/or a
start-scrolling-immediately flag) any calculation of scroll rate I
perform will be pretty meaningless.

Phil

Phil Barrett
2003-12-09, 12:47
Talking of lyrics plugins...

A rough and ready version is attached. It doesn't yet call the
animation routine itself (indeed I'm not yet clear how it can), but it
works pretty well just sending lyrics back from lines().

(NB if you want to try it, you'll need the Info.pm fix from Dan's last
email)

However unless you keep it alive by pressing up/down/right it
eventually times out and is replaced by the screensaver.

Is there a way for a mode to fix itself and refuse to be replaced?

Or has anyone looked into a screensaver API (see Dean's email below)?

Phil


On 5 Dec 2003, at 22:56, dean blackketter wrote:
> I'd like it to use our plugin mechanism (i.e. drop a file in the
> plugins folder), but it doesn't have to be a "mode". This will
> probably need an API to allow for a plugin to register a screensaver.
>
> That said, it probably makes sense to have the screensavers
> implemented as modes that automatically get pushed when the user is
> idle and popped when the user presses a button.
>
> You could also use this mechanism to build a player menu that let you
> browse screensavers....
>
> -dean

Kevin Deane-Freeman
2003-12-09, 13:50
Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> Talking of lyrics plugins...
>
> A rough and ready version is attached. It doesn't yet call the
> animation routine itself (indeed I'm not yet clear how it can), but it
> works pretty well just sending lyrics back from lines().
>
> (NB if you want to try it, you'll need the Info.pm fix from Dan's last
> email)
>
> However unless you keep it alive by pressing up/down/right it
> eventually times out and is replaced by the screensaver.
>
> Is there a way for a mode to fix itself and refuse to be replaced?

Slim::Hardware::IR::setLastIRTime($client,
Time::HiRes::time() + (Slim::Utils::Prefs::get("screensavertimeout") * 5),);

Gregory P. Smith
2003-12-11, 00:41
On Thu, Dec 04, 2003 at 11:37:39AM -0800, Kevin Deane-Freeman wrote:
> My concern is that once we do this, everyone and their cat will be wating it to
> work with THEIR format. I'm still twitching everytimg I read "but I want cover
> art done this way". Waht about embedded ID3 lyrics? What about a big txt file?

yep, and soon someone will probably want it to display the musical notes,
chords, insert-favorite-instrument-here fingering, etc..

Phil Barrett
2003-12-11, 01:21
On 11 Dec 2003, at 07:41, Gregory P. Smith wrote:
> On Thu, Dec 04, 2003 at 11:37:39AM -0800, Kevin Deane-Freeman wrote:
>> My concern is that once we do this, everyone and their cat will be
>> wating it to
>> work with THEIR format. I'm still twitching everytimg I read "but I
>> want cover
>> art done this way". Waht about embedded ID3 lyrics? What about a big
>> txt file?
>
> yep, and soon someone will probably want it to display the musical
> notes,
> chords, insert-favorite-instrument-here fingering, etc..

Not a big problem. Chords, at least, are documented in the ID3 SYLT
tag, which I'm supporting.
If anyone has any an mp3 with real SYLT data, please send it to me for
testing purposes.

Phil

dean
2003-12-11, 08:30
I'd like a copy of that too, to put in my test file library.

On Dec 11, 2003, at 12:21 AM, Phil Barrett wrote:

> On 11 Dec 2003, at 07:41, Gregory P. Smith wrote:
>> On Thu, Dec 04, 2003 at 11:37:39AM -0800, Kevin Deane-Freeman wrote:
>>> My concern is that once we do this, everyone and their cat will be
>>> wating it to
>>> work with THEIR format. I'm still twitching everytimg I read "but I
>>> want cover
>>> art done this way". Waht about embedded ID3 lyrics? What about a
>>> big txt file?
>>
>> yep, and soon someone will probably want it to display the musical
>> notes,
>> chords, insert-favorite-instrument-here fingering, etc..
>
> Not a big problem. Chords, at least, are documented in the ID3 SYLT
> tag, which I'm supporting.
> If anyone has any an mp3 with real SYLT data, please send it to me for
> testing purposes.
>
> Phil
>
>