[Time code];

A while back, I mentioned planning to start work on an anime music video (AMV), as a means of improving my Final Cut skills, and thereby getting my developer head more in line with what’s needed by actual users of media software. I also blogged a couple times (1, 2, 3) about how the process of ripping, de-interlacing, and re-encoding the video from DVD was going.

So, update. Earlier in the month, at the Java Posse Roundup, I did a five-minute lightning talk on AMVs (hey, the topics were wide open, and this has genuine geek culture relevance), so I wanted to get mine started before then, to show it as a work in progress. Joe Nuxoll of the Posse and Dianne Marsh of the Ann Arbor JUG and CodeMash recorded the talks by hand with a digital camera, so you can see my AMV mini-talk on YouTube.

Also, I’ve exported what I’ve got done as an MP4:

Note: the above video uses the HTML5 <video> tag, falling back on the QuickTime plugin if that’s not available. Works in Safari, WebKit nightly, and Firefox… haven’t tried anything else

A couple thoughts so far:

• I think I spent 5-10 hours just logging, creating subclips for use later.
• The Bella Final Cut Keyboard is a massive time saver for editing. I did the last three edits with mouse and keyboard while travelling and it was burdensome compared with the ease of just jogging to the needed frame and clicking the in- or out-point button.
• Some of the source video is a little jumpy (the second edit might merit a redo, because I cut into it right on a jump). Going frame by frame through the source material, there also seems to be a little bit of frame damage at the bottom of every frame preceding an edit… presumably evidence of its being hand-edited film, from the time before anime production techniques went all-digital
• After tightly timing the first few edits to the guitar “ping”s, I allowed them to get looser during the guitar intro. It’s probably too loose, too vague, for some of the “Miyazawa vanity montage” (losing the source video’s dissolve to the flower background shot, and finding a different way into the “towering above the crowd” shot, might help)
• Probably want to lip synch Miyazawa in the doorway on that first line of lyrics.

Update: Ah, I’m my own worst critic. Looking at it again, I should at least chalk up credits for the parts I think work:

• The establishing shots on the guitar “pings” work, and gradually establish the location by getting closer each shot.
• Continuity holds up, as the sequence gradually moves down the hallway and into the classroom. Most of those shots are from the same sequence in the first episode, but I remember one (Arima’s reaction maybe?) was actually borrowed from much later. There are lots of great shots I didn’t use here because of continuity (location and costume, mostly). I imagine each sequence will largely use video from a narrow period of time, so shots match.
• The idea for this first sequence is to establish Miazawa, and I think it’s going in the right direction. Her crazy moments in the first few episodes should work with the lyrics, up through and including the chorus “I’m bad news, baby I’m bad news/ I’m just bad news, bad news, bad news”, cutting to another outrage (like her punching Arima) on each “bad news”. General road map after that:
  • Break and second verse: establish Miyazawa/Arima romance
  • Bridge (“I’m just damage control…”, etc.): inner monologue sequence (His and Her Circumstances has lots of these).
  • Instrumental break (“‘cuz we’ll all need/ portions for foxes”): Maybe super Miyazawa into the solarized effects shots of the classrooms, hallways (there’s a spinning shot from like episode 20 that could cap such a sequence), then back into the establishing locations for the reprise of the opening pings that gets us into the…
  • Third verse: Switch to Arima’s POV (“there’s a pretty young thing in front of you/ and she’s real pretty and she’s real into you”)
  • Third chorus: Back to Miyazawa’s POV (“you’re bad news/ my friends tell me to leave you”)
  • Final chorus: Joyous romantic shots (“you’re bad news/ that’s OK, I like you”) get us to big conclusion and out

Still, it’s good to have it started. Of course, now I’ve committed a massive amount of time to iPhone projects, so I don’t expect to look at this again until sometime after June. I’d originally planned to do this AMV — Rilo Kiley’s “Portions for Foxes” audio with His and Her Circumstances video — as my “learning experience”, then move onto a second video for which I have distinctly more concrete plans. But Anime Weekend Atlanta‘s cut-off for the AMV expo is usually in mid-August, so I’ll be lucky if I can even get this first one done in time to enter it in the expo.

I guess MacWorld isn’t going to get in trouble for revealing information that is behind the developer.apple.com/iphone password protection and is thus NDA. So, read today’s exciting news from them, not me.

Ah, Daring Fireball has it now too.

Sorry for the drop; Keagan broke his elbow last week (no, the other one), and that blew a pretty big hole in my @keyboard time.

One of the epiphanies in the iPhone SDK is in discovering how the iPhone’s development contributed to Leopard. Remember, Leopard got delayed six months so Apple could finish up and ship the iPhone. Various self-styled analysts attributed ulterior motives to the delay, but in retrospect, it looks like what really happened is that a number of technologies were developed for both the iPhone and Leopard.

Bill Dudney, author of the Prags’ upcoming book on Core Animation talks about this in the most recent Pragmatic Podcast, pointing out how CA was developed for the iPhone, and then brought to Leopard. It takes a little work for me to figure out the chronology of that, given that I attended a CA session at Leopard Tech Talks Atlanta in January 2007, but by that point, the iPhone had been announced and its prototype demoed, so its low-level frameworks could surely have been put together by then, to allow for the first batch of apps to be written atop them.

Bill’s working on an iPhone chapter for his Core Animation book, but presumably won’t be able to release it until the NDA releases in June. On that note, I’m pleased to have been a tech reviewer for his book, and it’s a solid trip through CA, starting with the easiest stuff you get more or less for free, and continuing on through greater and greater levels of programmatic involvement with animation and the “layers” that implement them. His last chapter (in the current beta) covers QTKit integration, putting movie playback and video capture into CA layers, allowing you to effect and animate them easily. I helped Bill work through an issue regarding DV camcorders (see the stuff about “muxed” devices in my multi-cam capture stuff), and there may be a PowerPC-only repaint issue that could become a bug report or ADC support request, but all of that should be handled before any readers need to worry about it.

Dang, I owe Bill a back cover blurb too.

Speaking, in a roundabout and non-NDA-compromising way, about the iPhone, it’s not a secret that Core Audio is present on the device: it was listed as one of the frameworks in the SDK special event. Right now, I’m trying out some stuff with its Leopard equivalent, particularly a nice new API called Audio Queue Services. For handling streaming audio, it uses a queue of buffers, and a callback scheme: if you’re writing… oh let’s just hypothetically say one were to write a Shoutcast-style MP3-over-http client (maybe because one did just that with Java Media Framework and abandoned it when Sun pulled MP3 out of JMF)… if you were writing such a thing, you’d just register for callbacks when the queue wants you to fill a buffer. Once it has one buffer, it can start playing (you can also schedule the playback for a specific time), while at the same time it’s calling you back to fill the next buffer. A sample app works fine with Shoutcast streams that I dumped to the hard drive — MP3 only though, no HE-AAC — so I’m pretty confident that it can work just when the callback implementation is wired up to an http stream. At least on Leopard. As for the iPhone, well, that’s all NDA’ed for now, isn’t it?

Oh, and I just discovered CBC Radio 3 has a Shoutcast feed and is in the iTunes Radio listing. Totally awesome, and way more practical than the Flash widget on their web page.

Daring Fireball nicely summarizes the snit about iPhone apps not being allowed to run in the background, for reasons of user-experience clarity, battery life, performance, etc.

I think eventually we’ll see apps with legitimate, long-running needs addressed. Given the kinds of needs people are expressing — mostly doing the occasional poll over the network — here’s how I think it might work (no SDK spoilers here, sorry!)

• An app that needs to have some presence kept around registers a class with the system to do that work when the main app terminates. It’s tempting to call this a “delegate”, but that has a specific meaning in Cocoa (it’s an object that can handle things like callbacks), so let’s call it a “suspended app helper”.
• The helper is registered by its name, and must have a class method like wakeup that does its work. At registration time, the main application can also request that the helper be called at a specific time, or at a regular interval. This request is not guaranteed to be granted.
• When it wakes up, the helper does whatever it needs to do and terminates. It has access to the file system in the same way the main app does, so it can leave files for the main app to pick up, can change preferences, whatever. It should also be able to change its app’s icon, to communicate status (eg, put a red numeric badge on the icon to show you how many e-mails are waiting, how many buddies are on WoW, etc.)
• The timing of the wakeups is key. The system can coalesce all the scheduled wakeups into a single block of time. This potentially saves power, because instead of having background apps keeping the wifi turned on, the helpers all run together, and the wifi only has to stay on long enough to service the helpers.
• If the system knows the battery is running low, it should also have the right to extend the interval between running the helpers, or even abandon them altogether (feature request: the wakeup method might provide a parameter with a “next scheduled call” to the wakeup, NIL if battery is so low that no further calls are expected, thereby giving the helpers a chance to wrap up their work, log out of IM servers, etc.)
• When a main app is run again, it can check the file system for files left to it by its helper.

Yes, this is inspired by lease patterns, particularly in Jini, but they’re common patterns. Nothing new here, just saying the controversy is probably unwarranted: if it’s important, they’ll figure out something reasonably nice eventually.

…and just four business days after the iPhone SDK announcement. iPhone gets its own track, along with Mac and “IT” (Apple cares about the enterprise? Who knew?).

June 9-13. Highly possible I’ll pony up the $1300 and go this year. It’s a big chunk of change for an individual to spend, but it looks to be worth it: lots of sessions provide NDA information that doesn’t get out to the rest of the Apple developer base for months.

A couple of links I tossed onto the desktop to share:

• Ballmer: No Silverlight for iPhone — No kidding. I don’t think anyone believes MS is serious about Silverlight on any platform other than Windows anyways.
• How Apple Just Made All Other Mobile Platforms Irrelevant — A little strong (we are talking about a $400 phone after all; my mom’s not going to have one anytime soon), but talking up the gaming angle is a valid point. Can a device do everything well? PSP movies didn’t pan out, so we’ll see if the media-centric iPhone works as a game platform.
• The iPhone SDK: Apple gets it right — smartly focused on the “ecosystem” of the app store, the install experience, and the iFund. “Apple is challenging the rest of the mobile industry to compete on its terms. It will be very interesting to see how the other mobile vendors react, Nokia and Microsoft in particular.”
• Maybe it’s possible to have too many developers — probably should at least ask the question of how many of the 100,000 downloads will turn into apps on the store. I’d be surprised if 5-10% actually produce finished apps by June (which would still be huge, of course).