|
|
GeekTool - Useful and fun info on the desktop
I see your point about Console entries, but your script will not indicate what song is selected in the Player if it is not playing; IOW, if Player is paused, you get no result in your GT display. With the script I posted above, it will always return the selected song info (if iTunes is running), unless you're in the Music Store playing a sample, video or similar, which does not return data; thus the error handler in the above script, which does not send any info to Console.
GeekTool - Useful and fun info on the desktop
True, I guess you could add another chunk of code similar to the player state to reflect iTunes in paused or stopped(?) state. This would return data in those 3 scenarios which I believe are the only ones that would be used while iTunes is open.
GeekTool - Useful and fun info on the desktop
I modified my script a little...ok a lot...the output of this will look like this:
the timer will adjust depending on the position of the track and updates in real time going from 0:00 to 3:41 (in this case) It also checks to see if iTunes is playing, paused, stopped, rewinding, or fast forwarding and will output the track title regardless of the state the player is in. This was mentioned to me by Frederico (thanx!).
GeekTool - Useful and fun info on the desktop
I like that you've taken an extra step or three to look for additional Player states; and testing your script exposes some weaknesses in mine that I just wrapped entirely in one big error handler; something your script lacks and really needs. E.G., try this: open your script in Script Editor; observe the 'Event Log History'; open up the iTunes Music Store; find and play any sample; run your script:
Part of the problem is that you're asking iTunes to return information about song data before you even know the Player State; but, as the above test proves, even a player state check first, with streamlined code to reduce the excessive requests in your original check for Player State (i.e., if your Player is Fast Forwarding, your script makes five attempts to figure that out; too slow; taxes osascript and CPU cycles) followed by an info request can fail in certain states when the player is still Playing. Observe:
Result:
So, while we have a Player State that is Playing, and we could even meet any one of the other five states while in the Music Store, or other similar condition, we choke on duration. Try reordering the info calls, and you get some interesting results:
Interesting. So, with some logical deductions and some error handlers, we can probably, through testing various Player States, return more useful data to GeekTool. Now, I'm still using iTunes 4.1 and iTunes 4.5, and I think iTunes 4.6 actually deals with this better by allowing for more Shared Library and Music Store calls, plus you could probably get the current view of the browser to return more useful info, so I don't know how much effort its worth. That said, assuming they didn't, here's one iteration that not only streamlines your code more, but also handles at least the Music Store failure a bit more gracefully:
Anyway, it's all fun playing around with new ways to skin cats.
Cheers
GeekTool - Useful and fun info on the desktop
Oops! There's an error in the last line of that error handler; it reads:
Should read:
Sorry!
GeekTool - Useful and fun info on the desktop
Hmmmm... never mind that I neglected to account for the Radio playlist being active... Good thing I rarely ever listen to it.... (;
GeekTool - Useful and fun info on the desktop
This version accounts for both Radio and Music Store:
|
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.09 seconds |
|