Slashdot Mirror
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."
When using Mac OS X I try as hard as possible to avoid 'ports' of *nix software. 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.
The PERL needs AppleScript to talk to iTunes. It doesn't do it on it's own...been there and doing the same thing with PHP :)
Check my gallery site that lets visitors also spy on my currently playing song, etc. I use PHP and MySQL to manage a Mac and Linux (2 box combo) image database. Just for fun, PHP, along w/AppleScript, pulls data from iTunes, while it supports image serving, uploading, resizing, etc. Ho Ho Ho
The Windows Media Player for OS 9 was "powered by Quicktime", hilariously enough.
the subject pretty much covers it completely
Controlling music remotely is only useful when there is a function to turn the volume to 11.
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
The PERL needs AppleScript to talk to iTunes. It doesn't do it on it's own...been there and doing the same thing with PHP :)
Yeah, the only problem is you're doing the same, tired "look what I can play" garbage. There has only been one really useful application of iTunes scripting: iSing, and even that is questionable if you survey your surroundings when the song is over. :-)
The original posting should have made this point, as my original reaction was "why use Perl rather than AppleScript"; reading the article, I see there is a good argument in favor of using Perl along with AppleScript, but I imagine I wasn't the first one to go to the page with that thought at the top of my mind.
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
The only title of honor that a tyrant can grant is "Enemy of the State."
Well no:
1) Used by only one vendor and is going to remain that way
2) It is tied to a particular hardware model and thus is likely to be outdated within a decade
3) It is not network transparent which has been a Unix feature on GUIs for 2 decades and on the system itself for 3 decades
4) The vast majority of Unix apps don't support it
5) If you include X windows servers running on PCs and dumb X terms I'm not sure it has more users than X so even your sole reason for considering it standard may not be.
Well no:
1) Used by only one vendor and is going to remain that way
That one vendor is the UNIX volume leader.
2) It is tied to a particular hardware model and thus is likely to be outdated within a decade
No, Quartz is quite hardware-independent.
3) It is not network transparent which has been a Unix feature on GUIs for 2 decades and on the system itself for 3 decades
Ok, I'll give you that one. The benefit of Quartz 2d's rendering library living in the app's address space though, is increased 2-d rendering performance.
4) The vast majority of Unix apps don't support it
This will change. A lot of X-windows apps are getting new GUIs as we speak.
5) If you include X windows servers running on PCs and dumb X terms I'm not sure it has more users than X so even your sole reason for considering it standard may not be.
I'm not sure that X terms make much difference in the figures.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
> No, Quartz is quite hardware-independent.
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.
> > The vast majority of Unix apps don't support it
> This will change. A lot of X-windows apps are getting new GUIs as we speak.
If this happens along with Unix apps considering OSX / Aqua their home platform that IMHO would make Aqua the Unix standard interface with X the "backwards compatabile" interface.
> I'm not sure that X terms make much difference in the figures.
I see a tremendous number of corporate desktops running PC X servers. There are still quite a few Unix/VMS/Z-OS apps served out via. X in the corporate world. In manufacturing I see dumb X terms all over the place. In these environment computers get damaged by user error and machinery too much to have their processing be local (as well as cost saving issues).
If this is the same code that was discussed over at O'Reilly you need to start tweaking how Apache or other things run.
There was a discussion of this over at MacNN Forums as well.
PERL is not talking to iTunes. AppleScript handles that. All in all, a less than earth shattering event.
Both links I provided discussed this in depth.
I was curious if the Perl scripts mentioned were simply calling the same Applescripts and how they dealt with these issues. My sense was that they were variations on the similar Perl code discussed at the MacDev page at O'Reilly.
Capiche?
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:
It is cowardly, and a betrayal of whatever it means to be a Jew, to act as a white man
-James Baldwin
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