I’m currently re-doing AutoRate in Objective-C. I’ve heard from a few users with very large libraries (20,000+) that the current version takes several hours to go through their entire library. Should be able to do much better than that in Obj-C instead of AppleScript.
Should give me more scope to do some other things as well, as I’m more comfortable with Obj-C than AppleScript. One feature I’m considering is live updating of ratings – AutoRate runs in the background and watches tracks that are played. That will yield the ability to form more accurate ratings, instead of having to use a couple of heuristics to ‘guess’.
So, stay tuned.
Related posts
- AutoRate 1.4.2 Edit: Please see the official AutoRate product page for the...
- AutoRate 1.4.1 Edit: Please see the official AutoRate product page for the latest version...
- AutoRate 1.5.0 beta After a long hiatus, it’s time for a new version...
- AutoRate 1.5.0 release Thanks to the efforts of Brandon Mol and a few...
- AutoRate in Japan’s Mac Fan Magazine AutoRate got a mention in the Japanese Mac Fan magazine!...



4 Comments
Regarding using ObjC in place of AppleScript, check out objc-appscript if you haven’t already done so:
However, don’t expect a straight translation from AS to ObjC to automatically provide vast performance improvements. While the AppleScript language certainly has its share of performance problems, Apple event IPC has various bottlenecks of its own which you need to be aware of.
Basically, there are two problems dealing with large data sets in AppleScript:
Alternatively, switching to another language (Python, Ruby, ObjC, etc.) lets you avoid that problem entirely.
Switching languages won’t help you here; your only option is to minimise the number of events you send wherever possible, e.g. sending a few more complex events:
tracks_ref = app('iTunes').playlists[1].tracks names = tracks_ref.name.get artists = tracks_ref.artist.get albums = tracks_ref.album.get names.zip(artists, albums).each do |name, artist, album| # do stuff here endis far, far more efficient than sending many simpler ones:
track_list = app('iTunes').playlists[1].tracks.get track_list.each do |track| name = track.name.get artist = track.artist.get album = track.album.get # do stuff here endThere are some notes about performance optimisation in the appscript documentation, and I think Matt Neuburg also discusses these issues in his AppleScript book.
HTH
has
http://appscript.sourceforge.net http://rb-appscript.rubyforge.org
Thanks for the great tips! I’ll check those things out – it’d be nice to reduce the bottleneck that is AS as much as possible.
This is great – Appscript is going to save so much time. I’m glad you mentioned it!
Great stuff! I say thnx and looking forward of the next release.