Controlling iTunes with Perl

EccentricAnomaly writes "brian d foy has created perl modules for controlling iTunes. His modules, Mac::iTunes and Apache::iTunes, can be found on the CPAN. Now perl mongers can run iTunes remotely via the command line or via a web interface on a Mac hooked-up to a nice stereo to use as a home or office jukebox. I shudder to think what else may be possible now that iTunes is in perl's clutches."

Comments

Re:uh, aren't there other players?

[bdash]

One thing that I really like about iTunes is its very easy to see which tracks belonging to which album, and which album belongs to which artist, using the browse mode. The smart playlists feature also means that simply adding a song by your favourite artist to your music library can make it appear in playlists whose criteria it matches.

Re:uh, aren't there other players?

[Melantha_Bacchae]

bdash wrote:

> When using Mac OS X I try as hard as possible to
> avoid 'ports' of *nix software.

Don't look now, but your hard drive has many ports of Unix software that were installed with OS X. But that is because OS X really is Unix.

> This is simply because unless a decent job has
> been done on the porting, the look and feel just
> does not fit with the rest of the system. To
> make a *nix application fit in with the look and
> feel of the system would require a substantial
> amount of modification to the code, sometimes
> enough that it would be easier to just start
> from scratch.

It depends on how separate the user interface is from the rest of the code. If the user interface is well separated, you can just toss that, write a new one in Cocoa, and keep the behind the scenes code. If the program has no graphical user interface, such as say MySQL (an open source back end database program), you can do a fairly straight port.

In this case they are talking about adding the ability to script iTunes with the Perl language the same as you would with AppleScript. No look and feel is involved, and if you don't know Perl you probably wouldn't be using it.

Chief Tsujimori: "I won't let you get away. I will never let you escape."
Godzilla elegantly lifts his tail skyward to give her the "finger", crashes it down on the water, and submerges.
"Godzilla X Megagiras", 2000

Re:For Darwin for OSX

[jcr]

Because OSX has an entirely non standard Gui (from a Unix perspective) that isn't based on X;

Things change. Quartz/Aqua is now the the standard GUI for UNIX, since Mac OS X is far and away the most-numerous UNIX there is.

-jcr

Re:For Darwin for OSX

[good soldier svejk]

I think you miss the point. Where are all the other GUIs from the early 90's (Windows 3.0/3.1 NT 3.51 Gui, the OS/2 gui, DRDos gui...?). All of these GUIs were not designed around a very open and abstract hardware process and thus were tied to very specific notions of how hardware would work. Aqua has the same problem. X conversely does not. X can easily support a 3D virtual reality GUI served up to 10,000 way parellel subsystems... if such things existed. Unix technologies tend to be designed to scale both up to faster system and into the future.

Can you be more specific? I'm not sure how mean this. Are you talking about the benefits of client server network transparency? Quartz (Aqua is essentially just the theme) is based on the same model. It is fully capable of network transparency. OpenStep and Rhapsody's DPS engines supported it. Apparently the hooks are still in there. I once saw them documented in detail on a GnuStep mailing list, but I can't google it and their archive does not seem to be searchable. I did find a mention of them on Ars Technica and Planet PDF. My Apple reps refuse to comment on whether Apple has plans for exploiting this capability.

BTW, Apple continues to update and publish the OpenStep standard and Quartz remains OpenStep compliant. From the GnuStep FAQ:

1.3.2 Is GNUstep following Changes to OpenStep and MacOSX?

Yes, gnustep-base already contains the documented changes in the Foundation library. GNUstep aims to be compatible with both the OpenStep specification and with MacOS-X. It should be easy to write an application that compiles cleanly under both GNUstep and Cocoa.

Re:With a little help from AppleScript, I might ad

[pudge]

Mac::AppleEvents / Mac::Glue allows it. Mac::AppleEvents is currently being ported to Mac OS X, but you can use it from MacPerl in Classic to talk to iTunes in Mac OS X in the meantime.

use Mac::Glue;
my $iTunes = new Mac::Glue 'iTunes';
# optionally talk to another host
# $iTunes->ADDRESS(eppc => 'iTunes', 'otherhost');

my %track;
my $name = $iTunes->prop(name => of => 'current track');
$track{name} = $iTunes->get($name);

$iTunes->pause;

No AppleScript required or used, all raw Apple events, with the AppleScript *vocabulary* used (by parsing the aete resource to do the AppleScript->AE mapping, all done transparently and automatically, after simply dropping the target application on a droplet once). Hopefully, when it is ready for Mac OS X, it can be used as a more efficient and friendly alternative to AppleScript.

Coming soon to Mac OS X box near you, as part of the already-released Mac::Carbon distribution. I am so gonna have fun with this when it is released ...