Indrio Development Begins: iTunes, COM & Python
Indrio is the name or a road not too far form here. Indrio is also the code name for a little project I’m working on to help me learn Python. It involves talking to iTunes, over COM. This is easier than it sounds. The iTunes SDK documentation is well written, well organized and easy to understand. It’s an easy API to work with, thats the good news.
The bad news is that some of the cool stuff that iTunes is doing in the UI is not available through the COM interface. Of particular interest to me was the Party Shuffle playlist. You can add tracks to it but only at the end i.e. No “Play Next in Party Shuffle†via COM. You can’t determine how many previously played tracks are showing (unless your actually playing that playlist and work it out from the currently playing track). You can’t set the playlist that feeds into the party shuffle or any of the other parameters. These things are not blockers for what I wanted to do but they would have made things much nicer for users.
Then there is fun with ID’s. The docs say that all objects in iTunes support four script friendly functions to return the Source, Playlist, Track & Database ID’s respectively. If you have a problem accessing these functions its because the Source, Playlist and Track functions are declared to start with common letters; sourceID(), playlistID(), trackID(). The database ID function is capitalized as per the docs: TrackDatabaseID(). Also of interest, Python can handle the multiple return values of GetITObjectIDs() by turning them into an array. Score one for Python! Score another one for the Python COM browser which helped me track down the capitalization bug.
iTunes.GetITObjectByID() doesn’t work if all you have is the Database ID, which makes knowing that basically useless. To make GetITObjectID() work you need to know all 4 parameters. That isn’t exactly congruent with the docs. Supplying 0 to any of the parameters throws some sort of error.
The final twist is with Python. It supplies base types when a function returns a derived type over COM. So you have to cast the return type to the type you expected. This had me stumped for a while until I saw this Simon Brunning’s code. win32com.client.CastTo() is the magic bullet that fixes this. I wish there was some good docs for the Python COM interface.
Stay tunes for the next installment where I reveal even less about what Indrio might be or do or why you should care…