Apple Music Profile
YouTube Channel
RSS Feed
Dupin
Join Together
M3Unify
30 Most Recent RSS FeedAppleScript
iTunes 12.2 and AppleScript Issues, Volume 2
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.
MacVoices Podcast
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.
But There's Good AppleScript News, Too
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.
AppleScript Support Killed In Latest iWorks
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?
OS X 10.9: AppleScripts and Accessibility Control
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 Scripting—to script key codes for example—you'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.
Show Track Count and Time of Selected Playlist
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:
tell application "iTunes"
set thePlaylist to (get view of front browser window)
display dialog (get name of thePlaylist) & return & return & ¬
(get index of last track) & " tracks" & return & return & ¬
(get time of thePlaylist) buttons {"OK"} default button 1 giving up after 300
end tell
Interesting play Issue with MiniPlayer
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:
tell application "iTunes"
set aTrack to item 1 of selection
play aTrack
end tell
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:
tell application "iTunes"
set aPlaylist to view of front window
play aPlaylist
end tell
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.
iTunes 11 Loses playlist window
Technically, you can't open a playlist in its own window in iTunes 11, so the playlist window element is moot.
iTunes 11 Loses Gapless Track Feature
You can no longer designate an album of tracks as gapless. Thus, a track's gapless property is now moot.
ERRATA: My title for this post is misleading. The gapless feature has not been lost. But the ability to manually change a track's gapless setting has been removed.
iTunes 11 Released
Apple has released iTunes 11. Apple originally previewed iTunes 11 at its September Special Event, announced a vague October release date, and then later postponed release to November.
This updated version features some iOS-inspired GUI changes, re-designed MiniPlayer, improved iCloud integration, improved search, and a revamped design of the iTunes Store.
