Forgot your password?
typodupeerror
Perl Businesses Programming Apple

Controlling iTunes with Perl 47

Posted by pudge
from the stupid-perl-tricks dept.
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."
This discussion has been archived. No new comments can be posted.

Controlling iTunes with Perl

Comments Filter:
  • aren't there other players for mac?
    or is itunes that good that you would rather use it through web interface than say, mpg123/whatevers the commandline player of the day?

    this sounds cool and all, but, like, porting xmms would have been cooler, right?(xmms runs pretty easily on osx, does it(why not if not?)?)

    • iTunes is pretty much the best all-in-one mp3 there is for any OS. Its main appeal on Mac's though is the integration with the iPod.
      • 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.
      • by Anonymous Coward
        There are other players (Audion), but iTunes really does several things quite well. It's tight integration with your library (25GB in my case), and the power to organize and find, prompted me to get an iPod.

        Adding PERL support is good, however one need only look to the AppleScripting that's already out there for iTunes, and one need not shudder; it's already being scripted to adapt to many uses.

    • 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.
      • by Melantha_Bacchae (232402) on Tuesday November 26, 2002 @12:40PM (#4759510)
        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
        • Because OSX has an entirely non standard Gui (from a Unix perspective) that isn't based on X; I kind of like to use the distinction

          For Darwin = Unix CLI or for Darwin/X
          For OSX = Aqua interface

          Fink for example ports to Darwin not to OSX.

          To take your MySQL example, it is not common for Mac applications to have a CLI management system. So a port to OSX IMHO should involve a full Aqua management console. I certainly agree that Fink (et al) have ported it quite well to Darwin.

          • by jcr (53032) <jcr@NoSPaM.mac.com> on Tuesday November 26, 2002 @03:25PM (#4761061) Journal
            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

            • by jbolden (176878) on Tuesday November 26, 2002 @03:41PM (#4761243) Homepage
              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.

              • And Aqua's closed. Closed "standards" generally find it hard to gain full acceptance in the Unix/Linux world, and eventually are replaced by freer standards.

                As much as I want to, the IT bosses won't let me bring in OSX at work because they can't see the code. If they can't see the code, they can't prove there's no backdoors in it to their bosses. From that standpoint, Aqua's no better than having WindowsXP on our servers. And we're not going to buy new expensive hardware just to run Darwin with no GUI. OSX without Aqua sucks. I've tried it. Darwin sans Aqua is like a crippled FreeBSD with far less apps. What I learned is that "The Apple Experience *IS* Aqua". Which is why Apple will NEVER open their Aqua code. So they're out for our company. Nothing I can do.

                I just hope the Linux guys really buff up the X-Windowing System to an Aqua-like sheen, polish, consistency, and ease of use. And STOP THE DUPLICATION OF EFFORT, GUYS!!!

                BlackBolt
                • You might want to try Oroborus they have an Aqua theme. It ain't OSX but if you love Aqua and have to use X... The target audience is more OSX users who need to run some X apps rather than Unix users but still worth a look.

                • by Anonymous Coward
                  As much as I want to, the IT bosses won't let me bring in OSX at work because they can't see the code. If they can't see the code, they can't prove there's no backdoors in it to their bosses.

                  You work for dumbasses.

                  You can see all of the OS code of OS X. The only think hidden is the UI. Only a complete ignoramous would worry about "back doors" in a desktop UI.

                  As for proving it to their bosses, show them the OS code, and how would those bosses know they are not looking at the Aqua code, as well?

                  I just hope the Linux guys really buff up the X-Windowing System to an Aqua-like sheen, polish, consistency, and ease of use. And STOP THE DUPLICATION OF EFFORT, GUYS!!!

                  This is exactly why I have all but given up on taking most Linux users seriously. It seems like the Linux world is now dominated by people who think of Linux as a commercial app, and if there is a feature that they feel it lacks, then somebody "out there" should make it happen for them. Look, if you are not willing to build the tools you need, then what the fuck are you bothering with Open Source for in the first place? There are people working on it, why are you not working with them, instead of bitching from the sidelines? Given your attitude, your company might as well spend the money on XP, and let somebody else take care of everything for them. While they're at it, outsource an MS "Strategic Partner" to handle all of the support & security issues, and get some India-based code shop to handle all of the programming. Then they can fire you and your dumbass boss, and get on with their business.

                  • 1. In the Windows directory, go to Application Data\Microsoft\WELCOME.

                    2. Create a shortcut for the file WELDATA.EXE by right-clicking the file and selecting Create Shortcut.

                    3. Right-click the newly created shortcut and select Properties.

                    4. In the shortcut tab, add the following at the end of the Target edit box: You_are_a_real_rascal. This causes the application WELDATA.EXE to be called with the argument You_are_a_real_rascal .

                    The Target edit box should have the following:
                    C:\WINDOWS\Application\Data\Microsoft\ WELCOME\WELD ATA.EXE" You_are_a_real_rascal

                    5. In the Run combo box, select Minimized.

                    6. Click OK, double-click the shortcut, and enjoy!

                    If an operating system can get shipped with these hidden features embedded within the code that no one knew about (including testing and quality control), what other back doors exist? People now publicize easter eggs because they are fun, but if a developer put a back door in an operating system so he could get back in whenever he wanted, do you think he would publicize it? Probably not. Just remember, a network is only as secure as its weakest link, and because you do not have source code to validate commercial software, that very well could be your weakest link that an attacker uses to compromise your system. This example is for Windows98, but the Mac has Easter Eggs as well. Go to www.eeggs.com to see for yourself.

                    Unless the code is 100% open, any openness is futile because malicious code can be hidden elsewhere. Security is nothing to take lightly, especially in a corporate setting. And you recommend lying to your bosses and you get modded up to "insightful"? Incredible bias on the part of the Maccie mods here. Just incredible. You would lie to get your chosen OS into an office? I am ashamed of both you and the astroturfing mods here. Maybe Mac users ARE a cult.
              • by jcr (53032)
                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
                • by jbolden (176878)
                  > 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).

                  • by Anonymous Coward
                    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.

                    That's where you're wrong. Aqua can work fine on other platforms, it just hasn't been released for them, and since Apple's not sharing the source of Aqua, a competitor would need to reverse-engineer Aqua to make that happen. However, if Apple suddenly wanted to move to a totally new hardware platform, moving Aqua would be trivial, becuase it is not as married to the hardware as you seem to think it is.


                  • 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 [arstechnica.com] and Planet PDF. [216.239.37.100] 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.
                • 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.

                  So, until that "volume leader" ports to anything else than its own hardware, that point is kinda moot, isn't it?

              • Well, let's see... three out of five of those points apply to Windows, a fourth applied to Windows XP on launch... I guess Windows isn't the standard desktop interface on PCs.
    • by goon america (536413) on Tuesday November 26, 2002 @12:05PM (#4759228) Homepage Journal
      iTunes is really just a fancy organizer for Quicktime. The Quicktime libraries are so big, and so useful that any multimedia app for the Mac uses them for everything.

      The Windows Media Player for OS 9 was "powered by Quicktime", hilariously enough.

    • There are other players - a quick hunt for mp3 players at www.versiontracker.com shows up a good variety of ones which work, and fill various niches, however iTunes is one of those apps that's a well put-together mix of dead-simplicity and good functionality.

      xmms runs under OSX - but requires an XFree86 to display anything. mpg123 also runs, and runs well as a pure player.

      If a scripting addition to iTunes gives access to playlists and the organisation someone already has in place, I can see that being very useful.
    • --unless I'm mistaken, the guys who developed the itunes are the past developers of soundjam, the best, IMO, audio media player for classic mac. They folded and went to work for apple. I still use soundjam for inet radio on my old mac, much better than anything else I have used, including various quicktimes. I've tried them back to back on the same MP3 stream, no comparison.

      Don't have a newer mac so don't run osx and don't have an ipod so can't comment on any of those, but if it really IS the soundjam guys I imagine it's a superior product going by their past success.
      • --unless I'm mistaken, the guys who developed the itunes are the past developers of soundjam, the best, IMO, audio media player for classic mac. They folded and went to work for apple.

        They didn't fold, Apple bought them.

        -jcr
  • by djupedal (584558) on Tuesday November 26, 2002 @11:41AM (#4759025)
    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 [no-ip.org] 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 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 [subsume.com], and even that is questionable if you survey your surroundings when the song is over. :-)

    • by kalidasa (577403) on Tuesday November 26, 2002 @02:39PM (#4760594) Journal
      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.
    • by WatertonMan (550706) on Tuesday November 26, 2002 @06:32PM (#4762895)
      Just out of curiousity, how do these Perl scripts work if there is no user currently logged into OSX? After all iTunes works in a user mode. If you call the Perl script and no user is logged in, will it work?

      If this is the same code that was discussed over at O'Reilly [macdevcenter.com] you need to start tweaking how Apache or other things run.

      There was a discussion of this over at MacNN Forums as well [macnn.com].

      • PERL is not talking to iTunes. AppleScript handles that. All in all, a less than earth shattering event.
        • You miss the point. Applescript works with the Window Manager running which runs as a user. The problem is that if no one has logged in then iTunes can't run and the Perl script won't work. If you are running your Perl scripts from Apache this can cause problems. Further if you try to make it more robust you open up all sorts of security holes.

          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?

        • 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 [cpan.org] distribution. I am so gonna have fun with this when it is released ...
  • by eht (8912) on Tuesday November 26, 2002 @12:21PM (#4759344)
    the subject pretty much covers it completely
  • Remote? (Score:4, Funny)

    by Trusty Penfold (615679) <jon_edwards@spanners4us.com> on Tuesday November 26, 2002 @12:23PM (#4759351) Journal

    Controlling music remotely is only useful when there is a function to turn the volume to 11.
  • by flashz (55340)
    I've been waiting for this! It's great, but I hope to see some improvment those modules still have alot of modules! /S

A committee is a group that keeps the minutes and loses hours. -- Milton Berle

Working...