← home

thump

note: thump is defunct.

Feedback

If you have any ideas or opinions regarding thump, playing mp3s/music in general, or anything remotely relevant to thump, please let me know. I like to hear ideas.

Requirements

You need Python 2.2, and either mpg321 or mpg123.

Your Python will need threading support, so on NetBSD (and maybe others, I don't know), install the python2x-pth package, since the default python2x packages do not have threading support.

Source

thump 2

Version 2 is almost a total rewrite, to make thump much more object-oriented. Work will be split up between the player, the queue manager, possibly another controlling process, and various clients. IRC gateway is the plan, a la BitlBee.

• thump2-2003-08-17-01.tgz [ 30 KB ]
• thump2-2003-08-06-01.tgz [ 56 KB ]
• thump2-2003-07-06-01.tgz [ 17 KB ]

thump 1

• thump-2003-05-22-2.tgz [ 6 KB ]
• thump-2003-05-22-1.tgz [ 12 KB ]

Current status

August 17 2003: Now using XML to transfer commands around. Lots of crud cleaned up, config file and code stabilized, playlist with basic functionality works, everything looking really good. Most big problems have been worked out, and now it's just a matter of getting things done.

August 6 2003: Tons of work, tons of changes. I've decided to just use mpg321, at least for now. As things got more complex, I found myself duplicating more and more things that mpg321 already has, so I am using it. Tons of other changes, no time to write about all of them.

July 14 2003: Logging works (much more elegant now too), decoder was mostly overhauled, adding pause/resume, seek, grab/ungrab of DSP, a command queue that listens on a socket is now complete. Tons of docstrings. Some other stuff I can't remember.

July 6 2003: Rewrite underway -- player works, decoder works, a dummy queue reader just takes commands on stdin, logging should work but not tested yet.

Overview

thump stands for The Unix Mp3 Player, the name reflects the goals of the player, and the philosophies that I believe software, and accordingly, software authors, should follow. These ideas form the foundation of Unix-like operating systems. Basically, things should be modular, flexible, and perform specific tasks. Something like that, anyways.

Files

In the thump config directory (normally ~/.thump), there are a number of files that serve various purposes.

[ This section is out of date ]

• access_log is a formatted file listing what songs were played at what time. The odd :@@: sequence is used to split the two fields to make it super easy to parse the file.
• error_log has errors and messages from thumpd.
• fe.pid is a list of the pids of clients/frontends currently running.
• options contains... options. "loop yes", "loop no", "shuffle yes", "shuffle no". Without quotes.
• live-time is constantly updated with the play time of the current song.
• player.pid has the pid of the player.
• playlist is a standard m3u format file, which is, just a list of files, one per line.
• stderr.out is where stderr gets redirected to. If thumpd dies mysteriously, check this file. You can also run thumpd with the -nodaemon option, which stops thumpd from forking and becoming a daemon, and also keeps stdout/stderr directed to your terminal.