My dual-dual-core PowerMac arrived this week. I had to go with the “low-end” graphics card, because there’s a 6-8 week delay on the better one (I simply refused to consider the best one, which would have added $1,650 to the price), but performance is quite spiffy, and the machine is quite quiet in normal operation.
How quiet? I can occasionally hear a bit of drive noise when it’s chugging away, but I’ve yet to be able to pick the fans out from the background noise in my house. I’m sure that will change when I really start pounding on the CPUs, but when it’s idle, I forget that it’s turned on.
Sadly, since I’ve come down with the seasonal muck, it’s all I can do to sit up long enough to play World of Warcraft for a few hours. The good news is that I can crank up all the video options and still get 30 frames/sec on my 20” Cinema Display. Well, except in front of the bank in Ironforge, but that problem’s on the other end.
Configuration details:
The machine it’s replacing is a dual 1GHz G4 (WindTunnel aka “Dual Mirrored Doors”), so some performance improvement is to be expected. :-)
Most of the real bang for the buck with OS X Tiger is under the hood, but as cool as things like Core Image are, Apple found it easier to focus their marketing on three key features: Dashboard, Spotlight, and Automator. The only problem with this is that they’re not done yet.
Spotlight should have been released as an open beta for users to play with and developers to write plug-ins for. Instead, Apple made it pretty much the only way to search in Tiger, and hijacked a very useful keyboard shortcut to activate it. Worse, the indexing process is a major pig, and the default behavior is to index the entire contents of any disk you attach to your computer, as soon as you connect it.
Dashboard is a cool prototype of a number of ideas. If they ever finish the APIs necessary to write full-featured programs in DHTML, a thousand useful special-purpose tools will appear. As it is, all we’ve got are a thousand web-scrapers, search buttons, and picture viewers, and many of them are CPU hogs. To be honest, I’m more excited by the tantalizing glimpse it gives of a future desktop-layering API; the way that the Dock, Exposé, and Dashboard exist outside the desktop while interacting with it has real potential. I think we’re going to see more such layers in future releases; the most obvious candidates are screen savers and the grab-bag of tools with “float above over windows” options, but there are certainly others I haven’t considered. My other hunch is that a mature version of Dashboard would be a perfect match for an Apple PDA; the SDK’s emphasis on small size and distinctive front graphics fits almost too well.
Which brings me to Automator. It’s actually good enough to call a released application; the problem is that it isn’t what Steve told us it would be. In another year, perhaps, third-party developers will have fleshed it out with a wealth of plug-ins that make it possible to really tie your applications together in useful ways without programming, but it’s not there yet.
So. Today’s problem: my manager’s SO has 3,680 audio files that she wants to put on her iPod. Unfortunately, they’re in a format iTunes doesn’t understand. Google turned up a few Windows utilities that claim to grok this format, but the only Mac tool likely to work was a Mac OS 9 app, and I really didn’t want to reinstall Classic just to find out.
To my surprise and delight, however, QuickTime Player reads them just fine, and it has an Export function that will let me write them out in AIFF or WAV format. In theory, this is a perfect task for Automator: “for each file in these directories, open it up and write it back out in WAV format, then send the whole lot to iTunes and have it convert them to MP3/AAC”. In practice, however, the only thing that Automator can do is allow you to select the files and send them to QuickTime Player; converting them requires a bit of AppleScript programming. Automator will run that script once you’ve written it, but unless you get lucky and find something on the web that’s pretty close, it may take longer to automate the solution than to do it by hand.
I got lucky. Even better, I happen to have another 8,400 of these files that I wouldn’t mind having on my iPod…
[update: it turned out to be easier to hack the script to walk the directory tree directly, so I don’t need Automator at all, just AppleScript. The only way to improve the script further would be to write it in Perl and generate the necessary AppleScript; that way I could have a decent string-handling library.]
Coming soon to a home office near me: Dual dual-core 2.5GHz G5 PowerMac, with 4GB 533 DDR2 ECC SDRAM, 2x 500GB SATA HDD, NVIDEA GeForce 6600 w/ 256MB RAM. Add a Matias Tactile Pro Keyboard and a Microsoft Wireless Notebook Optical Mouse, and life will be good indeed. I suppose I’ll need a new set of speakers, too…
Coming soon after, a copy of Aperture.
So my new Japanese class has started (lousy classroom, good teacher, reasonable textbook, nice group of students, unbelievably gorgeous teacher’s assistant (I will never skip class…)), and, as expected, the teacher is pushing us to master hiragana quickly. I did that quite a while ago, so while everyone else is trying to learn it from scratch, I can focus on improving my handwriting.
One thing she suggested was a set of flash cards. I had mine with me, and mentioned that they were available for a quite reasonable price at Kinokuniya. Her response was along the lines of “yes, I know, but nobody ever buys optional study materials; do you think you could photocopy them so I can make handouts?”
I could, but that wouldn’t be nearly as much fun as making my own set. The first step was finding a decent kana font. Mac OS X ships with several Unicode fonts that include the full Japanese kana and kanji sets, but they didn’t meet my needs: looking good at display sizes, and clearly showing the boundaries between strokes. I found Adobe Ryo Display Standard. TextEdit seems to be a bit confused about its line-height, but I wasn’t planning to create the cards in that app anyway.
How to generate the card images? Perl, of course, with the PDF::API2::Lite module. I could have written a script that calculated the correct size of cards to fill the page, but I was feeling lazy, so I wrote a 12-line script to put one large character in the middle of a page, loaded the results into Preview, set the print format to 16-up with a page border, and printed to a new PDF file. Instant flash cards.
For many people, this would be sufficient, but one of the things sensei liked about the cards I had brought was the numbers and arrows that indicated the correct stroke order. There was no lazy way to do this, so I used Adobe Acrobat’s drawing and stamping tools. The stamping tool lets you quickly decorate a PDF file with images in many formats, so I just modified my previous script to create PDF files containing single numbers, and imported them into the stamp tool. The line-drawing tool let me make arrows, although I couldn’t figure out a simple way to set my own line-width and have it remembered (1pt was too thin after the 16-up, and 2pt had too-big arrowheads).
So why is this post titled “the cleansing power of Quartz”? Because the one-per-page annotated output from Acrobat was more than six times larger than the same file printed 16-up from Preview. Just printing the original file back to PDF shrank it by a factor of four, which, coincidentally, is almost exactly what you get when you run gzip on it…
The final results are here.
Daring Fireball demonstrates at length why it’s a bad idea to pretend that a programming language’s syntax is “English-like”. Personally, I’ve avoided AppleScript due to a bad experience with Apple’s similar HyperTalk language, which scarred my brain the day I tried to do something extremely simple,and found myself typing:
get line one of card field short name of the target
This was the simple, concise way to do it…
…why Apple went from “Dashboard gadgets” during the Tiger beta to “Dashboard widgets” in release. Perhaps this is the answer: Microsoft Gadgets.
Quoting:
To bring the web’s content to users through:
• Rich DHTML components (Gadgets)
• RSS and behaviors associated with RSS
• High customizability and personalization
• To enable developers to extend their start experience by building their own Gadgets
Apple has chosen an interesting method for supporting the current hurricane relief efforts. They’ve made it possible to donate to the American Red Cross through the iTunes Music Store.
They also used their regular iTMS weekly updates mailing list to announce the link.
A Japanese-language online radio show I like, 6Sense, is published in an annoying way. They keep more than a month’s worth of archives online in MP3 format, but each episode is split into 60+ audio files, accessed through a Flash interface.
Examining the Flash app told me very little. Examining my Privoxy logs gave me the regular-but-unpredictable naming convention for the audio files, and a little more digging turned up the URL that the Flash app calls to get the list for a specific day. After that, I simply used wget to download the complete show… as 60+ MP3 files.
Knowing that someone had to have written a Perl script to concatenate MP3 files, I googled and found mp3cat, part of Johan Vroman’s mp3cut package. Making the results into a podcast required the use of another Perl script, podcastamatic, and a web server to host the results. I just turned on web sharing on my Mac, moved the files into ~/Sites, and typed the appropriate URL into iTunes.
With the latest version, iTunes supports podcasts directly, but the integration is kind of peculiar, and carries over to the iPods. Both correctly track what you’ve listened to, and where you left off in the middle of an episode, but otherwise they’re not treated like regular audio tracks.
In iTunes, if you finish listening to one episode of a podcast, instead of moving on to the next episode, it skips to the current episode of the next podcast. On iPods, there’s no concept of “next” at all; when a podcast ends, it just stops playing. If you’ve set it to repeat, it repeats the episode you just heard. Unfortunately, not all podcasts are an hour long; some are quite short, such as ナナライフ, which averages about 90 seconds.
Ironically, the least sophisticated iPod handles podcasts the best right now. The iPod Shuffle just treats them as sound files, and syncs up the play count when you connect it to your computer. When you delete an episode from iTunes, it’s deleted from your Shuffle. Not perfect, but better for long drives (and I’m driving 150 miles a day right now, as I settle in to my new job…).