Suggestion: the lyrics view

Discussion:

Suggestion: the lyrics view

Vladimir Todorov

2011-06-02 07:08:47 UTC

Hello Everyone,

Yesterday I tested the ordering of songs when the album contains more than
one CD and the Disk # is specified as "Cd1" / "CD 1" .. instead of just "1"
and it worked just fine. I also tried to load all of my mp3s to see if cmus
will hang again but it didn't so I presume that these features are working
as expected.

Now I have an idea. I hope you will like it.

Is it possible to add another view to cmus - the lyrics view. We can bind it
to the key '8' or the settings view can go to '8' and the lyrics view can go
to '7'.
I really like to be able to see the lyrics of the currently playing song. I
think that other people would like it too.

A little more explanation:

Several days ago I found a script that downloads the lyrics of specified
Artist and Title from wiki lyrics. I enhanced the script by wrapping it into
another script that first checks if the lyrics are available in a local
cache dir and if so they are linked to /home/$USER/lyrics, otherwise the
script that downloads the lyrics is invoked and if the lyrics are found they
are saved to "$baseLyricsDir/Artist/Artist - Title.txt" and after that they
are linked to /home/$USER/lyrics. If the lyrics are not found
/home/$USER/lyrics points to a file that contains the text "no lyrics
found". That way I have my own database of lyrics and the script works
faster when the lyrics are found locally. And the lyrics are not downloaded
every time when they are requested.
The script also checks if the Artist/Title information from the ID3 tags is
null or empty and if so it tries to extract that information from the
filename using a regex. After that I created an alias in my .bashrc file
(alias lyrc="cat /home/$USER/lyrics"). I attached this script to cmus
(status_display_program) and whenever I wanted to see the lyrics I just had
to type "lyrc" in the terminal (I am using tilda so I always have a terminal
opened).

This works fine but I think it will be a good idea to have this feature
inside the cmus player. It doesn't have to download the lyrics from internet
- it just needs to look for the lyrics inside a particular directory which
will be specified in the settings. The format that could be used is
"$baseLyricsDir/Artist/Artist - Title.txt" ($baseLyricsDir will be
configurable). The Title and the Artist will be extracted from the ID3 tag
and if they are not found they could be extracted from the filename with a
regex if the filename satisfies a predefined pattern. Also if the mp3 file
contains lyrics (embedded lyrics) they should have priority over the lyrics
in the local cache. The check if the lyrics are found in the cache and
should be displayed should be done on every lyrics_view_show event because
if a script is used to download the lyrics from internet we will have a
delay before the lyrics appear on the hard drive (if they are found at all).

And after I had the scripts that download the lyrics and link them I wrote a
script that changes the song in cmus on every two seconds and I mute the
volume. That way I succeeded to download 6 000 lyrics over one night. I know
it is lame but for now it is what it is ; )

What do you think about the idea?
Also if someone is interested I could send the full set of scripts that do
this thing. Improvements and suggestions will be appreciated.

/v

Nikita Melnikov

2011-06-02 07:24:50 UTC

Permalink

my opinion is (im not a cmus developer, tho) that this will make cmus
more bloated which is not good. today we download lyrics, tomorrow we
download covers and then we have amarok or whatever. there's no need to
bring any feature ona can imagine into cmus if it's not related to music
playing. especially when you have an external script for this!

but hm... i think it's possible to make a view for external scripts (in
general). that will keep cmus compact and those scripts will act like
some kind of visualisation plugins, haha. just an idea...

Post by Vladimir Todorov
Hello Everyone,
Yesterday I tested the ordering of songs when the album contains more than
one CD and the Disk # is specified as "Cd1" / "CD 1" .. instead of just "1"
and it worked just fine. I also tried to load all of my mp3s to see if cmus
will hang again but it didn't so I presume that these features are working
as expected.
Now I have an idea. I hope you will like it.
Is it possible to add another view to cmus - the lyrics view. We can bind it
to the key '8' or the settings view can go to '8' and the lyrics view can go
to '7'.
I really like to be able to see the lyrics of the currently playing song. I
think that other people would like it too.
Several days ago I found a script that downloads the lyrics of specified
Artist and Title from wiki lyrics. I enhanced the script by wrapping it into
another script that first checks if the lyrics are available in a local
cache dir and if so they are linked to /home/$USER/lyrics, otherwise the
script that downloads the lyrics is invoked and if the lyrics are found they
are saved to "$baseLyricsDir/Artist/Artist - Title.txt" and after that they
are linked to /home/$USER/lyrics. If the lyrics are not found
/home/$USER/lyrics points to a file that contains the text "no lyrics
found". That way I have my own database of lyrics and the script works
faster when the lyrics are found locally. And the lyrics are not downloaded
every time when they are requested.
The script also checks if the Artist/Title information from the ID3 tags is
null or empty and if so it tries to extract that information from the
filename using a regex. After that I created an alias in my .bashrc file
(alias lyrc="cat /home/$USER/lyrics"). I attached this script to cmus
(status_display_program) and whenever I wanted to see the lyrics I just had
to type "lyrc" in the terminal (I am using tilda so I always have a terminal
opened).
This works fine but I think it will be a good idea to have this feature
inside the cmus player. It doesn't have to download the lyrics from internet
- it just needs to look for the lyrics inside a particular directory which
will be specified in the settings. The format that could be used is
"$baseLyricsDir/Artist/Artist - Title.txt" ($baseLyricsDir will be
configurable). The Title and the Artist will be extracted from the ID3 tag
and if they are not found they could be extracted from the filename with a
regex if the filename satisfies a predefined pattern. Also if the mp3 file
contains lyrics (embedded lyrics) they should have priority over the lyrics
in the local cache. The check if the lyrics are found in the cache and
should be displayed should be done on every lyrics_view_show event because
if a script is used to download the lyrics from internet we will have a
delay before the lyrics appear on the hard drive (if they are found at all).
And after I had the scripts that download the lyrics and link them I wrote a
script that changes the song in cmus on every two seconds and I mute the
volume. That way I succeeded to download 6 000 lyrics over one night. I know
it is lame but for now it is what it is ; )
What do you think about the idea?
Also if someone is interested I could send the full set of scripts that do
this thing. Improvements and suggestions will be appreciated.
/v
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev

--
Nikita Melnikov

Paul van der Walt

2011-06-02 09:43:30 UTC

Permalink

Hi,

Post by Nikita Melnikov
but hm... i think it's possible to make a view for external scripts (in
general). that will keep cmus compact and those scripts will act like
some kind of visualisation plugins, haha. just an idea...

Abstraction! Nice! I'm rather in favour of a script-view, not
so much a lyrics view. The lyrics scripts are probably
interesting for the wiki, though.

Paul

--
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Vladimir Todorov

2011-06-02 12:38:24 UTC

Permalink

Well, a script view will do the job. I suppose that it could be implemented
with a named pipe or something similar?

Post by Paul van der Walt
Hi,

Abstraction! Nice! I'm rather in favour of a script-view, not
so much a lyrics view. The lyrics scripts are probably
interesting for the wiki, though.
Paul
--
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev

Jason Woofenden

2011-06-02 16:19:18 UTC

Permalink

Hi all,

I also think that a lyrics view would be overkill, but kinda like
the idea of a text view that scripts can write to. I'm not entirely
sure it's a good idea, I'd love to hear other thoughts about it.

There are certainly plenty of other places/ways to display text, it
doesn't need to be in cmus. But I like the idea of there being a
standard way for cmus scripts to display text. I think this would
simplify documentation and configuration for scripts.

If we are going to do a text view...

We should be able to trigger an update of the text view via cmus
remote and key bindings (no named pipe or any new communication
method.)

API suggestion
==============

:shell -t command [args] write command output to text view

:shell -T command [args] append command output to text view

:set text_display_program triggered when text view is shown

Use cases
=========

Debugging scripts
-----------------

Say I'm working on a script to get cmus to play tracks from
libre.fm. I've got it set up to be triggered by my
status_display_program and want it to output some debugging
messages so I can see what it's sending/receiving from the libre.fm
rest API. I periodically call:

cmus-remote -C ':shell -T echo message'

Displaying lyrics
-----------------

Say I like having lyrics to all my music cached on my hard drive, so I make a
status_display_program that forks into the background, downloads the lyrics (or
reads them from the metadata or cache) and then calls:

cmus-remote -C ':shell -t cat /home/me/.lyrics/cur'

Expensive and/or slow script
----------------------------

Lets say I want to do something that uses enough resources (bandwidth, cpu,
etc.) that I don't want it to execute unless I'm actually looking at the text
view. Examples might be fetching and showing the last 100 tracks scrobbled to
libre.fm or the wikipedia pages for the artist and/or album, or generating some
detailed statistics.

:set text_display_program slow.sh
:set status_display_program slow.sh

slow.sh could be something like:

#!/bin/bash

TMPFILE="$HOME/tmp/image2ascii.$$.pbm"
trap "rm -f $TMPFILE; exit" 0 1 2 3 15

# only do this if the text view is visible
if [ "$(cmus-remote -C 'set view')" = 8 ]
then
cmus-remote -C 'shell -t echo "updating..."'

# FIXME add command to fork into the background

do-something-slow > "$TMPFILE"
if [ $? = 0 ]
then
cmus-remote -C "shell -t cat $TMPFILE"
else
cmus-remote -C 'shell -T failed'
fi
fi

In the above scripts I've assumed that the stdin of the shell command was
hooked to cmus-remote's stdin. This would be very cool, but it'd be OK not to
have it, as temp files can be used.

Well, that was a nice way to pass most of my bus ride. I hope my
thoughts and examples help people think more clearly about how/if
to proceed.

Looking forward to hearing other opinions/ideas.

Take care, - Jason

Johannes Weißl

2011-06-02 21:25:01 UTC

Permalink

Hello Jason,

Post by Jason Woofenden
I also think that a lyrics view would be overkill, but kinda like
the idea of a text view that scripts can write to. I'm not entirely
sure it's a good idea, I'd love to hear other thoughts about it.

Yes, I think this could be a very powerful and flexible solution. I
already hacked a patch that allows display of :run commands a month
ago [1], but a separate view has many advantages (e.g. player
remains controllable while lyrics are displayed).

[1] https://gitorious.org/~jmuc/cmus/jw-cmus/commits/wait_key
e.g.:
:set wait_key=true
:run mutagen-inspect

Post by Jason Woofenden
There are certainly plenty of other places/ways to display text, it
doesn't need to be in cmus. But I like the idea of there being a
standard way for cmus scripts to display text. I think this would
simplify documentation and configuration for scripts.

Yes, me too! Having an xwindow or a textfile somewhere is not nearly as
user-friendly! What I would want is to display the tags of the file
(e.g. mutagen-inspect).

Post by Jason Woofenden
If we are going to do a text view...
We should be able to trigger an update of the text view via cmus
remote and key bindings (no named pipe or any new communication
method.)
API suggestion
==============
:shell -t command [args] write command output to text view
:shell -T command [args] append command output to text view
:set text_display_program triggered when text view is shown

Hmm, not bad! I will think about it, all others should do the same :-)

Hmm, but of course a log file would be an alternative (I do this
already).

Johannes

2011-06-03 05:58:55 UTC

Permalink

Post by Johannes WeiÃl
Hello Jason,

Yes, I think this could be a very powerful and flexible solution. I
already hacked a patch that allows display of :run commands a month
ago [1], but a separate view has many advantages (e.g. player
remains controllable while lyrics are displayed).
[1] https://gitorious.org/~jmuc/cmus/jw-cmus/commits/wait_key
:set wait_key=true
:run mutagen-inspect

Yes, me too! Having an xwindow or a textfile somewhere is not nearly as
user-friendly! What I would want is to display the tags of the file
(e.g. mutagen-inspect).

Hmm, not bad! I will think about it, all others should do the same :-)

Hmm, but of course a log file would be an alternative (I do this
already).

I too, like the idea of a general script view. Instead of a dedicated
lyrics view, a script view would be a really powerful tool, and will
have endless uses, subject to the users' needs and ideas.

Gregory Petrosyan

2011-06-03 00:22:05 UTC

Permalink

Post by Jason Woofenden
Use cases
=========
Debugging scripts
-----------------
Say I'm working on a script to get cmus to play tracks from
libre.fm. I've got it set up to be triggered by my
status_display_program and want it to output some debugging
messages so I can see what it's sending/receiving from the libre.fm
cmus-remote -C ':shell -T echo message'
Displaying lyrics
-----------------
Say I like having lyrics to all my music cached on my hard drive, so I make a
status_display_program that forks into the background, downloads the lyrics (or
cmus-remote -C ':shell -t cat /home/me/.lyrics/cur'
Expensive and/or slow script
----------------------------
Lets say I want to do something that uses enough resources (bandwidth, cpu,
etc.) that I don't want it to execute unless I'm actually looking at the text
view. Examples might be fetching and showing the last 100 tracks scrobbled to
libre.fm or the wikipedia pages for the artist and/or album, or generating some
detailed statistics.

The idea sounds interesting, but the only "real" use case for the
generalization right now is lyrics display; debugging or wikipedia
info seem a little, hm, "unreal" to me. Since there are very limited
number of free views in cmus, I think we should be very careful about
using one of them for a particular new feature.

Can someone come up with more real-life examples of how this
generalization can be useful?

Gregory

Paul van der Walt

2011-06-03 11:01:12 UTC

Permalink

Post by Gregory Petrosyan
info seem a little, hm, "unreal" to me. Since there are very limited
number of free views in cmus, I think we should be very careful about
using one of them for a particular new feature.

What do you mean by that? Is there a limit other than the number
of number keys on the keyboard? Also, people could decide not
to map, say, the playlist view instead (hypothetically).

Not an expert here, just wondering what you mean.

Paul

--
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Gregory Petrosyan

2011-06-03 15:58:56 UTC

Permalink

Post by Paul van der Walt

Well, my point is that while views can be mapped to different keys in
cmus, it is not something you expect users to do, much like you do not
expect people to re-map hjkl in vim (I assume that is possible). So,
IMHO, it is better to limit the number of views to 10 and to map them
to 1...0, to remain consistent and backwards-compatible.

Gregory

Paul van der Walt

2011-06-03 16:07:41 UTC

Permalink

Post by Gregory Petrosyan
Well, my point is that while views can be mapped to different keys in
cmus, it is not something you expect users to do, much like you do not
expect people to re-map hjkl in vim (I assume that is possible). So,
IMHO, it is better to limit the number of views to 10 and to map them
to 1...0, to remain consistent and backwards-compatible.

Okay, fair enough, but then I thought we only had about 5, but I
guess that's not true.

--
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Jason Woofenden

2011-06-04 05:43:17 UTC

Permalink

Post by Gregory Petrosyan

Post by Paul van der Walt

Funny you should use hjkl in vim as an example. Those were possibly
the first keys I remapped. Definitely one of the first anyway. I
would think lots of people would change them to ijkl.

More to the point... using 1...0 for views makes them discoverable.
Which is great for features that are obvious, once visible. But
we're talking about a feature that is only useful after following
install instructions on a website, which can easily tell you how to
activate the scripts output view. So activating it with ":view s"
or whatever, is fine. The instructions for using a script that
displays thins in that view can recommend a key binding, or tell you
about an existing (but not so discoverable) one.

I do think your question about real-world examples bears repeating
though. I tried to come up with some, to help me think through what
would be a good API and to demonstrate it with different sort of
problems (long-running daemon-type script, quick (blocking is fine)
script and a slow-running script that outputs once then exits.) but
as you mentioned, they were a bit contrived.

Anybody have other real-world uses for a script output view?

Take care, - Jason

a.l.e

2011-06-04 18:21:12 UTC

Permalink

Post by Nikita Melnikov
my opinion is (im not a cmus developer, tho) that this will make cmus
more bloated which is not good. today we download lyrics, tomorrow we
download covers and then we have amarok or whatever. there's no need
to bring any feature ona can imagine into cmus if it's not related to
music playing. especially when you have an external script for this!

as somebody who is scared of seeing cmus getting more and more bloated, i guess that i'd prefer to see a way for an external program to ask cmus which song it is currently playing.

sometimes, i also like to see the lyrics of the current song... but i don't see any reason why it should not be an external app.

just my two cents...

ciao
a.l.e