Identifying a volume as being an iPod

[John Joyce]

Does anybody know how to identify a mounted volume as being an iPod ?
Or even more generally useful, is there a lib or gem to help identify
the type of volume or disk ?

I'm currently working on a prog to help transfer songs from your iPod
to an authorized iTunes account.
iTunes itself makes it easy to transfer "purchased songs", that is,
songs that are identified as purchased through iTunes, but fails to
offer an easy method to transfer songs that you did not buy through
iTunes, such as tracks you ripped from a CD.

Opening the directories that hold the music on an iPod is dead
simple, even opening them as Finder windows on OS X, but the two
areas that are stopping me know are:
1-- making an automated identification of the iPod
2-- actually moving the songs to the iTunes library.

The second one is something I'm currently learning AppleScript in
order to make it feasible, perhaps with the rubyOSA gem.
Ideally, I would like to make it cross platform, but I don't have any
Windows, so it would be up to somebody else to add that later.

 

[Tiago Macedo]

An iPod (at least when formatted in FAT32 will contain an "iPod_Control"
folder on the root.

You can also check the USB device ids:
Bus 005 Device 003: ID 05ac:1261 Apple Computer, Inc.
(this is an 80GB Classic Silver)

or just build a wrapper for libgpod (I don't it supports drm'ed tracks
though)

Tiago Macedo

 

[John Joyce]

An iPod (at least when formatted in FAT32 will contain an
"iPod_Control" folder on the root.

You can also check the USB device ids:
Bus 005 Device 003: ID 05ac:1261 Apple Computer, Inc.
(this is an 80GB Classic Silver)

or just build a wrapper for libgpod (I don't it supports drm'ed
tracks though)

Tiago Macedo

The device ID info is in the right vein for what I'm thinking of.
I know about the "iPod_Control" folder.
It's on every iPod, inside it is the Music folder and that contains
the directories that actually hold the audio files.
I'm just curious, but I'll look into the way the system recognizes
the iPod... there must be some simple trick to go, ok this is an iPod
and not some other device.

 

[MonkeeSage]

The device ID info is in the right vein for what I'm thinking of.
I know about the "iPod_Control" folder.
It's on every iPod, inside it is the Music folder and that contains
the directories that actually hold the audio files.
I'm just curious, but I'll look into the way the system recognizes
the iPod... there must be some simple trick to go, ok this is an iPod
and not some other device.

On my system (linux, 2.6.22 kernel), this turns up some interesting
results...

$ sudo grep -R -i ipod /usr/src/linux/*

....particularly, the following files look like they have some stuff
for identifying ipod devices...

/usr/src/linux/drivers/ieee1394/sbp2.c
/usr/src/linux/drivers/usb/storage/unusual_devs.h

Regards,
Jordan

 

[John Joyce]

On my system (linux, 2.6.22 kernel), this turns up some interesting
results...

$ sudo grep -R -i ipod /usr/src/linux/*

...particularly, the following files look like they have some stuff
for identifying ipod devices...

/usr/src/linux/drivers/ieee1394/sbp2.c
/usr/src/linux/drivers/usb/storage/unusual_devs.h

Regards,
Jordan

Interesting, ieee1394 is FireWire, but iPods haven't shipped with
that in quite some time.
none the less, if you look in there and happen to see anything
interesting, let me know please!
I don't currently have a Linux system running, even it requires
better hardware than my current crop of old hardware...

 

[Giles Bowkett]

Opening the directories that hold the music on an iPod is dead

simple, even opening them as Finder windows on OS X, but the two
areas that are stopping me know are:
1-- making an automated identification of the iPod
2-- actually moving the songs to the iTunes library.

The iTunes library has an XML component and a binary component. The
XML part is just a dumb-as-nails XML file. I think I once edited it by
hand because iTunes was pissing me off and I wanted it to know who was
boss. Anyway, IIRC, iTunes didn't explode as a result. I don't know
what the binary component is but if my fuzzy memory is working
properly you can just change the XML and the program will deal.

However, I thought moving files off the iPod was impossible.

Oh wow, that's cool. You can just go in there in Term, or Path Finder.
I don't use Finder, but presumably you can get in that way too. Very
cool. Now I can archive all the stuff I bought on my old computer.
Weird how the files get renamed, though. Are they supposed to all have
names like F47/ENNS.mp3?

The second one is something I'm currently learning AppleScript in
order to make it feasible, perhaps with the rubyOSA gem.
Ideally, I would like to make it cross platform, but I don't have any
Windows, so it would be up to somebody else to add that later.

I think you can just do it with Builder in Ruby. I did a little
googling and the impression I got was that the binary and XML
components are exact duplicates, and that when iTunes finds the binary
version is corrupted, it uses the XML as a backup. So you could just
add the files in the XML, nuke the binary, and iTunes would
automatically go to the XML to stay up to date.

By the way, if you want to find out what the files in
iPod_Control/iTunes do, don't run cat against them, some of them are
quite large and others will make your Terminal beep at you.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[Giles Bowkett]

If you speak Perl there are some pretty wiggy-looking Perl libraries for it:

http://search.cpan.org/search?query=iPod&mode=all

What's really odd is that most of them seem to involve SQL.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[John Joyce]

If you speak Perl there are some pretty wiggy-looking Perl
libraries for it:

http://search.cpan.org/search?query=iPod&mode=all

What's really odd is that most of them seem to involve SQL.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

Sweet, I don't speak Perl, but when it's readable I can read it
enough to get what I need.

But yeah, you can go into /Volumes/ipod_name/iPod_Control/Music/
and there you find some cryptically named directories that contain
your audio files.
The names of tracks are stored internally in the files themselves.

just open each directory with the OS X terminal command open, then
drag the songs to the iTunes library in the iTunes app window.
Sometimes the tracks will not get their names as they should and
retain those cryptic names in iTunes.
I've yet to determine why but I supsect either for larger libraries,
it steps on itself during the transfer, or files that are not the
native iTunes format might not contain the track info internally.

Anyway, this is my little project to help me and my coworkers enjoy
our own music at work.
I've discovered that OS X has an IORegistry that holds xml of
connected devices, iPods make themselves pretty obviously iPods in
that IORegistry, but I don't yet know how to access the IORegistry to
check connected iPods and their names.
I want to make it so that the user can confirm that the proper iPod
is being accessed, then transfer the songs.

appleScript is currently on the menu for adding the files to the
iTunes library. The library's xml files are just too ugly for me.
I don't really want to dig in to how they are structured or ordered.
This gives me the impetus to finally learn appleScript and then I can
use rubyOSA...
but if you have some deeper insights into iTunes' xml then maybe we
can add that to it.
I suspect using the appleScript GUI scripting approach will be faster
than Ruby xml writing.

If this is nailed down well enough it should be cake for somebody
else to do the windows version of the program.

 

[John Joyce]

Well, I've found better stuff to work with, more practical anyway.

in:
/Volumes/ipod_name_here/iPod_Control/Device/
there is a nifty little file called SysInfo

I wouldn't dare modify it, but it is worth reading. In fact, I would
almost recommend creating read-only method to wrap whatever methods
you want to use to open and read the thing. Just to avoid any chance
of stepping on this file.
I have replaced my serial number with a five asterisks. You only need
the first 3 characters of a serial number on the ipod to identify it.
The most important line is line 3, the model number.
You could, if you were diligent, check to see that the first 3 chars
of the serial number match the model number for the type of iPod.
If you were overly diligent, you could try to check the serial number
against Apple's web site somewhere.

Anyway, let's just say we've got more than enough to say the device
is probably an iPod and is likely the one you want to transfer music
from to an authorized iTunes. The odds of having multiple iPods
connected to one computer are pretty low. It happens, but not much.
That's no big deal, we just have to add a check to ask the user
running the program which iPod they want to transfer from, since the
name of the iPod is the same name in the terminal.

Now all we need to do is script the Finder to move the files into
iTunes!
After I finish learning just enough AppleScript, I will convert it to
RubyOSA...

The file reads thus:

BoardHwName: iPod M26
pszSerialNumber: 5U5*****TK2
ModelNumStr: MA107
FirewireGuid: 0x000A270012AE3CCB
HddFirmwareRev: ADBA41KB
RegionCode: J(0x0002)
PolicyFlags: 0x00000000
buildID: 0x05118000 (5.1.1)
visibleBuildID: 0x01118000 (1.1.1)
boardHwRev: 0x00000000 (0.0 0)
boardHwSwInterfaceRev: 0x000C0005 (0.0.12 5)
bootLoaderImageRev: 0x00000000 (0.0 0)
diskModeImageRev: 0x00000000 (0.0 0)
diagImageRev: 0x00000000 (0.0 0)
osImageRev: 0x00000000 (0.0 0)
iPodFamily: 0x00000000
updaterFamily: 0x00000000

 

[Giles Bowkett]

it steps on itself during the transfer, or files that are not the

native iTunes format might not contain the track info internally.

I can definitely contradict this. I pulled an .mp3 off one of my iPods
and although it had an iPod filename it knew what the song was called.
mp3s have a system for metadata, I think they're called ID3 tags but
don't quote me on that. I think Apple's proprietary format also uses
this same system for metadata. so when you pull in songs from an iPod
it just goes to the metadata in most cases. of course it's possible to
create mp3s without metadata, which is very likely what you're seeing
if it goes to the weird filename rather than the name of the song,
especially if you're only seeing it on mp3s but not AACs.

Anyway, seems like a nifty project, announce if you release it, sounds
like it'd be fun to play with.

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[MonkeeSage]

Interesting, ieee1394 is FireWire, but iPods haven't shipped with
that in quite some time.
none the less, if you look in there and happen to see anything
interesting, let me know please!
I don't currently have a Linux system running, even it requires
better hardware than my current crop of old hardware...

Interesting bits...

==snip==

/* iPod 4th generation */ {
.firmware_revision = 0x0a2700,
.model_id = 0x000021,
.workarounds = SBP2_WORKAROUND_FIX_CAPACITY,
},
/* iPod mini */ {
.firmware_revision = 0x0a2700,
.model_id = 0x000023,
.workarounds = SBP2_WORKAROUND_FIX_CAPACITY,
},
/* iPod Photo */ {
.firmware_revision = 0x0a2700,
.model_id = 0x00007e,
.workarounds = SBP2_WORKAROUND_FIX_CAPACITY,
}

========

==snip==

/* Submitted by Sven Anderson <[email protected]>
* There are at least four ProductIDs used for iPods, so I added
0x1202 and
* 0x1204. They just need the US_FL_FIX_CAPACITY. As the bcdDevice
appears
* to change with firmware updates, I changed the range to maximum for
all
* iPod entries.
*/
UNUSUAL_DEV( 0x05ac, 0x1202, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),

/* Reported by Avi Kivity <[email protected]> */
UNUSUAL_DEV( 0x05ac, 0x1203, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),

UNUSUAL_DEV( 0x05ac, 0x1204, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY | US_FL_NOT_LOCKABLE ),

UNUSUAL_DEV( 0x05ac, 0x1205, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),

/*
* Reported by Tyson Vinson <[email protected]>
* This particular productId is the iPod Nano
*/
UNUSUAL_DEV( 0x05ac, 0x120a, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),

========

Don't ask me about what exactly all the code means, I just thought it
looked promising. Ps. You can browse and search the kernel source
online: http://lxr.linux.no/linux

Regards,
Jordan

 

[John Joyce]

I can definitely contradict this. I pulled an .mp3 off one of my iPods
and although it had an iPod filename it knew what the song was called.
mp3s have a system for metadata, I think they're called ID3 tags but
don't quote me on that. I think Apple's proprietary format also uses
this same system for metadata. so when you pull in songs from an iPod
it just goes to the metadata in most cases. of course it's possible to
create mp3s without metadata, which is very likely what you're seeing
if it goes to the weird filename rather than the name of the song,
especially if you're only seeing it on mp3s but not AACs.

Anyway, seems like a nifty project, announce if you release it, sounds
like it'd be fun to play with.

No contradiction there, I said "might not contain track info
internally" ...
Some mp3 files (most really) have id3 tags properly filled in.
Other formats handled by iTunes might only have their metadata in the
iTunes library xml files.
For example aif or aiff files. These were some of my suspects.
I don't know how iTunes checks audio files, but you can bet it
doesn't care much about the file name.
Oddly enough though, it seems that the file name tweaking occurs
during the transfer to iPods, a little obfuscation to slow down
hacking the things.

 

[John Joyce]

Interesting bits...

==snip==

/* iPod 4th generation */ {
.firmware_revision = 0x0a2700,
.model_id = 0x000021,
.workarounds = SBP2_WORKAROUND_FIX_CAPACITY,
},
/* iPod mini */ {
.firmware_revision = 0x0a2700,
.model_id = 0x000023,
.workarounds = SBP2_WORKAROUND_FIX_CAPACITY,
},
/* iPod Photo */ {
.firmware_revision = 0x0a2700,
.model_id = 0x00007e,
.workarounds = SBP2_WORKAROUND_FIX_CAPACITY,
}

========

==snip==

/* Submitted by Sven Anderson <[email protected]>
* There are at least four ProductIDs used for iPods, so I added
0x1202 and
* 0x1204. They just need the US_FL_FIX_CAPACITY. As the bcdDevice
appears
* to change with firmware updates, I changed the range to maximum for
all
* iPod entries.
*/
UNUSUAL_DEV( 0x05ac, 0x1202, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),

/* Reported by Avi Kivity <[email protected]> */
UNUSUAL_DEV( 0x05ac, 0x1203, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),

UNUSUAL_DEV( 0x05ac, 0x1204, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY | US_FL_NOT_LOCKABLE ),

UNUSUAL_DEV( 0x05ac, 0x1205, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),

/*
* Reported by Tyson Vinson <[email protected]>
* This particular productId is the iPod Nano
*/
UNUSUAL_DEV( 0x05ac, 0x120a, 0x0000, 0x9999,
"Apple",
"iPod",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),

========

Don't ask me about what exactly all the code means, I just thought it
looked promising. Ps. You can browse and search the kernel source
online: http://lxr.linux.no/linux

Regards,
Jordan

Thanks! I know, it's intentionally cryptic.

 

[Giles Bowkett]

For example aif or aiff files. These were some of my suspects.

Ahhhh. I get it.

I don't know how iTunes checks audio files, but you can bet it
doesn't care much about the file name.
Oddly enough though, it seems that the file name tweaking occurs
during the transfer to iPods, a little obfuscation to slow down
hacking the things.

That means if you have an id3-tag reader (either command-line or
Ruby), you can process the most common use case entirely in Ruby.

(I'm averse to learning AppleScript but otherwise interested in this
kind of hacking, so that's very good news in my book.)

--
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[John Joyce]

Ahhhh. I get it.


That means if you have an id3-tag reader (either command-line or
Ruby), you can process the most common use case entirely in Ruby.

(I'm averse to learning AppleScript but otherwise interested in this
kind of hacking, so that's very good news in my book.)

After spending some time with AppleScript for a day or two now in my
spare time, let me assure you:
aversion is good. AppleScript is an old dog and it shows. Limitations
galore.
There are a lot of powerful little hooks in it, but it's hardly worth
the effort to reach the level of using them.
Turns out GUI scripting still requires a user to turn on this feature
manually. Unless somebody knows what to send to the tool
defaults write <something here>
If somebody already could tell me, I could write that into the Ruby
portion as a backtick command in the beginning and in the end clean
up to turn it off again (if it wasn't on before).

Worst thing is that AppleScript can launch a process but can't get
output from that process, not directly anyway.
It requires use of intermediary file writing and subsequent reading.

I've got enough now to where the only thing I have to figure out is
how to leverage Applescript for the GUI scripting of adding files to
the library. The concept is simple, but I'm working on the learning
the mechanism now.

 

[Giles Bowkett]

After spending some time with AppleScript for a day or two now in my

spare time, let me assure you:
aversion is good. AppleScript is an old dog and it shows. Limitations
galore.

You're not the only one having that experience. I've seen it elsewhere
- hence the aversion.

I think this is one reason Apple's getting behind Ruby w/RubyCocoa,
etc. I could be wrong, though.

http://developer.apple.com/scriptingautomation/overview.html

"Scripting Bridge, new in Leopard, brings advanced automation to the
desktop, making it easy to send Apple Events=97the built-in messaging
architecture of Mac OS X=97between applications, allowing you to
leverage the features of rich desktop applications from your own code.
The best part is that your code can be in the language you want,
whether Objective-C (with Scripting Bridge), Python (with PyObjC),
Ruby (with RubyCocoa), or pure AppleScript."

I read somewhere or got the impression somehow that the whole plan
here was to leverage the power they built into AppleScript but allow
people to use languages they actually *enjoy* using, so Apple could
stop sinking money into AppleScript and instead leverage the hackery
and energy of the open source communities around Python and Ruby (and
others).

Wow. There's a bunch of libraries; check this out. I did

sudo port install id3lib ; sudo gem install id3lib-ruby

And then created a symlink because the apostrophe in my iPod's name
was confusing Ruby somehow.

ln -s /Volumes/Giles's\ iPod/iPod_Control/Music/F01/TSGI.mp3 path_to_ipod_m=
p3

And then:
=3D> "General Midi"

This means that for the simplest scenarios, copying stuff off an iPod
and giving each file an appropriate name is downright effortless.
That's really, really cool - I have an iPod synched to an old machine
that I figured I'd have to keep forever unless I felt like giving up
all the content on it. Not a problem any longer. I could fit the whole
thing in the spare capacity on my newer iPod (since virtually
everything on there was done in good old-fashioned mp3 format).

w00t w00t

--=20
Giles Bowkett

Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com

 

[John Joyce]

You're not the only one having that experience. I've seen it elsewhere
- hence the aversion.

I think this is one reason Apple's getting behind Ruby w/RubyCocoa,
etc. I could be wrong, though.

http://developer.apple.com/scriptingautomation/overview.html

"Scripting Bridge, new in Leopard, brings advanced automation to the
desktop, making it easy to send Apple Events=97the built-in messaging
architecture of Mac OS X=97between applications, allowing you to
leverage the features of rich desktop applications from your own code.
The best part is that your code can be in the language you want,
whether Objective-C (with Scripting Bridge), Python (with PyObjC),
Ruby (with RubyCocoa), or pure AppleScript."

I read somewhere or got the impression somehow that the whole plan
here was to leverage the power they built into AppleScript but allow
people to use languages they actually *enjoy* using, so Apple could
stop sinking money into AppleScript and instead leverage the hackery
and energy of the open source communities around Python and Ruby (and
others).

Wow. There's a bunch of libraries; check this out. I did

sudo port install id3lib ; sudo gem install id3lib-ruby

And then created a symlink because the apostrophe in my iPod's name
was confusing Ruby somehow.

ln -s /Volumes/Giles's\ iPod/iPod_Control/Music/F01/TSGI.mp3 =20
path_to_ipod_mp3

And then:

=3D> "General Midi"

This means that for the simplest scenarios, copying stuff off an iPod
and giving each file an appropriate name is downright effortless.
That's really, really cool - I have an iPod synched to an old machine
that I figured I'd have to keep forever unless I felt like giving up
all the content on it. Not a problem any longer. I could fit the whole
thing in the spare capacity on my newer iPod (since virtually
everything on there was done in good old-fashioned mp3 format).

w00t w00t

--=20
Giles Bowkett

I too wonder if Apple is or isn't cooking up some kind of appleScript =20=

replacement.
Ruby would be wonderful candidate for it.
But maybe too wonderful...?
The trouble with Apple Events is that in order to really make use of =20
them, you have to know a lot of Cocoa stuff already.
It's not cake.
What's worse is, if the app in question doesn't make itself =20
scriptable, then it will only be scriptable the hard way.
Apple employs this themselves in limiting access to apps...

 

[has]

Does anybody know how to identify a mounted volume as being aniPod?
Or even more generally useful, is there a lib or gem to help identify
the type of volume or disk ?

I don't have an iPod myself, but doesn't iTunes list mounted CDs,
iPods, etc. automatically? In which case you should be able to get a
list of references to mounted iPods using something like this:

require 'appscript'
include Appscript

ITunes = app('iTunes')

p ITunes.sources[its.kind.eqiPod)].get

From there you should be able to refer to an iPods playlists and
tracks, copy them to iTunes' own playlist, etc.

HTH

has

 

[has]

After spending some time withAppleScriptfor a day or two now in my
spare time, let me assure you:
aversion is good.AppleScriptis an old dog and it shows. Limitations
galore.
There are a lot of powerful little hooks in it, but it's hardly worth
the effort to reach the level of using them.

The AppleScript language is largely crud, but the one thing it does do
extremely well is speak Apple events to other applications. Other
languages have been appallingly slow to catch up in this area; as a
result, most of the application-specific domain knowledge still lies
over in the AppleScript community.

Therefore, if you want to do any significant amount of application
automation work in any language, then realistically you'll need to get
at least a working understanding of AppleScript under your belt first.
(Yes it sucks; but if you ever want things to change then somebody's
gotta go first.) Learning the language will enable you to grok
existing AppleScripts for hints and solutions and phrase questions in
terms that experienced AppleScripters - who may not know much about
general programming, but know these applications scripting interfaces
like the backs of their hands - can understand and reply to.

The best book for existing developers to get up to speed on
AppleScript is Matt Neuburg's 'AppleScript: The Definitive Guide'
<http://www.oreilly.com/catalog/applescpttdg2/>. The language-specific
chapters you should be able to skim through; once you get past the
weird syntax, except for the Apple event stuff it's a rather ordinary,
minimally-featured imperative scripting language. The chapters on
application scripting should contain information applicable to all
languages, though will be phrased in AppleScript terms, of course
(hence the need to know the language itself in order to make sense of
everything else).

FWIW, Brian Marick ('Everyday Scripting with Ruby') is also planning
to write a book on Mac automation with Ruby (http://www.exampler.com/
blog/2007/11/27/scripting-your-mac-with-ruby/) which will include
material on using Ruby in place of AppleScript, although I don't
imagine it will be out until well into next year.

I've got enough now to where the only thing I have to figure out is
how to leverageApplescriptfor the GUI scripting of adding files to
the library. The concept is simple, but I'm working on the learning
the mechanism now.

I'm not an iTunes scripting guru, but I would think a fairly simple
sounding task like yours should be entirely doable via iTunes own
scripting interface. GUI Scripting is hackish and fragile, and best
avoided if at all possible.

Best place for asking application-specific questions would probably be
the AppleScript-users list (there are other places, but AS-users is
the most popular and contains a reasonable proportion of experienced
users):

http://lists.apple.com/mailman/listinfo/applescript-users

Curious folks, AppleScripters; they often seem to exist in a bubble
disconnected from the rest of the programming world, but are generally
eager to help. The quality of advice can vary, but I don't think
that's different to anywhere else.

Once you've found out the magic incantations to use - usually the
hardest part - you'll need to translate them from AppleScript to Ruby
syntax yourself. First thing obviously is to print out the iTunes
dictionary in Ruby format using the tools supplied with the Apple
event bridge you're using (e.g. for appscript use ASDictionary). If
you get stuck you can try posting them here - there's a few folks like
myself who have some experience using Ruby as an AppleScript
replacement, that may be able to help. Another extremely handy tool is
ASTranslate, which converts AppleScript commands to their Ruby
appscript equivalents - while it's not a full-blown code converter,
it's a great tool for helping to work out how to rephrase individual
application commands.

HTH

has

 

[has]

All the real functionality is at the OS API level (Apple events, OSA)
and in the applications that leverage these APIs to expose some or all
of their functionality to other programs. AppleScript is just one of
several client languages for these services (it wasn't even the first,
btw; UserTalk predates it).

As for Scripting Bridge, I'm rather disappointed with it myself: it
lacks several features found in AppleScript, is noticeably inferior on
the application compatibility front, parts of its API are badly
designed or basically unfinished, and the lack of native APIs on
Python and Ruby makes those languages feel like they're being treated
as second-class citizens in the AppleScript world. Still, that's why
there's appscript.

I too wonder if Apple is or isn't cooking up some kind of appleScript
replacement.
Ruby would be wonderful candidate for it.

I wouldn't mind seeing a full-blown OSA language component for Ruby
myself, which is what you really need to replace AppleScript 100% as
that'd let you use Ruby for tasks that require attachability (Mail
rules, folder actions, etc).

However, I believe Ruby's internal architecture makes this difficult
as it doesn't ensure that unrelated scripts hosted within the same
Ruby runtime are 100% isolated from one another. I've already run into
similar problems designing my PyOSA component, which is why it's still
not got past the 'developer preview' status after more than two years;
well, that, and I'm lazy. (One solution might be to host each Ruby
script as a separate subprocess, but the OSA wasn't really designed to
work that way so this is likely to cause other problems, not to
mention an inevitable performance hit.) Still, if anyone wants to
discuss this topic further, drop us an email.

But maybe too wonderful...?
The trouble with Apple Events is that in order to really make use of
them, you have to know a lot of Cocoa stuff already.

You don't have to know any Cocoa stuff to use Apple events; however,
you do have to know at least a bit about how Apple events work, and
quite a lot about how individual applications implement their Apple
event interfaces. The latter in particular are notoriously
underdocumented which can cause some real headaches when learning to
script a new application, requiring you to fall back on a mix of
intelligent guesswork, trial-and-error experimentation and shared
community knowledge to figure things out. Though hopefully as more
folks are introduced to application scripting via Python, Ruby, etc.,
application developers will start to take scripting interface
documentation and other issues more seriously.

HTH

has