I’ve been away from the blog on a pretty grueling day-job contract. It’s actually been positive for my work on the Core Audio book: nothing encourages a side project like disliking your day job.

Squirreling away some morning hours between 5 and 9 AM over the last two weeks, I’ve managed to get first drafts of the first two chapters done (admittedly with a helpful start from the fragments left from Mike and Kevin’s initial work on the book). I actually surprised myself by finding a concretization of the Nyquist theorem, which (basically) says that to reproduce a frequency, you have to sample at at least double that rate. In chapter 2′s digital audio intro, I added an example to get readers looking at raw samples, writing out their own waves as PCM samples. An inner loop uses a samplesPerWave value, and it occurred to me that something interesting happens at the Nyquist point. If you’re sampling at 44100 Hz, then for a 22050 Hz frequency, samplesPerWave is 2. That’s the minimum for a perceivable, repeatable pattern: at a higher frequency, you have less than 2 samplesPerWave and therefore no more repeating pattern, no wave.

Not a big deal, but it was a nice little “aha” moment to stumble across.

I’m enjoying having momentum on Core Audio, and since I wrote that never-published series of articles (yep, the publisher is still wedged) on low-latency use of units and OpenAL, I’ve already worked through some of the conceptually-hardest material, so there are fewer unknowns looming ahead than normal. Which I wouldn’t have expected for Core Audio, surely the hardest topic I’ve ever written about.

I’ve found myself wondering what would be a good topic to pitch and hopefully write about in late 2010, time and budget permitting (writing for anyone other than the Prags is a financial indulgence… it most certainly does not pay the bills).

Here are a few things I’m thinking about.

  • HTTP Live Streaming – The only choice for streaming video to an iPhone OS device, and a compelling choice for streaming media in general. Would probably cover setting up your own server, working with CDNs that support it, writing your own client (if QTX or MediaPlayer.framework doesn’t work for you), encryption and DRM, etc.
  • Core Services – all the C functions that none of the introductory Cocoa books tell you you’re going to need for a serious iPhone or Mac application. Core Foundation, CFNetwork, Keychain, System Configuration, Reachability, stuff like that.
  • C for iPhone – I’ve mentioned this before, how I wrote about 100 pages of this for the Prags, and everything was fine until it wasn’t. With all the people getting into iPhone OS development without a C background and the problems of applying the very dated K&R to modern C development (especially for beginners, who won’t follow its Unixisms or its analogies to Fortran and Pascal), I still think we badly need a C intro that can serve as a prerequisite to all the iPhone books (including ours) that assume C experience. Plus, I find it a perversely fun topic to speak about (see the slides of my CodeMash session).
  • OpenAL – There’s, like, next to nothing to get beginners started with this audio technology, and what’s out there is frequently wrong or outdated (for example, some “getting started” type blog entries use the deprecated loadWAVFile that isn’t even present on iPhone OS). I’m actually thinking of a radically different format for this book, but don’t want to give it away just yet.

I was going to make this a poll, but I don’t think I have enough readers to make that viable, and all the poll plugins for WordPress suck anyways. So if you’d care to vote for one of these options, please post a comment. Besides, I’d love to have new registered users who aren’t offshored spammers.

There will likely be an update to iPhone SDK Development as well, when SDK changes warrant, but that hasn’t happened yet. Let’s see when we get a 4.0 and what’s in it.

CodeMash continues to be one of my favorite conferences to speak at and attend, both because of its convenient location — the Kalahari indoor waterpark in Sandusky, OH, just a four-hour drive from Grand Rapids — and because of its unconventional mix of topics. The concept is to bring together a variety of development styles and platforms: .NET/Java/scripting, server/client/mobile, open-source/commercial, etc. In the last few years, there’s been an increasing Mac/iPhone presence, maybe not enough to count as its own track, but certainly enough to draw attendees from some of the other technologies. And that’s the point of CodeMash: sharing ideas, and seeing what the other guys and girls are up to.

Aside: based on multiple trips to CodeMash, WWDC, JavaOne, and miscellaneous other conferences, I’m struck by how the Microsoft technologies attract far more female developers than Java or Mac/iPhone do, with the open-source scripting languages (Ruby, PHP, etc.) a distant second. Absolutely no idea what’s up with that, but suffice to say if you see a woman at CodeMash, and she’s not Dianne, then she’s quite likely a .NET developer.

This year, three of the four members of the Java Posse were in attendance at CodeMash, doing an atypically-listless panel on Wednesday night, and a bunch of sessions. I felt I should go see all my friends’ sessions, so I went to Dick Wall’s on “Funky Java” and Scala, Carl Quinn’s on tools, and Joe Nuxoll’s on Photoshop for engineers. I came away from these interested in Dick’s company’s DNA science, reminded of Hudson’s value to well-managed teams, and sadly weary of Photoshop bling and what it takes to achieve it in code. Maybe I’m just burned out by the App Store shininess arms race.

I also assisted Daniel Steinberg with his 4-hour Cocoa tutorial, built around a big example project that he wisely saved off as 20 “stages” that attendees could download and review. Daniel also did a 1-hour Cocoa session which served as outreach to developers looking at the Mac platform and not yet ready to jump in.

Attending friends’ sessions filled up most of my dance card, but I did hit a few other things. Probably the most valuable one I went to was Jim Weirich’s “Source Control for People Who Don’t Like Source Control”. The gist of this was to present the design of a hypothetical source control system with modern features and clever ideas… that turns out to be Git. Given that I have a natural aversion to anything loudly and obnoxiously touted by the Linux community as superior (usually based only on the fact that it is from the Linux community), I’ve never really given Git a serious chance, and this was an eye-opener. Git may, indeed, not suck. FWIW, his talk is available as a Pragmatic Screencast.

As for my own talks, I did a half-day iPhone tutorial that ditched the slides entirely and worked entirely from Xcode. It’s a sensible, hands-on approach that I’ll be using from now on. I did three projects: a trivial web browser, a tab-based collection of converters (since those are so damn popular in the App Store), and a conference session browser (as a navigation app). I chose these because of a conscious desire to focus on the repeated creation of view controller classes and their corresponding GUIs, which is the bread-and-butter of iPhone development. It’s good exercise to really get used to creating views in IB, wiring everything up, setting the File’s Owner class, etc. Lots of beginner problems come from missing connections, particularly VCs that aren’t wired to views, so I thought it would be good pedagogy to focus on that stuff first, even at the expense of rhapsodizing about Obj-C or covering more iPhone frameworks.

I also did a session on iPhone tricks and tips that was a mixed bag: I pulled it together kind of late, so some of the media tips were kind of pedestrian (like setting your audio session category to adjust mixing and ring/silent behavior). Still, there were a couple wows worth remembering, specifically using multiple targets to build “lite” and “full” versions, and using keychain to persist data in a way that survives wipes. Slides here

The session I think I was happiest with was “Oh Crap! I Forgot (Or Never Learned) C!” This was actually the last gasp of a book I was writing last year called Just Enough C To Program the iPhone, a language book that used the iPhone SDK as a workbench. The idea of the book was to help the scripters and Flash developers who got lost in the pointer stuff in our iPhone book, as well as first-time programmers who wanted to develop iPhone apps right away, even if they had never programmed before. In short, it would serve as the prerequisites for our, or anyone else’s, iPhone book. But it’s not happening: it’s one of those projects where everything was fine until it wasn’t.

Still, I sometimes find I enjoy the directness, the concreteness of programming in C.

So that’s something I tried to bring out in this presentation: not just that you might have to use C for some reason, like calling into native code from your higher-level language, but that C’s performance, popularity, and even its primitiveness are traits to be admired and enjoyed. The last third of it really got into the traditional C “hard parts”: pointers, malloc()/free(), pass-by-value, arrays as syntactic sugar over pointers, when struct members take the dot versus the arrow operator, memory math, etc. Slides here.

The iPhone tutorial is a consistent big draw, but I just might propose a half-day “C re-education camp” tutorial for next year, to fully immerse attendees in the C way. Maybe with some OpenGL (which is called from C) so it’s not all about the command line. Any takers?

I’m speaking at two conferences in early 2010, as indicated by the badges in the right side column.

First is CodeMash in Sandusky, OH, January 13-15. I’m doing one four-hour “precompiler” tutorial on iPhone programming, and two sessions.

No, of course they’re not done yet. But here’s a bit of what I’m planning:

  • Introduction to iPhone SDK – I’ve decided that rather than put up some slides to walk through the basics, I’m going to teach the entire tutorial in Xcode and Interface Builder. This means I need to not only write my examples in advance (duh), but to pull together a bit more of a script so I know where to stop and explain things: “Objective-C uses square braces for method calls, which are really better thought of as message dispatches”, “IBAction is synonymous with void, but tells Interface Builder it’s OK to accept a connection to this method”, etc. I’m also thinking about how to cover the most truly useful material in four hours. I think I’d like to do the trivial browser in the first hour to do basic project building, IB, coding, etc., a tabbed app in the second hour to play with multiple view controllers, and a navigation app in hours 3 and 4, since those are so bread-and-butter. The nav app might use the webservice of the conference’s session list… if I think we can really pull off tables, networking, and XML parsing in two hours. Gonna have to rehearse to convince myself it can be done in a group setting in that kind of time.
  • How Do You Do That on iPhone? – This is just going to be a grab-bag of non-obvious techniques that you can’t get from the docs and instead have to learn from forums, programming guides, word-of-mouth, etc. Things like custom table cells and building the “full” and “lite” versions of your app with one Xcode project (hint: understand how “targets” work).
  • Oh Crap! I Forgot (or Never Learned) C! – In a way, this is the last gasp of a book that I wrote 100 pages of before it just ended up not happening. My thesis was that for all the developers who never learned C, or did but forgot, it’s a real bitch to be thrown into the world of pointers and malloc and life without objects, especially when the premier guide to the language was last updated during the Reagan administration, and contains no-longer-helpful analogies to Fortran and Pascal. The idea of the book was to be a C primer that you’d work through with the iPhone SDK, not in order to learn the iPhone APIs right away (we already wrote that book), but so that there would be a specific workbench, freely and easily available, for learning the C language (this is where K&R basically says “use cc on the command-line and if that doesn’t work, go ask a sysadmin.”). The session is going to survey the language from the point of view of scripters and other modern-day programmers, with particular attention to memory-management concerns, and idioms that are unique to C (things like setting up “context objects” for callbacks, because you don’t have closures).

Then, in April, I’ll be at 360iDev in San Jose (register with my special link), speaking on the topic of Core Audio. The talk, Core Audio: Don’t Be Afraid To Play It LOUD is one where I’m going to try to play up the fun factor a little more, and embrace the fact that Core Audio is a goddamned hard API to master. If you can do anything in Core Audio, you should feel awesome, and I’ve found that small successes in this API make you want to learn more. Oh, and bonus points if you catch the reference in the session title.

BTW, more news on the Core Audio front in an upcoming post…

One-time self-described “World’s Greatest Compressionist” Ben Waggoner posts a pointed question to the quicktime-api list:

http://www.apple.com/macosx/what-is-macosx/quicktime.html

What I’d like to know is if QuickTime X is going to be available for Windows and older versions of Mac OS X.

It’s an important issue, because despite iTunes’ insistence on installing QuickTime on Windows, the future of that product seems completely unknown. For years, every question I’ve seen about the future of QuickTime on Windows has been met with absolute silence from Apple. Yeah, I know, “Apple does not comment on unannounced products,” and all… Still, Apple has left this technology in limbo for a remarkably long time. I recall asking ADC reps about QuickTime for Windows back at Leopard Tech Day Atlanta in 2006, as I was considering calling it from Java with JNI, and (as previously noted), I got no reply at all. And every other public question I’ve seen about the future of QuickTime on Windows has gone similarly unanswered, for years.

Smell that? That’s the scent of Abandoned Code Rot. We got that from QuickTime for Java for a few years before they managed to finally deprecate it (though they apparently haven’t gotten the message out).

It wouldn’t be too surprising to see QT for Windows fall by the wayside… Apple probably cares more about the popularity of its favorite formats and codecs (AAC and H.264) than of the QuickTime APIs and QuickTime’s interactive features like Wired Sprites that have been clearly and unequivocally beaten by Flash.

But if that’s true of Windows, is it also true on the Mac? QuickTime developers are right to be a little worried. The old C-based QuickTime API remains a 32-bit only option, intended to be replaced by the Objective-C QTKit. But in the four years since its introduction in Tiger, QTKit has only taken on part of the capabilities of the old QuickTime API. With Leopard, you could finally do capture and some significant editing (e.g., inserting segments at the movie or track levels), but raw sample level data was unavailable for any track type other than video, and some of the more interesting track types (like effects and especially tweens, useful for fading an audio track’s volume between specific times) are effectively useless in QTKit.

With Snow Leopard, the big news isn’t a more capable QTKit API, it’s QuickTime X. And as Apple’s QuickTime X page points out, QTX is all about a highly-optimized playback path (using decode hardware if available) and polished presentation. Great news if you’re playing 1080p movies on your computer or living room PC, not so much if you want to edit them: if you want to edit anything, you’re back in the old 32-bit QuickTime (and the code is probably still written in C against the old APIs, given QTKit’s numerous limitations). You don’t see a 64-bit Final Cut Pro, now do you? (BTW, here’s a nice blog on that topic.)

When you all install Snow Leopard tomorrow and run the QTX-based QuickTime Player, you’ll immediately understand why the $30 QuickTime Pro (which bought you editing and exporting from the Player app and the plug-in) is gone. Follow up in the comments tomorrow (after the NDA drops) and we’ll discuss further.

If I were starting a major new multimedia project that wasn’t solely playback-based — imagine, say, a podcast studio that would combine the editing, exporting, and publishing tasks that you might currently perform with Garage Band, iTunes, and FTP — I would be very confused as to which technology to adopt. QuickTime’s cross-platform story seems to be finished (QTJ deprecated, QTW rotting away), and everything we hear on the Mac side is about playback. Would it be safer to assume that QuickTime doesn’t have a future as a media creation framework, and drop down to the engine level (Core Audio and Core Video)? And if not QuickTime… then what?

Oh, and as for the first question from the quicktime-api thread:

… How about Apple throwing us a bone as to what QuickTime X will offer those of us that use QT and QTSS?

From what I can tell, Apple has all but ditched QTSS in favor of HTTP Live Streaming, supported by QuickTime X and iPhone 3.0.

After last week’s crunch, closing the last of the errata and our own to-dos, we have officially sent iPhone SDK Development to production, meaning it will now get a second copy-edit, typesetting, printing, binding, and shipping to your anxious hands.

A note of thanks is in order to the beta-program purchasers and the thousands of errata they filed, along with over 500 forum discussions on the book. No getting anything past this group, that’s for sure.

Well, maybe one little thing. With the Snow Leopard release date now set, it looks like Apple engineers have a chance to reply to e-mail from several months ago. Last night, I heard back from the dns-sd.org folks (at an @apple.com address) about my request back in June to reserve a Bonjour service type for the Game Kit example in the book. The bad news is, I included an illegal character in my service name, so I had to change it from amiphd_p2p to amiphd-p2p, which is now part of the public list of DNS SRV (RFC 2782) Service Types. And the only reason that’s bad is that the book still has the name with the underscore, and I’m currently locked out of the book during production.

It’s a minor point, and it will get fixed, it’s just silly-bad timing, getting a reply to a two-month-old e-mail just a day after we wrapped the book.

Another interesting @apple.com e-mail has to do with the Clang Static Analyzer that we cover in the performance chapter, but that remains NDA for now. Anyways, they’ll have their own updates in due course, so watch their page.

Related point: I went to the Barnes & Noble on 28th Street for the first time in ages today, and drifted by the computer book section. It’s probably the biggest in Grand Rapids, for what that’s worth. Computer book sections are shrinking everywhere, particularly the programming sections, for a number of reasons: anything nichey is a non-starter at retail and is basically only available via Amazon and the like, programmers are eagerly jumping into eBooks (or bundles where you get a PDF now and the paper book when it’s ready), some programmers prefer the immediacy of blogs and other informal sources to stuffy books, and of course nearly any computer eBook of any significance is on bitTorrent (including ours, despite the fact that the unauthorized PDFs all clearly identify the reader who chose to post his or her copy). All of which goes to explain why your local retailer has less reason to stock computer books when they can make more money off political screeds and trifling fiction. And, as I discussed a few weeks back, why you’re going to continue to see fewer and fewer programming books going forward.

Still, the iPhone SDK is such a hot topic that even all this friction can’t stop it from being a popular topic with readers and authors alike. There were at least four other iPhone programming books on the shelves, and I took a first peek at several of them today. Note of explanation here: when writing a book, I never look at anything that could be considered a “competing” book. It’s my own mental firewall that ensures that my work is my own, and that I don’t lift ideas from fellow authors. That said, I do read the official docs, both to learn things myself and to make sure that the book I’m writing goes beyond what you can get for free. There’s no value for the reader (or the writer) if the book is just a paraphrase of Apple’s programming guides.

I think the only one on the shelves today that is officially updated for iPhone SDK 3.0 is Dave Mark’s Beginning iPhone 3 Development book, which features significant coverage of Core Data, probably the most significant of the new features in iPhone SDK 3.0. Of the older titles covering iPhone 2.x, I saw Erica Sadun’s, Jonathan Zdziarski’s, Neal Goldstein’s and Christopher Allen and Shannon Appelcline’s books.

They’re probably all worth a deeper read, though a glance through them and a mental comparison to my own project of the last year shows some similarities and differences. I’m sure all of us are grateful for the ease of getting screenshots from the simulator, as all the titles are rich with illustrations. Nearly all of them cover OpenGL, which ours actually doesn’t, I think because Bill thought that readers would be better served by studying OpenGL on its own (and that there isn’t enough unique about its iPhone implementation… as opposed to say, SQLite, which I put in the book not so much for the SQL or even the C API as for the strategies of managing the database files within an iPhone context: creating them with your Mac’s sqlite3 interactive shell, putting them in a bundle for deployment and backup, etc.). On the other hand, I think ours is the only book to talk about debugging and the various performance tools (Shark, Instruments, and the third-party Clang Static Analyzer). Unsurprisingly, given my inclinations, it looks like we hit media a lot harder than our peers. Counting the new-for-3.0 “Music Library Integration” chapter, we ended up with four media chapters, totaling nearly 75 pages. And that’s after cutting the too-hard-for-now Audio Streaming chapter.

It looks like all the other authors assumed a pre-requisite level equivalent to ours: know a curly-brace language, preferably C, and we’ll cover Objective-C as we go. We’ve had a few scripting-language converts (Flash/ActionScript people, it seems) on our forums who have a hill to climb with the latent subtle C-isms, mostly the memory stuff, and I wonder if our colleagues have had similar experiences with their audiences. C knowledge is a strange thing: all us old folks think it’s a lingua franca, yet I think we all know that younger developers no longer learn it as a matter of course, and may not be particularly eager to do so.

Anyways, I imagine everyone else is rushing out their 3.0 updates too, so it’ll be interesting to see what new features get covered, and what our readers still want from us in future versions or more advanced titles.

I found a link on blip.tv (Low-Latency Core Audio with Queues, Units, Graphs, and AL) to the talk I gave at iPhone Camp Atlanta a few weeks ago. Here’s the <embed>:

I’m not sure if this is meant as final, or if the conference’s home page will have updated video links later. I sure hope it’s not final, because the video is several minutes out of sync with the audio. To wit, I’m looking at 10:27 right now, where the video shows a dialog indicating the hardware latency of the Audio Unit demo, but the soundtrack is still one topic back, talking about Audio Queues. It also cuts out at least five minutes before the end of the talk.

While it was short and off the cuff, I thought it went well and covered a lot of important stuff for people who’ve touched Core Audio and want to know how far down the rabbit-hole goes. Hoping they’ll post a fixed video someday.

Next Page »