iPod and iTunes Hacks

Control iTunes with Perl

Use the Mac::iTunes Perl module to control iTunes from scripts and from other machines

When I started to work with iTunes AppleScripts, I wanted them to be as easy to write as Perl scripts, even though they were not. After a while, I decided to fix that by writing a Perl module to handle the AppleScript portions of iTunes. I already had a MacOSX::iTunes Perl module that I used to parse the binary format of the iTunes Music Library.xml file. I needed to add AppleScript support to it.

On the suggestion of Chris Nandor, the caretaker of MacPerl and author of Mac::Carbon, I changed the name of my distribution to Mac::iTunes and added the Mac::iTunes::AppleScript module, which wrapped common AppleScripts in Perl functions. The meat of the module was the _osascript routine, which creates an AppleScript string and calls osascript:

sub _osascript
        {
        my $script = shift;

        require IPC::Open2;

        my( $read, $write );
        my $pid = IPC::Open2::open2( $read, $write, 'osascript' );

        print $write qq(tell application "iTunes"\n), $script,
						qq(\nend tell\n);
        close $write;

        my $data = do { local $/; <$read> };

        return $data;
        }

The Mac::iTunes::AppleScript module works much like the osascript command-line tool. Indeed, the first version simply created a script string (called osascript) with that script and captured the output, if any, for parsing. About the same time I finished the first version, Nathan Torkington needed Perl access to AppleScript and convinced Dan Sugalski to write Mac:: AppleScript. With that module, Perl could work with AppleScript without calling an external program. I replaced the _osascript routine with tell(), which uses the RunAppleScript function from Mac::AppleScript:

sub tell
       {
       my $self = shift;
       my $command = shift;

       my $script = 
               qq(tell application "iTunes"\n$command\nend tell);

       my $result = RunAppleScript( $script );
       if( $@ )
               {
               carp $@;
               return;
               }

       return 1 if( defined $result and $result eq '' );

       $result =~ s/^"|"$//g;

       return $result; 
       }

Once I have tell(), I simply feed it an AppleScript string, which it runs and then returns the result. For example, iTunes can play Internet streams. The AppleScript way to say this uses open location:

tell application "iTunes"
        open location "http://www.example.com/streaming.mp3"
end tell

In Mac::iTunes::AppleScript, I wrapped this little script in a method, named open_url(), which takes a URL as an argument and uses tell () to run it:

sub open_url
        {
        my $self = shift;
        my $url = shift;

        $self->tell( qq|open location "$url"| );
        }

Most of the AppleScript commands for iTunes have a corresponding method in Mac::iTunes::AppleScript. Now I can use the full power of Perl, even though I am really using AppleScript behind the scenes.

iTunes, Perl, and Terminal

Just as I ran AppleScripts from the Terminal window with osascript, I can now run Perl programs that interact with iTunes. I want to play streaming media with few keystrokes and without going to the iTunes Open Streaming… menu item; that’s just too much work when I do not want to switch applications.

I created a simple program, named stream, using Mac::iTunes. I create an iTunes controller object and then call the open_url() method with the first command-line argument. Perl tells iTunes to play the MP3 stream, and even though iTunes starts to do something, it stays in the background while I continue whatever I am doing. I can even use this program from shell scripts:

	#!/usr/bin/perl
	use Mac::iTunes;
	my $controller = Mac::iTunes->controller;
	$controller->open_url( $ARGV[0] );
	% stream http://www.example.com/streaming.mp3

Small scripts do not have much of an advantage over the equivalent AppleScripts, but as things get more complex, Perl starts to shine.

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 large external hard drive filled with MP3s.

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: ch04.xml,v 1.4 2005/07/16 19:13:31 becki 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>[e-mail]<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), and 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, as shown in Figure 4-38.

Figure 4-38. The Mac::iTunes CGI interface

The template file I use is in the html directory of the Mac::iTunes distribution. If you have any design skills, you’ll surely want to design something more pleasing. The code is separated from the presentation.

I have a small problem with this approach. To tell an application to do something via AppleScript, the telling program has to be running as a logged-in user. The web server is set up to run as the unprivileged pseudouser 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.

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 nonstandard 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 create files only where 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 that I don’t 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 used 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, shown in Figure 4-39, 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.

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

Figure 4-39. Mac::iTunes mod_perl interface

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.

Since I had been away from the Tk world for a while, I was referring to Mastering Perl/Tk (O’Reilly) quite a bit. As I was flipping through the pages on my way to the next thing I needed to read, I noticed a screenshot 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, such as 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, such as 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 get the Tk interface to poll iTunes for its state only every three and a half seconds or so before it took a big drop in performance. But that’s good enough for me. Check out the Tk interface in Figure 4-40.

Figure 4-40. 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) need to do is make the colors configurable. The script already uses a configuration file, although I can configure only a few things at the moment.

Final Thoughts

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

—brian d. foy