Art
Computing
Contact info
CV
Electronics
Geek culture
Home brewing
Math
Music
Physics
Rants
Ψ/Φ
Style
Teaching
Theatre
WHAT'S UP
Comms is a curses (textmode) front end for Audacious and XMMS based on Ulf Betlehem's cplay. It is written in Python using some extra libraries for interfacing, and released under the GNU GPL.
It's a relatively quick hack to fulfill my own purposes, so don't expect too much. It's geared towards power users with some familiarity with XMMS-like players and/or cplay, but of course everyone is welcome to try it. Please let me know if you make any notable improvements.
[2015-08-06] D-Bus library changed to make newer Audacious work again.
[2014-10-05] Audacious 3.5 has updated its D-Bus implementation, and Comms does not currently work with it. Use 3.4.* until a solution is found.
[2012-07-11] Comms is alive and well with Audacious 3.2.4. Available on Github from now on.
Starting with version 1.4.0, Audacious allows control via D-Bus. Since I had to update the Python interface anyway, I decided to use pure D-Bus and do some other updates. XMMS is no longer supported, for that you can use the old version.
This version also works with Audacious 2.0 and higher. However, some features are broken prior to 2.2 beta1, namely the remote controls for repeat and shuffle, as well as the binary name ("audacious2" instead of just "audacious").
Note about audio CDs: the new libcdio plugin isn't accessible via D-Bus, as far as I know. You need to use the Audacious GUI: Right click -> Plugin services -> Add CD. Nevertheless, you can then use Comms to deal with the tracks as usual.
Requires:[2006-11-02] I'm migrating to Audacious as XMMS is starting to lose support. So I'm working on porting Comms respectively.
The port is based on Ben Wolfson's xmmsalike.py that implements a replacement for pyxmms using ctypes. The idea with ctypes is that you can directly access functions in the interface library (.so) without having to write a Python interface module in C.
The xmmsalike.py module actually works for XMMS and its two successors/forks, Beep Media Player and Audacious, since the control interfaces are essentially the same. Comms should work for all of them now, though I have not tested BMP. The old PyXMMS version is still available below.
Prerequisites:To run it, you should have Audacious/BMP/XMMS running first, and start Comms in a terminal. Press 'h' to see the keybindings; for example z, x, c, v, b are the same as in the player.
If there isn't a player running, Comms will try to start it in an existing X server. For this purpose you can set a default player in the script (near the top of the file).
If there isn't an X server available, Comms will try to start it in headless mode. Audacious has a native headless mode, for the others you need Xvfb to run headless. The Xvfb way is not well tested and I may remove it in the future.
Usually, I have the player running with X on my desktop/media station, and I'm controlling it via Comms over SSH (in a screen) from my laptop. It's a nice example of the client/server idea, and it doesn't matter if you have other instances of Comms running. I also use Comms locally, since the keyboard navigation is nicer for many things, and for the cache function — see below.
On 2006-03-29 I implemented an idea to help me with DJing. The problem is that I have lots of music files burnt to CDs and DVDs, which makes it hard to switch between two arbitrary songs with only one drive. 'Real' vinyl/CD DJs have the basic solution of using two or more players/turntables, and in the same way I could just add another CD/DVD drive.
However, you could just as well copy the desired file onto the hard drive, and play the copy instead. I've done this by hand very occasionally, but it's pathetically inconvenient. Thus I wrote a caching function into Comms. Instead of adding a file with the space key, use 't' to cache it. Then you can umount the disc and keep playing.
The cache directory will be created as ~/tmp/comms-cache, and it will not be cleaned up by Comms. As far as I know, it's not possible to query directly whether a file has been played; it must be done indirectly using extra tools like marker files. Even then you might want to play it again :) IMHO this is not a big issue, but it would be nice to find a solution.
[2012-07-11] Keys 1..9, 0, F1...F12 now act as play buttons for tracks 1 to 22. This should help with theatre sound effects, for example. For this reason I had to remove keys 9 and 0 from volume control, but - and =/+ are still available.
XMMS handles audio CD tracks as virtual files in /mnt/cdrom, or whatever directory you have set. Thus Comms utilizes recursively adding directory contents for putting audio CD tracks into the playlist. As a neat side effect, when you mount a CD/DVD of audio files, you can use the same 'C' command to recursively add those files :)
On one of my machines, Audacious/XMMS misinterprets mounted DVD+Rs as audio CDs with a single track. This means that recursively adding any directory on the disc will fail :-/ This can be circumvented by changing the CD Audio directory to something else than the mount point. For audio CDs it won't make any difference, 'C' will work anyway, but then again it won't work for data discs.
I haven't got much experience on these, but they may be good starting points if you're looking for alternatives.
Here are notes of mainly historical interest, outlining the conversion of Cplay into Comms.
There's an important paradigm shift, as the program is changed from the all-managing cplay to a humble client of XMMS (server). Generally, if we input something, it goes directly to XMMS, and most of the visual info is something we have requested from XMMS. For example, the playlist is fully managed by XMMS and we just draw the titles into our playlist buffer.
It's possible to do things differently; for example, XMMS can be used as a standalone 'player' just like mpg123. (Of course this isn't practical considering the time it takes to start and quit.) However, I wanted to keep Comms as a 'humble client' and maintain the possibility of control by other clients at the same time (very useful when developing/debugging Comms). The other client can even be a different instance of Comms, or the XMMS GUI itself. E.g. if the playlist is changed by others, Comms should display the new contents, because it's only the XMMS playlist that is actually being played
Some important changes were made to the user interface, to suit the
way XMMS works. In XMMS style there are the keys [zxcvb] =
Originally I used the xmms-module by Disconnect which was not complete, and I extended it to suit my needs. Here is the tarball which doesn't work any more (the script is already ported to pyxmms). To build it anyway, unpack and $ make -f Makefile.pre.in boot; make; make install. You may have to tweak the Makefile* for your system. It requires development packages (headers) for Python and XMMS.