Re: Play Playlist in iTunes
Re: Play Playlist in iTunes
- Subject: Re: Play Playlist in iTunes
- From: has <email@hidden>
- Date: Sat, 4 Oct 2008 10:26:58 +0100
On 4 Oct 2008, at 03:54, Mr. Gecko wrote:
I am not using AppleScript to do this, I am using AppleEvents, as
you can see in code below.
Aware of that. You'll often find that folks use the name "AppleScript"
as a catch-all term for anything relating to Apple event IPC. It's
easy to lapse into the habit; apologies if it caused any confusion.
Anyway, regardless of whether you use AppleScript or C to build and
send events, the underlying RPC+query semantics are the same as
they're defined by the Apple Event Manager and by the event handling
code in scriptable applications. The AppleScript language sticks a
thin layer of syntactic sugar [1] over the existing Apple Event
Manager API in order to make it easier to use, but the way it behaves
is virtually [2] identical.
This is way faster than using AppleScript.
It's the extra overhead of calling into the AS component that slows
things down, particularly if you're compiling from source each time.
There shouldn't actually be much speed difference between AppleScript
and other APIs where building and sending events is concerned; it's
the one area where AppleScript's performance is about as good as it
can be. AS, appscript and SB all seem to be about equal here; the
Carbon C API might be a little faster as it's closest to the metal,
but I doubt the difference is significant by the time you've packed
your Cocoa values into AEDescs and back.
BTW, regardless of what API you use, you can also speed up or slow
things down massively depending on the number of Apple events you use
to perform a given task. This can be particularly noticeable with
iTunes, since playlists can often run into thousands of tracks. Apple
event IPC traditionally optimises for fewer, more complex events over
many simple ones, so each event you send is relatively expensive but,
depending on the application, you can often perform multiple
operations in a single event. For example:
#import <Foundation/Foundation.h>
#import "ITGlue/ITGlue.h"
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
ITApplication *itunes = [ITApplication applicationWithBundleID:
@"com.apple.itunes"];
// This sends 3 Apple events:
NSDate *time1 = [NSDate date];
ITReference *tracksRef = [[[itunes playlists] byName: @"stress test"]
tracks];
NSArray *names = [[tracksRef name] getList];
NSArray *albums = [[tracksRef album] getList];
NSArray *artists = [[tracksRef artist] getList];
printf("time 1 = %.3f sec\n", -[time1 timeIntervalSinceNow]);
// This sends N * 3 + 1 Apple events (where N is the number of tracks
in the playlist):
NSDate *time2 = [NSDate date];
NSArray *tracksList = [[[[itunes playlists] byName: @"stress test"]
tracks] getList];
NSEnumerator *iterator = [tracksList objectEnumerator];
ITReference *track;
while (track = [iterator nextObject]) {
NSString *name = [[track name] getItem];
NSString *artist = [[track artist] getItem];
NSString *album = [[track album] getItem];
}
printf("time 2 = %.3f sec\n", -[time2 timeIntervalSinceNow]);
[pool drain];
return 0;
}
gives the following times for a 4000-track playlist:
time 1 = 0.137 sec
time 2 = 5.779 sec
and for a 40,000-track playlist:
time 1 = 2.116 sec
time 2 = 82.634 sec
I'm not sure which approach EyeTunes uses, but it's something to bear
in mind if performance is an issue for you.
I would prefer using AppleEvents because it is the right way to
communicate with different things in the os, using cocoa.
It's all Apple events under the hood. Some APIs just make them easier
to work with than others.
HTH
has
[1] Plus a few magical behaviours such as 'implicit gets' which do
unfortunately muddy comprehension a bit. But I won't claim that
AppleScript is a perfect pedagogical tool, just a convenient one.
[2] See [1].
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden