AddThis Social Bookmark Button

Listen Print Discuss
Mac OS X > Excerpts >

Controlling iTunes with Perl
Pages: 1, 2

iTunes, Perl, and Apache

I have been using Apple's AirPort for a while. We swear by it in my household, and my guests like to bring their laptops and wireless cards when they visit. The Airport has raised our computer expectations -- we want to be able to do any task from anywhere in the house. However, when it comes to playing music, we have a problem. Which computer is hooked up to the stereo? I do not like listening to music on the built-in speakers of my laptop, so I have another Mac hooked up to my stereo and a very large external hard drive filled with MP3s.



With all of that, I cannot carry that computer around my apartment. Even if I could, I want it to just play music and perhaps perform other silent tasks. I should not have to interrupt my music because I decide to change something on the Mac I am working on. I want the music to keep playing even if I restart the iTunes on my laptop, which I do frequently while developing Mac::iTunes.

I need to control this central MP3 player remotely. I could create a command line tool to control iTunes and then log in the machine with ssh, but not everyone who wants to control iTunes likes using the Terminal. I need a more pleasing interface. Since Mac OS X comes with the Apache Web server (which runs by default), I can write a CGI script to control iTunes.

#!/usr/bin/perl
# $Id: iTunes.cgi,v 1.3 2002/09/30 05:09:02 comdog Exp $
use strict;

use CGI qw(:standard);
use Mac::iTunes;
use Text::Template;

my $Template = '/Users/brian/Dev/MacOSX/iTunes/html/iTunes.html';

=head1 NAME

iTunes.cgi - control iTunes from the web

=head1 SYNOPSIS

=head1 DESCRIPTION

This is only a proof-of-concept script.

=head1 AUTHOR

brian d foy, E<lt>bdfoy@cpan.orgE<gt>

=head1 COPYRIGHT

Copyright 2002 brian d foy, All rights reserved

=cut

my $controller = Mac::iTunes->new()->controller;

my $command      = param('command');
my $playlist     = param('playlist') || 'Library';
my $set_playlist = param('set_playlist');

if( $command )
	{
	my %Commands = map { $_, 1 } 
		qw( play stop pause back_track);
	$controller->$command 
		if exists $Commands{$command};
	}
elsif( $set_playlist )
	{
	$controller->_set_playlist( $set_playlist );
	$playlist = $set_playlist;
	}
	
my %var;
	
$var{base}      
	= 'http://10.0.1.2:8080/cgi-bin/iTunes.cgi';
$var{state}     = $controller->player_state;
$var{current}   = $controller->current_track_name;
$var{playlist}  = $playlist;
$var{playlists} = $controller->get_playlists;
$var{tracks}    
	= $controller->get_track_names_in_playlist( 
		$playlist );

my $html = Text::Template::fill_in_file( 
	$Template, HASH => \%var );

print header(), $html, "\n";

On the first run without input, the script creates an iTunes controller object, sets the starting playlist to Library (the iTunes virtual playlist that has everything iTunes knows about), then asks iTunes for a lot of state information, including the names of tracks in the playlists, the names of the playlists, and what iTunes is currently doing (e.g. playing or stopped). The script uses Text::Template to turn all of this into HTML, which it sends back to a Web browser. The template file I use is in the html directory of the Mac::iTunes distribution, and those with any sort of design skills will surely want to change it to something more pleasing. The code is separated from the presentation.

Screen shot.
The Mac::iTunes CGI interface.

I have a small problem with this approach. To tell an application to do something through AppleScript, the telling program has to be running as a logged-in user. The Web server is set up to run as the unprivileged pseudo-user "nobody," so this CGI script will not work from the stock Apache configuration. This is not much of a problem, since I can make Apache run under my user. On my machine, I run a second Apache server with the same configuration file save for a couple of changes.

Mac OS X in a Nutshell

Related Reading

Mac OS X in a Nutshell
A Desktop Quick Reference
By Jason McIntosh, Chuck Toporek, Chris Stone

First, I have to make the Web server run as my user, so I change the User directive. Along with that, I have to choose another port, since only root can use port numbers below 1024, and Apache expects to use port 80. I choose port 8080 instead. I will have to pass this non-standard port along in any URLs, but my CGI script already does that. As long as I use the Web interface without typing into the Web browser's location box, I will not have to worry about that.

User brian
Port 8080

I also have to change any file paths that Apache expects to write to. Since Apache runs as my user, it can only create files were I can create files.

PidFile "/Users/brian/httpd-brian.pid"

Once everything is set up, I access the CGI script from any computer in my home network, Mac or not, and I can control my central iTunes.

iTunes, Perl, Apache, and mod_perl

CGI scripts are slow. Every time I run a CGI script, the Web server has to launch the script and the script has to load all of the modules that it needs to do its work. I have another problem with Mac::iTunes, though. The first call to Mac::AppleScript's RunAppleScript() seems to be slower than subsequent calls. I pay a first-use penalty for that. To get around that, I want to keep my iTunes controller running so I do not have to pay this overhead over and over again.

I created Apache::iTunes to do just that. I could run my CGI script under Apache::Registry, but I like the native Apache interface better. I configured my Web server to hand off any requests of a URL starting with /iTunes to my module. I use PerlSetEnv directives to configure the literal data I had in the CGI version.

<Location /iTunes>
SetHandler perl-script
PerlHandler Apache::iTunes
PerlModule Mac::iTunes
PerlInitHandler Apache::StatINC
PerlSetEnv APACHE_ITUNES_HTML /web/templates/iTunes.html
PerlSetEnv APACHE_ITUNES_URL http://www.example.com:8080/iTunes
PerlSetEnv APACHE_ITUNES 1
</Location>

The output looks a little different from the CGI version because I used a different template that included more features. I can change the look-and-feel without touching the code.

Screen shot.
Mac::iTunes mod_perl interface

I tend to like the mod_perl interface more. Instead of passing variables around in the query string, the URL itself is the command and is simple, short, and without funny-looking characters.

http://www.example.com/iTunes/play
http://www.example.com/iTunes/stop

iTunes, Perl, and Tk

As I was working on Apache::iTunes, I was also working on a different project that needed Tk. I was programming things on FreeBSD, but I like to work on my Mac. That's easy enough, since I have XDarwin and OrobosX installed. Under Mac OS X 10.2 these work without a problem, although if you use 10.1 you have to perform a little bit of surgery on your system, following Steve Lidie's instructions. Since I had been away from the Tk world for awhile, I was referring to Mastering Perl/Tk quite a bit. As I was flipping through the pages on my way to the next thing I needed to read, I noticed a screen shot of iTunes. It was not really iTunes though -- Steve Lidie had taken the iTunes look-and-feel as a front end for his MP3 player example.

I already had all of the back-end stuff to control iTunes and none of it was tied to a particular interface. Even my CGI script could output something other than HTML, like plain text or even a huge image. I could easily add a Tk interface to the same thing -- or so I thought.

Controlling iTunes is easy. Controlling it from a Web page is easy. Controlling it from Tk, which has a persistent connection to whatever it hooks up to, was harder. Since I had the persistent connection, I could reflect changes in iTunes instantaneously. In the Web versions, if somebody else changed the state, like changing the song or muting the volume, the Web page would not show that until I reloaded. The Tk interface could show it almost instantaneously. In reality, I could only get the Tk interface to poll iTunes for its state every 3 1/2 seconds or so before it took a big drop in performance, but that is good enough for me.

Screen shot.
Mac::iTunes Tk interface.

The tk-itunes.pl script comes with Mac::iTunes. Someday I might develop a skins mechanism for it -- all I, or somebody else, needs to do is make the colors configurable. The script already uses a configuration file, although I can only configure a few things at the moment.

Final Thoughts

Perl can interact with Aqua applications through AppleScript. With Mac::iTunes as a back end, I can create multiple interfaces to iTunes that I can use on the same computer or on other computers on the same network. Everyone in my house, or within range of my AirPort, can control my iTunes.

brian d foy is a Perl trainer for Stonehenge Consulting Services and is the publisher of The Perl Review.

Return to the Mac DevCenter.