scripting iTunes 11 Up Next

Dear Lazyweb, how do I fake a click on this dingus using Applescript or Automator?

When I try to record an Automator action for it, it records "Click the "<fill in title>" button" and doesn't work.

(That button is the undocumented and apparently nameless magic thingy that makes Up Next use the selected playlist as its random source, which is the closest you can get to reproducing iTunes DJ in iTunes 11 -- but pretty much if you ever click anywhere else ever, it forgets about it. So I want to write a script to put it back to normal more quickly.)

Tags: , , , ,

9 Responses:

  1. anonymous says:

    $tags[2] =~ tr/yz/zy/;

  2. Jacob says:

    You can do this using with AppleScript, albeit in an incredibly fragile and verbose way. Try running this in AppleScript Editor:

    tell application "iTunes" to activate
    tell application "System Events" to tell last splitter group of first window of application process "iTunes"
    click (first button whose description is "shuffle")
    end tell

    Because Apple hates you, this will probably break with exciting unpredictable results someday. On that day, you should use the Accessibility Inspector tool (part of XCode) to inspect the new view hierarchy, and adjust the script to match.

    • jwz says:

      Thanks! Though it seems to fail at random some times. For the record, the full script in ~/Library/Scripts/ is:

      tell application "iTunes"
        set visible of browser window 1 to true
        set view of front window to playlist "75% Recent, 25% Library"
        tell application "System Events" to tell last splitter group of first window of application process "iTunes"
          click (first button whose description is "shuffle")
        end tell
        set visible of browser window 1 to false
      end tell

      • Jacob says:

        This article suggests that a delay between the window being active and the rest of the script (particularly the System Events stuff) will randomly fail, and to insert a delay (i.e. delay 1) to let the app catch up before moving to the next time.

        If that doesn't work…no idea. I happened to be automating a similar annoying issue with the Wacom tablet driver preference pane this morning, and I've ended up just adding delays all over the place and not thinking too much about how ugly that is.

  3. Nate says:

    Instead of delay, you can also poll reading the value of a widget until it doesn't error out.

  4. Perry says:

    Just a side question -- why has no enterprising person yet created a language that hooks into the same stuff that Applescript hooks into in the API but isn't totally gross in both syntax and semantics?

    • jwz says:

      It's actually fairly painless from Objective C: Scripting Bridge. I use that in jwzlyrics. There are bindings for it for other languages too, but I haven't used them. Well, I tried Mac::AppleScript::Glue for a minute but it seemed like more of a pain in the ass than it was worth.

      Of course all of them still have completely incomprehensible trial-and-error performance characteristics, because the underlying AppleEvents architecture is still insane.

      • Perry says:

        Yuck. I hadn't realized the suck was fractal and encompassed not only the bizarre and incomprehensible syntax but also the underlying architecture. :(

        Still, I might try playing with the stuff from the Objective C side. It at least gets rid of the language. Applescript's syntax is worse than Cobol.