While some applets and all apps from this site have a menu command to "Check for Update...", many AppleScripts do not. To make it easier to check if a script you downloaded at one time or another has a newer version available, use Doug's Check For Update. Just drop an AppleScript file on it (or launch it and use an Open Panel to navigate to a specific script) and it will check the website for the latest version of that script:
Sure, it'd be great if I could include a Sparkle-like mechanism to automatically check and install updates—as my apps do. But the code required to do so would just add too much overhead to a—very likely—simple AppleScript.
More information and download is here.
Kirk lists ten things iTunes does right at Macworld.
I'm very partial to #10.
"Do you have any scripts that work with iCloud Music Library/iTunes Match tracks? Like, to delete the cloud uploads and re-upload tracks?"
No. AppleScript cannot access anything in the cloud. Here's one of the reasons why: While it's certainly possible for me to write a script that arbitrarily deleted local tracks and files on your computer (with or without your knowledge), that's OK because presumably you knew stuff was going to get deleted by running the script. It's your responsibility, and Apple doesn't care what you do on your machine. You could set in on fire if that's what you wanted to do. Or install Flash. However, stuff in the cloud is Apple's responsibility. And they have pretty much guaranteed you that your goods up there are safe. So they're not going to let an AppleScript (of all things!) have arbitrary access to your goods in the cloud where it could potentially be a bad actor.
AppleScript can manipulate cloud tracks locally; for instance, copy such tracks to a new playlist or edit their tags. But anything to do directly with the cloud is strictly out-of-bounds.
I have already noted the new loved properties for tracks and playlists. I must admit that an update to the iTunes sdef was heartening (pun not much intended). However, there are some lingering issues and new issues with the latest incarnation of iTunes. Perhaps they have yet to be got to. Yeah, that's it. They'll fix it, fingers crossed.
Pretty much anything to do with the Apple Music tabs is off limits to AppleScript. So, for example, you can't select a track or playlist in "For You" and get info about it or manipulate it. I don't mind this so much. Once tracks are added to "My Music", they are accessible as shared tracks. It'd been the same with iTunes Match tracks. You can get and set the conventional track properties, you just can't access file metadata because, by definition, there are no local files for tracks in the cloud. Still, access to tracks and playlists in "For You" and "New" might be convenient, if even for accessibility purposes.
I am disappointed that current track does not work with playing Apple Music tracks (if playing from within the "For You" tab). I'm not sure if there's a security issue here, or it's just not hooked up yet. Definetly screws up anything watching for current track to change. Notifications is aware of playing Apple Music tracks, so why not AppleScript? Even as read-only. I'd be cool with that.
The new Playlist view doesn't seem quite hooked-up yet either. This is the new default view for local playlists. Anyone who's ever worked with broadcast automation will note that the abridged track information in Playlist view is reminiscent of a music log. (Note to Apple: please let us change this default view. As much as I really like the Playlist view I prefer Songs view as default to work with track tagging and only switch to Playlist view on formal occasions.) AppleScript-wise, it's all OK. But the reason I don't think it's hooked-up properly yet is by observing the pasteboard data from a playlist in Playlist view. Now, pasteboard data for dragged tracks and playlists typically contain metadata about the playlist and tracks being dragged. Except when the drag originates from a local playlist in Playlist view. In such cases, only the file paths are available in the pasteboard. And if cloud tracks are included in the drag, well, they don't have local files, so nothing about them at all appears in the pasteboard. However, when the very same playlist is in Songs view, the metadata is available from the dragged tracks' pasteboard as expected. So the data is already permissibly available, just not (yet?) in Playlist view. I suspect that, because it seems to be the same view used in "For You" when you play a playlist there, it has no provision for includiing metadata. Someone should get on that.
Also, there's no AppleScript way to access the artwork(s) or description that is a part of the new playlist header. It would be convenient to be able to script a playlist's description at least.
Many of my scripts and apps access the iTunes Library.xml file to get information about tracks and playlists. That's what it's there for. iTunes 12.2 has, uhm, mucked around with the format of this file. As a result, there's been a big scramble by all of us who develop iTunes apps to re-jigger our stuff. The XML now contains information about mobile apps, Ringtones, iTunes LP, iTunes Extras, and books. The "Master" playlist has a name of "####!####" where it used to be "Library". "Smart Info" and "Smart Criteria" keys are now being used with playlists other than the Smart variety. Additionally, there is now no way to tell the difference between Genius and Smart playlists; they look identical in the XML. Previously, a Genius playlist would key the persistent ID of its seed track and this would be a differentiating factor. But the "Genius Track ID" key is gone.
The new "Share iTunes Library XML with other applications" Preference setting is still a mystery to me, but I suppose there could be situations whereby you'd want this off. Sometimes I'm just plain dumb about things like that. But because some users think it looks like the perfect thing to uncheck I've needed to include a check for access to the XML at the start of many apps. Because if it's off, the script or app won't work.
On the bright-side though, despite the Apple Music considerations, iTunes still has pretty robust AppleScript support! So thanks for that, Apple.
Chuck Joiner invited me to join him on his MacVoices podcast. We talk about iTunes and AppleScript (of course) and obsessive-compulsive music organization, among other topics.
While losing iWorks AppleScript support is anxiety-inducing, some great new features have been added to AppleScript in Mavericks that are pretty exciting. I've played a little with libraries and Notifications in the DPs, but haven't incorporated anything into my scripts since
most a few of these features are not backwards-compatible on earlier operating systems.
Don Southard has a good article at MacStories outlining the latest stuff.
Apple has effectively killed AppleScript support in its latest versions of the iWorks apps. Probably not a surprise but a shock just the same. It's not a surprise because AppleScript support in Pages.app et al has never been very glamorous. But I don't have any doubts that the main consideration is the big part the iWorks apps play in Apple's iCloud/iCloud.com stategy and the security ramifications thereof. Anything that touches iCloud is pretty much hands-off to AppleScript.
Still, it's hard to sit helpless and watch AppleScript's maddeningly sad and frustrating march to irrelevance as iOS usage inevitably overtakes OS X.
Inter-app automation on iOS. Now that would cheer me up. There's hope, right?
With OS X 10.9 Apple takes security more seriously than it ever has. In this regard, Apple has added an additional level of security for apps that access the Accessibility API via "System Events". Here's how that new level of security may affect the way you use some AppleScripts downloaded from this site.
First of all: Some of my script applets (the ones with user interfaces) cannot run effectively while iTunes is in full screen mode. This is because only one of them, iTunes or the script, can be frontmost. So, when these scripts are launched they will detect and alert you if iTunes is in full screen mode.
To do this the script targets "System Events" to check for an accessibility property of the iTunes user interface indicating whether or not full screen is on. "System Events" is in the purview of Accessibility. If you've ever used GUI Scriptingto script key codes for exampleyou've had to set "Enable access for assistive devices" in the Accessibility pane of System Preferences. Well, as of OS X 10.9, this is no longer a global setting and must be set on a per-app basis.
There's seems to be a bit of inconsistency with the way iTunes 11 displays playlist time information as DD:HH:MM:SS. Sometimes times are displayed in the Status Bar at the bottom and sometimes a decimal version will be displayed beneath the playlist's name at the top of the browser. I can't quite get a grasp on something like "7.6 days" though.
Here's a script you can attach a shortcut to that will simply display a dialog box listing the name of the selected playlist, the number of tracks it contains, and the time of the playlist as DD:HH:MM:SS:
As I mentioned below, I had to fix a script to workaround a problem playing a playlist when only one track had as yet been copied to it, which prevented the rest of the subsequently added tracks from being recognized by MiniPlayer and Up Next; thus, only the first track would play. Similarly, if you were to play (the AppleScript command) any track in a playlist, the following tracks will not play because they haven't been recognized by MiniPlayer and Up Next ("No upcoming songs").
Doesn't go good when Mini Player is empty:
You can play the playlist and everything's OK. You just can't initiate play of the entire playlist by playing one of its tracks with AppleScript.
Goes good and loads in MiniPlayer:
Additionally, I found that if the MiniPlayer was already loaded up with tracks, playing a track (via AppleScript) from anywhere would play that track and then resume with whatever is next in MiniPlayer.