On Wed, 27 Jan 2016 14:05:14 -0800
Ian Zimmerman <itz@???> wrote:

> On 2016-01-27 13:29 -0500, Steve Litt wrote:
>
> > A playlist handler is a programming 101 assignment enabling you to
> > load playlists and navigate within them, and while you're at it go
> > backward and forward in your current song.
>
> ...
>
> > My point is this: If a music player has anything but the most
> > rudimentary dependencies, those dependencies promote either
> > "pretty", or stuff outside the core competency of a music player.
>
> I respectfully disagree.
>
> I like to handle my music in terms of performers, composers, and
> titles; _not_ filenames. Thus some kind of database storing the
> collected tag information from the files seems completely appropriate
> to me. (Ideally this would be sqlite so I can browse it with generic
> SQL tools, like python :-Q )

I think you're *agreeing* with me. Have everything in a database (I
personally would never put whole files as a blob in a database, I'd put
a pointer to the on-disk file. But either way, it's not that hard to
program. Perhaps I should have said Programming 201.

>
> This is why I like mpd; it does this, unlike other simple text based
> players, like moc which I used before.

You could do this with a text playlist handler, or a very simple python
Tkinter app.

>
> Also, the separation of playlist/queue handling and actual audio
> output may not be as clean as you present it. Think about
> cross-fading for example (not that I ever use it, but mpd can do it
> IIRC).

Yeah, cross fading was one of those things in my mind when I discussed
"pretty" or "outside the core competency of a music player." Besides,
I'm pretty sure your playlist handler can tell mplayer to raise and
lower volume to fairly accurately imitate cross fading.

SteveT

Steve Litt
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28