what is emojis? those emoticons? why are they classist?
Emojis are emoticons that can only be typed by iPhones and read by iPhones and iPod Touches. They cannot be typed or read by computers or non-smart phones. The emoji is inherently classist because it excludes people who do not own expensive Apple products. Most people cannot afford iPhones and iPod Touches… when you type an emoji, you type a symbol that only financially advantaged people can read. That is classism.

Wow. That is a lot of stupid packed into one paragraph. The first sentence alone has at least four factual errors (emoji are not emoticons per se, the plural of emoji is just “emoji”, they can be entered by devices other than iPhones, they can be read by many devices), and it doesn’t get better after that (the poster has clearly never heard of Unicode or the free-with-contract iPhone 3GS).

Obviously, it was beyond the poster’s ability to look up the Emoji entry on Wikipedia.

I’d love to quote Colony Drop’s witty comment from their tweet but, alas, WordPress can’t handle Unicode emoji!

I’ve spoken at nearly all the CocoaConf conferences, and I have no reason to doubt Dave’s version of these events. Indeed, while some commenters would like to portray this as a spat solely between the Intercontinental and CocoaConf – and leave Apple out of it – that position doesn’t square with the facts. If the Intercontinental knew they were contracturally prohibited from hosting CocoaConf Alt, they wouldn’t have signed a contract with CocoaConf in the first place, right? Daniel Jalkut makes the best case for letting Apple off the hook, suggesting that someone at either the Intercontiental or Apple got a trigger finger and killed the event when they didn’t necessarily need to. That the Intercontinental realized it was in a conflict-of-interest scenario after the fact is possible, but it’s no more plausible than the idea that Apple doesn’t like anyone riding on their coattails and sent the hotel management a nastygram.

For what it’s worth, that latter scenario is the one that rings true to me. (Or, to haul out a tag I haven’t used in a while, nefarious skullduggery!).

But what’s done is done, and if Apple stomping on CocoaConf Alt adds to this year of WWDC discontent, so be it. It’s a little surprising to continue to see complaints and hand-wringing over the technical problems of the WWDC sales (see TUAW and Core Intuition), when the underlying problem is a massive mismatch of supply and demand for tickets to the event. If nobody had gotten server errors and the conference had sold out in 20 seconds instead of 60, would that have really been any better?

Maybe this is the year that WWDC jumps the shark for a lot of us? Maybe it already has?

I had my say about WWDC two years ago, hoping for some sort of radical change, and Daniel Jalkut does me one better by calling for an end to it altogether. When so many of the things that used to define WWDC – meeting up with colleagues who are there every year (but who didn’t get tickets this time), Q&A at the end of the sessions (dropped years ago in favor of one-way proclamations from Apple) – it starts to be hard to see how spending $3-5,000 makes more sense than just watching the videos, especially for that majority of attendees who never visit the labs.

So, I’m down on WWDC right now, in part of a general disquiet with the Apple platforms in general. They’ve released literally nothing this year, except an iPad with 128 GB of storage (the model I’m typing this on, by the way), ignoring badly out-of-date offerings like the Mac Pro, and all the creative professional apps like Logic and Aperture that you’d want to run on such a machine. Aside: If I were a full-time video professional, I would find it difficult to justify staying on the Mac platform, as there is no sense that Apple (the only supplier of Mac hardware) will offer professional-appropriate hardware in the future. An iMac with a daisy-chain of expensive Thunderbolt peripherals – assuming such things come to market at all – is deeply unappealing, and traps the owner with a non-upgradable video card and (in the lower models) no RAM expansion. A Hackintosh is more sensible, and once you go down that road, it’s worth asking if it’s worth giving up the fight and just switching to Windows. After all, the aforementioned Logic and Aperture have long languished without updates, something the “We Want A New Mac Pro” Facebook page asked Apple about… and got stonewalled.

So what are we expecting at WWDC? The inevitable MacBook refresh, and an end to Rich Corinthian Leather. Yawn.

I never planned to go to WWDC this year, or CocoaConf Alt, and am happy to keep my Summer free. I’m actually thinking pretty seriously about applying my conference budget for the year to Streaming Media West in November to dig more deeply into livestreaming. (And yes, I’m aware that Streaming Media East is just two weeks away, but conflicts with an already-planned personal trip to Anime Central next week.)

In the Fall, CocoaConf will be doing conferences in Portland, Columbus, Boston, and Atlanta. The late Summer / early Fall iOS talks are always tricky to do, because there’s usually a new verison of iOS that’s been announced at WWDC and is in beta, but which is still under NDA. So you can’t talk about the new stuff, and what you can talk about is old news.

One way to deal with that problem is to not limit talks exclusively to touring iOS frameworks. Following up my CocoaConf San Jose talk on Core Audio that touched on Audiobus, I’m thinking I may pitch an entire talk on that remarkable inter-application audio system (now supported by 180+ apps, last I saw!). I’ll need that much time to get into the developer program and get some good demos whipped up.

I had another thought for an NDA-proof topic: audio and video encoding for the iOS platforms. I could haul out Handbrake and Compressor (and AVAssetExportSession and AVAssetWriter in code) and mess with encoding formats and bitrates and get into the nitty-gritty of the various formats, what hardware they work on, their advantages and trade-offs. This kind of stuff scratches my A/V producer itch nicely, though I find it’s often a challenge to sell developers on the art and science of digital media. There’s a “just show us the code” mentality out there, one that sometimes hits the wall of “understand what the code does” in practice when you don’t truly understand the problem domain. ExtAudioFileCreateWithURL() is all well and good until you try to put big-endian PCM in a WAV file, or little-endian into an AIFF, or you don’t understand why caption tracks aren’t preserved by the AVAssetExportSession, or why your dissolves and primary/seconary movement are artifacting all over the place.

I like to come into each conference with something new, and having two new talks for the Fall tour fits the bill nicely. That leads to the question about teaching classes for the tutorial day of CocoaConf. Last year, I did my all-day Core Audio class three times, and this Spring I did an iPad Productivity class (mostly on UIDocument, along with topics like inter-application communication and printing) in Chicago and DC. I continue to get requests for Core Audio (and reprised it in San Jose a few weeks back), even though I think iPad Productivity has a wider pull. So maybe both of those will show up on the Fall tour, just in different cities (I already did Core Audio in Columbus and Portland, so those cities probably get iPad Productivity).

So, yes to CocoaConfx4 and Streaming Media West, no thanks to WWDC.

I’d hoped to get a full-blown Audiobus demo ready in time for the conference, but client work took priority, and in the midst of an 11-hour flight delay in Denver, I didn’t have the tools or the stamina to pull it off.

Actually, I’m thinking I may work on digging into Audiobus enough to get a whole one-hour talk on it ready for CocoaConf’s Fall tour. Doing so would also help me deal with the fact that some of the Fall conferences will likely fall inside the iOS 7 / OS X 10.9 NDA period, leaving us unable to talk about the new hotness from Cupertino. Audiobus is an interesting new topic that would not be encumbered by the Cupertino cone of silence.

I also continued to freshen the HTTP Live Streaming talk over the half-dozen or so times I gave it, but instead of spending more time (like people asked me to) on the iOS code part of the topic — which is pretty much a trivial use of the Media Player or AV Foundation frameworks — I found it was more interesting to track the spread of HLS to other platforms, such as over-the-top boxes like the Roku, for which I whipped up a demo that uses the HLS streams created for the iOS demos. HLS has continued to pick up outside adoption over the last 12 months, including Adobe adding it to their Primetime product last week.

Thanks probably to the clout of the iOS ecosystem, HLS seems to be becoming the de facto streaming standard for the time being, for better or worse. MPEG-DASH seemed like it had the best shot at dislodging HLS (thanks in part to its pedigree, along with the manifest danger of having much of the streaming video world clinging to a semi-standard and beholden to Apple’s capriciousness), but Streaming Media argues that DASH is overrated, and that the format problems it hopes to solve are already addressed by existing products, such as the current streaming servers from Wowza, Microsoft, Adobe, and Real. My open skepticism that MPEG-DASH would be the “15th Standard” appears to be playing out.

I’ve got one more conference coming up, MobiDevDay, this coming Saturday (May 4) in Detroit. My talk there is going to be a high-level overview of all the media frameworks on iOS, with an eye towards helping you figure out the right one for your app, where there’s overlap and where there’s one right tool for the job.

Gotta tell ya, esteemed blog readership, I’m pretty worn out from juggling an every-other-week conference tour and multiple clients who needed their projects to be production-ready yesterday. Oh, and a five-hour round-trip to teach the occasional session of the Develop Detroit class on the other side of the state. I like getting away, but it’ll be good to take a couple months off and stay at home for the Summer

No, I’m not going to WWDC. Didn’t try to get a ticket (too much drama), and don’t feel like it’s worth the expense now that I’m pretty comfortable with the platform and really just need to keep up with Apple’s annual changelog. Actually, with my rapidly-developing interest in livestream production, I’d find it far more valuable to go to the Streaming Media conference. I’m too tired to go to Streaming Media East in a few weeks (especially as it’s right after my weekend at Anime Central), but I am thinking fairly seriously about saving up for a trip to Streaming Media West in November, a trip which would also give me a chance to catch up with a number of friends and colleagues in the LA area. So… we’ll see.

Summer projects include more livestreaming experimentation, probably starting with Wowza’s 30-day trial (likely on Amazon EC2), so I can assess the value (and cost) of getting away from UStream. Not that I dislike Ustream, but there are reasons I might want to own my own infrastructure, rather than having UStream branding, their ads, and their copyright bots getting pissy with me if I run a popular movie trailer or an AMV in my pre-show. I also want to do some trial runs for different kinds of stream content: I’ve done iOS gaming and conference talks, but I’m also thinking of some live coding demos, some entertainment and fun stuff, etc. There’s also work to do in reimagining the stream for full-screen viewing: what do you do differently for your video stream when the target device is an HDTV (via a Roku or Apple TV) rather than an embed in a browser window?

So, Spring and Summer, 2013: less talking, no writing, more clients, more streaming. Sounds like a plan.

Earth to MacWorld: It’s already too late. The market has spoken, and it refuses to pay for apps, even when the toxic side-effects of that are manifest.

MacWorld’s piece comes in part as a response to Michael Jurewitz’s five-part series on app pricing, posted on the eve of his return to Apple (and, presumably, a lot more circumspection about his future blogging). Jury sees the app pricing race to the bottom as a self-inflicted wound and urges developers to charge what their apps are worth.

Great advice… for anyone still around to take it.

As a developer, it’s easy to get outraged at cheapskate users who complain that a $1.99 app is a “rip off” because it has a bug or doesn’t do what the user expected it to from the description. It’s galling that the comments on the MacWorld piece justify stinginess (or outright piracy) on the grounds that iOS apps don’t easily afford a “trial” system. To say that you got a bad $3 app once and can never trust app purchasing again is like saying you once had a bad burger at McDonalds and will therefore never eat in any restaurant again (or maybe every restaurant should have free samples of everything on its menu available at all times).

Yeah, OK, I could go on like this for a while, but the fact is that appealing to the better nature of the general public usually doesn’t work out. We are stuck with what our customers believe, and that means that they largely aren’t willing to pay for apps.

So what’s the proper response? Obviously: don’t write apps for sale in the App Store anymore. This has already happened. But it hasn’t manifested itself as a mass migration off the iOS platform (what, like Android users are any more willing to pay for apps?), but instead a migration into what one article (that I can’t find!) called the “middle class of developers making apps for corporate clients”.

Of all the full-time iOS developers I know, almost none of them work primarily in writing apps for sale to end-users. Nearly all of them, myself included, work for clients for whom an app makes sense in some other business model. For example, an app that lets end-users make use of some subscription service (like Netflix or Dropbox), or a physical product (the remote control app for my Roku). Or an app that will make the business’ own employees more productive. Or an app that flogs the company’s products. All of these apps generate value for the paying customer, but that’s the company that’s hiring us, not the end-user.

In other words, while there isn’t a competent business accounting app for the iPad (an equivalent to QuickBooks or AccountEdge, and not just a companion app to those desktop programs), there are plenty of apps to help multi-level marketing professionals maximize their downlines. And that’s because Amway will pay developers for their time, and the “$5 apps are a ripoff” crowd won’t.

True story: I was going over a GUI design for a client’s Mac app in a group chat and I said “man, I’d love a touch version of this on an iPad.” The client said they’d love to do it, but could never charge enough on the iPad to cover the development costs.

Think about that for a second. With 100 million iPads sold since 2010, versus a Mac installed base of about 60 million, the iPad market is nearly twice as large, yet cannot justify development or even porting.

As a user, I’d like to ditch OS X someday and go entirely iOS — I cling to the belief that iOS can get better faster than OS X gets worse — but that can’t happen if essential apps I need are never made for the platform. The lack of productivity apps for iPad is part of the reason I started teaching a class on the iOS productivity APIs at CocoaConf, but raising awareness and enthusiasm for this stuff doesn’t solve the real problem. If developers can’t recoup their investments in these apps, because the pricing power in the App Store has collapsed, then we won’t develop them at all.

A few years back, we figured Android apps were a non-starter because the Android user base would never pay for stuff. Who knew that this would apply to iOS apps as well?

What do you hate about most Cocoa Podcasts? They tend to be way too long, rambly, unfocused, self-indulgent. Therefore, if I were to produce a podcast it would be focused on the audience.

OSEG, so true. So I tweeted it right then and there:

Take a look at the tweet details and you’ll see a long trail of reactions, including those from Cocoa podcasters Saul Mora of NSBrief and Wolf Rentzsch and Andrew Pontious of Edge Cases.

So what’s the beef that Daniel and I have? Actually, it starts back at CocoaConf Chicago, and a flippant question I asked as the moderator of “Reverse Q&A”, where we take a panel of speakers and have them ask questions of the audience instead of the usual way around. Shifting topics with a segue, I asked “what’s the deal with all these developer podcasts anyways? why do we have so many?”

And the answer I got back was: “it’s easier than blogging.”

Skyping It In

That answer kind of floored me, but in the past few weeks, it actually seems to make a certain somewhat cynical sense. Let me give you an example:

Driving from CocoaConf back to the Baltimore airport (yes, CocoaConf DC was right next to Dulles, but getting a nonstop from Grand Rapids to BWI was actually easier and much cheaper), I listened to the Accidental Tech Podcast with iOS/Mac luminaries Marco Arment, Casey Liss, and John Siracusa, in part because I saw that they were covering Michael Tyson’s revolutionary Audiobus. The gist of the discussion was that it is rather surprising that Apple not only approved of Audiobus’ enabling of real-time inter-application audio communication on iOS (in contrast to iOS’ usual locked-down, single-app mindset), but that Apple even updated GarageBand to add Audiobus compatibility.

OK, so far so good. But then they got into the topic of how Audiobus can even work. There are two good ways to answer this question:

1. With a correct answer
2. By saying “I don’t know”

There is also a very bad way to answer this question:

3. By pulling a wrong answer out of thin air

Of course, I wouldn’t be writing this if they hadn’t gone with option #3, speculating that Audiobus probably opened a network port and communicated with sockets. It’s not an unreasonable answer, but it should be suspicious because of its obviousness: that approach to inter-process communication has been used on Unix for decades (we did it at Pathfire in the mid-90′s), and is prominently featured in the classic Beej’s Guide to Unix Interprocess Communication. And the reason listeners should be suspicious was that if it were that easy on iOS, it probably would have been done a long time ago.

The right answer, for what it’s worth, is that Michael discovered a novel way of using MIDI to send arbitrary blocks of data across the MIDI bus, which is accessible by all background applications. @flunkwerx pointed me to Michael’s blog post where he spells out this key discovery, and how it led to creating Audiobus.

OK, so long story for one mistake, but I think it’s unfortunately typical of the norm for the structure Cocoa podcasts. We have a regular set of personalities who expound on their thoughts in a group conversation, which is then converted as-is into an MP3 file and posted to the podcast feed. If they were blogging, any of them could have taken a few minutes to research and possibly find Michael’s blog. If they were livestreaming, an audience member in the chat room might well have corrected them, as often happens on shows like MacBreak Weekly. But with no time for upfront research and planning and no feedback loop, giving wrong answers that stay wrong is likely inevitable.

For what it’s worth, Daniel edits a podcast where every once in a while one of the hosts needs to pause to research something more before giving an opinion or providing a reference – “Hold on,” they say. And then while the recording runs they do whatever research they need to. “OK”, they say when they find it. They reset their answer and go on. The gap is easily edited out later, and the podcast is much more useful to the listener because it’s actually correct. Problem solved.

The Man Without A Plan

But Daniel’s slide quoted above doesn’t say anything about being wrong. He’s got a completely different set of complaints: length, self-indulgence, and rambling. Those are probably endemic to the format that most Cocoa podcasters have chosen. Which begs an even more important question: why did they choose that format?

Or… did they even make a choice at all?

In creating media, it’s common to talk about three phases of production:

1. Pre-production – Coming up with the original idea, planning how you’ll accomplish it, writing, budgeting, hiring, etc.
2. Production – The actual making of the thing: recording, filming, acting, performing.
3. Post-production – Additional work done after the production stage: editing, mixing, fixing, effects, titles, re-encoding, etc.

When so many podcasts are following the same format — a set group of personalities discussing the topics du jour — it’s fair to ask whether the first step has been skipped entirely. Is there any plan involved at all, any specific result that is meant to be achieved? Or does the next Cocoa podcaster do his podcast this way because all the other podcasts he listens to do it this way?

On And On And On

And the last step is commonly skipped as well. Back on my original tweet, you’ll notice that several of the objections raised involve how difficult it would be to edit the recorded discussion. Overwhelmingly, Cocoa podcasts seem to be taken as-is and posted to the internet. Every sidetrack, every corny joke (seriously, when a product is mentioned as being “not dead yet”, you really don’t have to go into a Monty Python and the Holy Grail bit… you’re not that funny), every dead-end conversation gets equal prominence as the gems of insight if the whole thing is just dumped on listeners.

The result is that these podcasts are commonly 90 minutes long, sometimes two hours, sometimes longer. How is it that these things are as long as a movie, yet don’t deliver nearly as much value? Might I suggest that if David Lean can tell the life story of Lawrence of Arabia in three hours, you should need a lot less than that to tell me why Apple would never make a flat-screen TV.

You’re Right! We’re All Individuals!

The other problem with these unstructured pundit-fests is that they’re contributing to a sort of groupthink in the Cocoa developer community. If someone were to go back to step 1, pre-production, and say “I’m going to make a podcast that challenges conventional wisdom about iOS development”, I’d want to listen to that. If someone set out to make an iOS podcast about that was entirely postmortems of successful or failed projects by interviewing their developers, I’d want to listen to that. If someone wanted to create a podcast featuring female and minority developers that are absent from all these other podcasts (notice my deliberate use of “he” three paragraphs ago), I’d subscribe. Those would probably bring some new ideas to the fore.

But another podcast where authors or other personalities speculate about rumors, rant against skeuomorphism, ascribe every mean-spirited Apple decision of the last five years to Scott Forstall (or the absurdly unfair and misguided caricature that’s been made of him), and spout conventional wisdom about “how Apple works”? Pass.

The Macintosh Way

Guy Kawasaki got a whole book out of “The Macintosh Way”, meaning “the right thing, done the right way”. I like podcasts a lot, and I like Cocoa development. I think these are all the right thing, but so many of them are done the wrong way. So what would help?

First off, there really ought to be a genuine interest and passion for the concept and craft of podcasting itself. It is a remarkable irony that pundits on these shows can go on about the rigor and polish required to make great apps, and then insist on minimal-effort, uninspired, unpolished podcast production to actually create the podcast. If your users deserve great apps, why don’t your listeners deserve great podcasts?

Greatness requires beginning with the end in mind. Podcasts should start with a vision of what you want to accomplish. And there are a lot of metrics to consider:

• Genre – Entertainment, academic, business development, community building, some combination of these, or something new altogether.
• Idiom – How does the listener experience the content? Interviews with different people, round table of the same personalities, a single speaker off the top of her head, a single speaker answering questions from listeners, one or more speakers working from a script, etc.
• Structure – How long should it be? Should it be broken in to specific segments (e.g., old news, upcoming announcements, feedback)?

Great, that’s pre-production. What about production? How do you make that good? Here it’s more a question of craft, which means there are common best practices that can be followed:

• Use good microphones. The value of “good” varies: you don’t have to use Daniel’s $300 microphone, but you definitely shouldn’t use your laptop’s built-in mic, since it’ll pick up room noise and possibly the laptop’s fan. In a pinch, the handheld USB mic from your Rock Band game is better than nothing.
• Try not to sound like Skype. It’s disorienting to have the full dynamic range of the locally-recorded speakers paired with the compressed, tinny, and sometimes flange-y sound of someone on Skype. We’ve become accustomed to it from old TV and radio where people would call in on their phones, but if all participants record themselves locally with something like Audio Hijack Pro, we can fix it in post.
• Watch your levels. If you clip (i.e., your signal goes over 100%), you can’t really fix it in post.

Finally, post production. The step everyone seems to think they can skip, either because it’s too hard or because they don’t care (the first is untrue, and if the second is true I don’t think you should be podcasting at all). Audio editing software is not hard to use, and get you results quickly. Among the things you can do:

• Mixing. If all participants recorded on separate mics (or hijacked their local audio so you didn’t have to rely on the Skype version), here’s where you bring them all into the same room. Dick Wall of the Java Posse subtly moves each speaker a little bit right or left in the stereo field to create a sense of relative space. This is a trivial 10-second task in Audacity or GarageBand.
• Normalize. Recorded too low? Have one speaker who was far away from his or her mic, such that either you can’t hear them, or you have to turn up the volume so loud that the rest of the speakers are uncomfortably loud? A quick trip through The Levelator fixes that.
• Music. Having an opening theme, and music between segments, is immensely comforting to listeners. It’s a perfect framing device, and there are lots of royalty-free loops in iLife and on the web.
• Introduce your episodes. Hands-free listeners will thank you for giving an episode number, name, and/or date right at the top of the show.
• Tagging. iPod/iPhone users will see your podcast as a list of episode titles, usually cut off after 20 characters or so. If every episode’s title starts with “The Awesome Amazing Apple Podcast…”, users won’t be able to tell which is which.

Don’t Listen to That, Listen to This!

So I’ve done a lot of complaining. Now it’s time to hand out some plaudits. Here’s a look at my podcasts window in iTunes:

Yeah, pretty telling that there are three Cocoa developer podcasts that I subscribe to that iTunes has stopped downloading because I haven’t listened to them. But scroll down and we’d find some good ones (at least given my own personal tastes… your mileage will of course vary based on your own interests):

• Skeptoid is probably the best one-person podcast I listen to. Host Brian Dunning puts in a lot of time upfront to research and write a script, which lets him be witty, thorough, and most importantly of all, accurate, which is crucial for his cause of debunking silly and sometimes dangerous pop culture beliefs.
• Rear Vision is kind of a cheat to include on this list (it’s a weekly radio program from Australia) but it’s a great place to take inspiration. They have a gem of an idea — seeing current events through the perspective of the decades of history that led up to them — and narrate the show with the help of experts from around the world. Maybe you and I couldn’t do this without making it our day job, but it’s at least another way to think about bringing together multiple perspectives and having a point. In a related vein, a college professor friend of mine is trying his hand at podcasting by turning his lectures into a History of the United States podcast that starts not with Henry VIII and the Puritans (like my 8th grade class did), but with prehistory, archeology, and anthropology.
• ANNCast gets high marks for longevity, having been podcasting regularly since 2009. Their preferred format is an interview with one or more professionals in the anime industry, and they noted in a recent show that they’ve unwittingly been creating an oral history of anime in America, getting recollections from some of the people who brought the form to the US (and some of whom, like Robotech producer Carl Macek, have since passed on). Saul Mora’s interview-driven NSBrief may be doing the same thing for Cocoa development, and deserves our admiration for that.
• Reisen Goes To School By Bus / Eroge Podcast is an example of a fan-made, low-tech podcast with high aspirations and unique content. Host Greg (@thedigitalbug), has a deep knowledge of Japanese visual novels and eroge (“erotic games”… think “Choose Your Own Adventure” with porn and tragedy). He splits his show into distinct segments — last month’s news, a game review, upcoming releases — broken up by music he probably doesn’t have the rights to but that’s awesome nonetheless. He’s got a bit of an accent but is a very conversational and idiomatic speaker, well-versed in the in-jokes and jargon that his audience appreciates. This show is the very epitome of “there’s nothing else like it.”
• Who says podcasts can only be non-fiction? Anime reviewer JesuOtaku has been producing the Fruits Basket Audio Drama, in which she’s adapting the manga Fruits Basket as an old-style radio show, complete with original music, sound effects, foley, and an extensive voice cast, all amateurs or semi-pros. The quality is truly outstanding. While it’s technically not a podcast — owing to her experience as a reviewer for That Guy With The Glasses, she initially posts new episodes as a video <embed> — she also posts regular MP3s that I’ve manually assembled into an unofficial-but-OKed-by-JO podcast feed XML of the show. (Full disclosure: I appear three times in the show as an extra, most recently as the bus driver that takes Tohru to Momiji’s vacation home)

Extra bonus disclosure: I used to have a podcast of my own. The Annotated Alchemist ran from 2005-2008. I pod-faded because 2008 got busier than I could handle (switching career to iPhone development, co-writing a book about it, dealing with a child’s ASD diagnosis, moving to Michigan). The show was an episode-by-episode critical analysis of the anime series Fullmetal Alchemist, based on the idea that there were too many anime podcasts consisting of “a bunch of kids talking crap into a laptop mic in the basement” and that I wanted to go way deep on one topic that I was really focused on. I split the show into specific segments: a summary of the episode, a discussion of the themes and craft of the show, listener feedback (I had a SkypeIn number that listeners could call with comments and questions… this gave me a variety of vocal tones that as a one-man show I couldn’t otherwise achieve), and a closing list of upcoming conventions with appearances by the show’s voice actors. The show’s site is gone but I still have the old episodes… they’re not great, but I could put them up on my Dropbox now, I suppose? Anyways, I had a specific goal in mind, and while it was a significant workload (2-3 hours to write each episode, 2 to record, 2-3 in post to mix in audio from the show or listener calls where I tossed to them), I was more or less able to realize my initial vision in some ways (the quality of the episodes themselves) if not others (keeping up with the weekly [adult swim] broadcast, finishing all 51 episodes).

But maybe there’s a simple rule at work when it comes to podcasts: anything worth doing is worth doing right. Hopefully, the quality of Cocoa podcasts will soon catch up with their quantity.

• All-Day iPad Productivity APIs Workshop – code
• Core Audio in iOS 6 – slides, code
• Mobile Movies with HTTP Live Streaming – slides, iOS code, Roku code

For CocoaConf San Jose on April 18, I’m bringing back the All-Day Core Audio Workshop for one more go-round, so get in on that if you’re interested.

I also had time left over at the end of my regular Core Audio session in DC… with a few judicious cuts, I could carve out 10 minutes or so for an introduction to AudioBus. Anyone interested in that?

I’d hoped we’d see an Apple TV SDK by now, and since we haven’t, I’ve gone looking for something else to do. I bought a Roku 2 XS Player (just in time for the Roku 3 to come out, wouldn’t you know), since the Roku platform is highly welcoming of third-party developers, and features a broad selection of third-party content (including, of course, another means of getting my Crunchyroll fix).

Aside: Notwithstanding the Amazon affiliate links in the above graf, I assumed I’d need to mail order the Roku from the company itself. A week after it arrived, I was picking up an iPod touch for my Mom at a Meijer, and saw multiple Roku models on the shelf. And this was at a fairly remote store (Cadillac, MI). To my surprise, it may be easier to find Roku than Apple TV at retail.

Think Different

The Roku is interesting in that they’ve clearly set out their own value system and aesthetic, going their own way rather than just copying Apple (like a certain slavish imitator we all know in the phone and tablet business). After using both the Apple TV and the Roku for a while, I like a lot of Roku’s choices better. Maybe nothing sums it up better than the remotes:

Yes, I forced the perspective here a little bit, but a straight on shot doesn’t do justice to the fact that the Roku remote is much larger than the Apple TV remote. This is a good thing. The Roku uses RF, which doesn’t require line-of-sight, and therefore lets the Roku be placed completely out of sight, even attached to the back of the TV. It’s about the size of a Wiimote, and the sideways orientation of the A and B buttons are clearly meant for potential service as a game controller. It has a built-in accelerometer (hence the Wii-like wrist strap) which also serves to wake up the controller when you pick it up. The Roku 3 adds a clever feature that lets you plug headphones directly into its remote for private listening. The Apple TV remote, on the other hand, requires a line of sight, is clearly unfit for most gaming (claims of Apple’s presumptive dominance of console gaming notwithstanding), and with Apple’s pronounced fetish for miniaturizing things that don’t need to be miniaturized, the one thing it does best is get lost in seat cushions.

There are two philosophies at work here: one is trying to build a great product, the other is indulging a “hobby”. Face it: without AirPlay, the Apple TV would be a little black plastic turd.

I Can Haz SDK?

The reason I’m interested in Roku is for my streaming work — more on that another time — so it was easy to figure out what I wanted to do for an initial project: bring up some of my streams on the TV.

To do this, I downloaded the SDK. This turns out to be a skippable step: there is no SDK, per se, at least in the sense of a toolchain and libraries that you have to have on your development machine.

To develop a Roku app (er, I mean, a Roku “channel”), you assemble resources (scripting code, images, metadata) in a specific folder structure, zip it up, then upload it to the Roku box via a web interface, which compiles and installs the channel. To debug running code or to see your compile errors, you just telnet to the Roku on a specific port. While there is an Eclipse plugin and a Makefile, they’re both conveniences. There is also a biftool command-line executable that I haven’t needed, and it’s a good thing too, because it depends on the Boost library that is supposedly provided by MacPorts, but like most dependencies on these open-source dependency manager systems, it doesn’t actually work out of the box for a lot of people, myself included. For now, not a problem.

The SDK download does provide a bunch of sample code, but not documentation. The documentation is in a wiki on Roku’s developer site, which is somewhat unfortunate in that it can’t be easily browsed offline, isn’t easily searched, and isn’t integrated with syntax-highlighting text editors and documentation viewers. There’s probably a nice opportunity here for someone who wants to write the first good Roku SDK book… which is not me, because I want to focus on streaming instead of writing for a while (which is why I’m on this adventure in the first place).

The UI components make sense for what a Roku is, and again, they’ve clearly gone a different way from Apple. The various “list styles” of the ifPosterScreen offer practical ways of navigating with a right-and-left action through series or episodes by billboard image, putting the current selection front and center and making it much more obvious than the thin highlight rectangle of an Apple TV. The use of top-of-screen menus and breadcrumbs are also unique and practical.

The CocoaConf Demo Channel

I’ve been doing a session on HTTP Live Streaming at CocoaConf that I’ve gradually been adding to — and livestreaming the talk itself when network conditions permit — so I decided to take the HLS streams I’d created for that talk and try to get them working on the Roku.

This, after all, is one of the biggest advantages of the Roku: its preferred formats are the usual flavors of H.264 video with AAC or AC3 audio, and it uses HTTP Live Streaming for streaming video, either live or video-on-demand. It’s no surprise that so many content providers with iOS apps are also on Roku, because most of the heavy lifting is in the encoder room, and the client-side work needed to get those apps working on the Roku is insubstantial.

How easy is it? I can’t say I’m exactly delighted to be working in a language that bills itself as being closely modeled on Visual Basic (that would be Roku’s own “BrightScript” language), but in maybe 8 hours of arbitrary copy-and-pasting from the sample code, I got my app working.

I captured a video of the app and posted it over on teh Plus (Google’s got money; they can afford to host my video). What should strike you as surprising is that this channel is about 150 lines of copy-and-paste code:

main.brs (sorry, used to have an iframe for the code here, but it didn’t scroll on Mobile Safari)

On the one hand, I’ve been doing curly-brace C-derived languages (or just plain C itself) for 15 years, so trying to revert to the style of these scripting languages is not easy. But then again, the whipitupitude of this stuff is not to be overlooked: I would have been hard pressed to have gotten as much done in my first 8 hours with the iPhone SDK, and it too had decent sample code and documentation to crib from.

Moreover, the whole point of these devices is to deliver content, so the actual functionality of a given app should mostly be to find video and then get out of the way when it starts streaming. There are non-full-screen APIs for video, so in theory you could get fancy and squeeze back your video and surround it with something else (e.g., a related Twitter feed, updating in real time), but still, I don’t know if anyone should be planning on porting Office or emacs over to the Roku. And if the apps are simple, then maybe the rigor of the more formal programming languages won’t do as much for you?

Still, if Roku ever does offer a C API, I’m in.

Anyways, the point of all this was to show that the Roku offers a great way to take the HLS content that many providers are already developing for iOS clients, and to put it on the big screen with an approachable SDK, on an inexpensive box that’s backed up by a company that actually wants to have a wide catalog of third-party content.

I can totally get on board with that.

Attendees of the iPad Productivity Workshop — an all-day class I did for the first time, following a poll here on [Tc]; about new tutorial topics — have already written all the code, but for DC students who want an advanced peek (or anyone else who’s interested), here’s a zip of the project in its various stages.

The “staged examples” is an idea I got from Daniel Steinberg, who swears by it for his classes. The great thing about it is that if someone falls behind, they don’t get lost: they can just skip ahead to the next checkpoint in the code’s progression. In this class, we build an app that can search iTunes, put results in an UICollectionView, and then allows the user to build their wishlist of items as a UIDocument. Along the way, we add in:

1. Copying an item to the clipboard, to paste into other apps
2. Document persistence, with iOS background saving
3. Add to / delete from list
4. Undo of add/delete
5. Save document to iCloud
6. Import documents from other apps (e.g., receive a wishlist as an e-mail attachment or Safari download)
7. Export wishlist to PDF and send it to mail, printer, other PDF apps

It turns out to be more than I can teach in 8 hours, so with the stages, we just skip ahead to a good starting point. In Chicago, we started at stage 3, with the search feature working and the split-view for wishlist browsing set up in the storyboard but not yet implemented. The code might get a few tweaks before DC — possibly sorting the .wishlist files in the master table, and supporting pasting into the wishlist — but overall things are in really good shape.

As for my other talks, I did Core Audio in iOS 6 and Mobile Movies with HTTP Live Streaming again. They’re good talks and pretty polished at this point, but they were in some ways meant as a placeholder in case Apple gave us something new to play with in time for CocoaConf. Obviously that hasn’t happened… it’s been a real boring Q1 in Apple-land.

• Core Audio in iOS 6 – slides, code
• Mobile Movies with HTTP Live Streaming – slides, code

If you’re here for the Core Audio, note that this is the corrected, works-on-iOS-6.1 code that I discussed in a previous blog entry.

I went through the e-mailed errata I’ve received for Learning Core Audio and sent off an update to Pearson, although it’s not yet up on the book’s home page. The biggest fix here is a typo in the chapter 8 audio pass-through for Mac, which sometimes causes bad distortion depending on your selected input device. The bug was caused by mis-counted timestamps and apparently a race condition of which audio unit (input or output) got called first… all owing to the fact that I had set -1 as a flag value, and then did a comparison against 0 instead of -1. Anyways, if this is something that bit you, watch the book’s home page for an update, or just grab the updated code from my Dropbox. The zip has a CHANGES.txt with the other code fixes in this update.

The other thing I had to correct was my ambitious pitch-shifting web radio demo that I developed for my CocoaConf Portland talk. The effect stopped working in iOS 6.1, and fixing it led to a long engagement with the coreaudio-api mailing list and the use of an ADC support incident on my part.

This app works by using an Audio Queue to play packets provided by an Audio File Stream, based on a web radio app we develop in my one-day Core Audio Intro course. It then uses iOS 6′s new AudioQueueProcessingTap to get a callback with decoded samples right before they’re about to be played, and applies an effect to those samples. To do this effect, I have to use an offline AUGraph, as explained in the afore-linked CocoaConf Portland blog entry.

Turns out that what we count as “an effect” isn’t cut and dry. Technically, AUNewTimePitch isn’t an effect at all; it has type kAudioUnitType_Converter (and not kAudioUnitType_Effect). This matters because it turns out there’s an unstated (probably undocumented) contract that effect units produce and consume the exact same number of samples, but converters don’t necessarily do so. That’s not a problem when you’re reading from a file (you can always ask for more data than you produce, at least until you hit the end of file), but it’s potentially a problem when you’re getting handed AudioBufferLists from the AQProcessingTap. I say “potentially”, because while this obviously wouldn’t work to do time-shifting — you can’t play audio faster than the web radio stream sends it to you — I’m only pitch-shifting.

On the list, Apple’s Bill Stewart suggested I buffer up some silence before adding the web radio samples to the buffer, so that I’d be protected if AUNewTimePitch ever needed more samples than had been saved off from the AQProcessingTap callback. So I did this, and it’s all well and good.

But it didn’t fix the problem, because my real problem was that I was forgetting to increment the time-stamps, so only my first call to AudioUnitRender() did anything, and the rest no-op’ed because the samples for time 0 had already been produced. That’s right, my second timestamp-related bug in a week. Oops. One of those things where you reach the end and wonder how the code ever ran correctly on 6.0 in the first place.

One other change in this demo is that 6.0 and 6.1 changed the so-called “topology” of the data provided by the AQProcessingTap callback. In 6.0, the data is interleaved: the AudioBufferList has an mBufferCount of 1, meaning right and left samples are interlaved in one AudioBuffer. In 6.1, the callback gives you 2 buffers in the AudioBufferList, so I had to change the technique where the ABLs are saved off for use by the AUGraph; they had been in a single pointer, now they’re in an array.

This is all summarized in a long post to coreaudio-api, which also covers a related thread on the list that AUNewTimePitch seems to boost levels and cause distortion (got a bug report in on that, FWIW). I’ve also posted a code update for my AQTap stuff — here’s the zip — which also sets up a second AQTap demo that uses a genuine effect unit, AUReverb2, and therefore avoids the buffering complexities that I dealt with for the pitch-shifting demo.

Done cleaning up old messes. Time to create some new ones.

Think back a bit: when the iPhone first came out, it was announced in January and went on sale in like July (months are approximate… I’m trying to avoid using seasons for fear of Northern Hemisphere bias. You’re welcome, Australia.) For a few years, iPhone was a mid-year product, with a corresponding iPod touch coming out later in the year. Then the iPad came out in early 2010 and was updated again in early 2011 and early 2012. But now, all of these products got late-2012 updates. So… what does that leave for the next six months?

Macs? The iMac got updated in late-2012 too, and the laptops have moved to a mid-year schedule (with an announcement at WWDC), better suited to back-to-school buying. Even if we do get the Mythical Modern Mac Pro in the next few months — and I am by no means optimistic about that — it’s a niche product.

And as developers, everything interesting is now a once-a-year update to iOS at WWDC. OS X is supposedly moving to an annual schedule, so that should be getting previewed soon (with an eye to mid-year release), but the simple fact is that very few of us can get Mac programming gigs, so it’s not worth the time of tracking an OS X beta and its new APIs very closely.

If Cocoa development is indeed a cargo cult — and it’s a pretty comfortable cult to be in if so — then the planes aren’t coming back with new stuff until July. Literally the only thing I can imagine happening before then is an Apple TV SDK, and there are few signs of that happening soon, or ever.

All this caught me a few months ago when I was setting up my schedule for the various CocoaConfs in March and April, and while I usually like to do new talks to keep things fresh and interesting, both for myself and attendees, there didn’t seem to be anything really worth doing a new talk about. iOS 6 didn’t change that much, and it’s been seven months since we got our first betas of that. Revolutionary changes like storyboards and GCD are years in the past (although you should all buy Daniel Steinberg’s book on Storyboards when it hits the iBookstore on Saturday). In the end, I had CocoaConf use my most recent talks as placeholders, and now I think there’s little chance I’ll swap in anything else new.

My restlessness — plus a consulting lull due to a client freeze (yep, I’m available for like the first time in two years) — has me looking at new stuff to get into, beyond the Apple ecosystem (though not too far). Of course, there’s livestreaming, which I’ve talked about enough to have its own category on this blog, and won’t belabor further until I can get more of my research and pre-production work done.

On the Apple TV SDK issue, I’ve capitulated and bought a Roku, which is hooked up to my HDMI-deprived downstairs TV. I’ve also joined Roku’s developer program, with an eye to trying out their SDK and seeing what it takes to develop streaming apps for the platform. Since HTTP Live Streaming is Roku’s recommended way of streaming content, I should be able to repurpose the HLS work I’ve done on iOS. And in the Big Dream, my livestreaming plans combine with custom apps for iOS and Roku and… well, let’s not get ahead of ourselves.

You can get a feel from downloading new channels on Roku what an Apple TV app store might feel like. The system has been designed to allow for consistent navigation with the remote — many apps use a top “strip” of categories that can then be entered by doing an arrow down. Within content areas, boxes represent either content, collections, or even actions… it all depends on whether you have a few things to show (TWiT), a lot (Crunchyroll), or seemingly infinite (Netflix).

But it also shows what’s likely holding up an Apple TV SDK: a lack of killer content. Beyond the ubiquitous Netflix and Hulu, what distinguishes Roku is niche content: K-dramas, religious shows, workout videos, and so on. Apple would never launch a third-party API if that’s all they could get; remember, back in the day, they used the iTunes Music Store and crappy pop music to flog the iPod, not idiosyncratic little podcasts.

It’s great that you can stream all the video apps from iOS to an Apple TV with AirPlay, but given that’s the only thing that distinguishes it from a Roku, does that basically make the Apple TV just an expensive HDMI-out cable (and not even as good, as AirPlay is highly dependent on your wifi performance)?

Even though both platforms have apps/channels for three of the big four US Sports (MLB, NBA, NHL), neither can show locally blacked-out games, which takes away much of the point of subscribing to such a service for a lot of people: you can’t watch the home team on it, so it’s only useful if you’re broadly interested in the sport, or if you’re a devoted fan of an out-of-town team. I kind of wonder if Apple sees breaking the blackout as one of its own requirements for seeing Apple TV as more than a hobby, and to do that, they’d basically have to revolutionize the industry (or wait for someone else to do it for them… Google maybe?)

As for the Roku SDK itself, I took a couple hours to get set up, and it looks like tough sledding. The development options are a command-line biftool utility that doesn’t work on Mac (thanks to libraries it expects but doesn’t find in MacPorts), or an Eclipse plug-in. Apps are written in a scripting language called BrightScript, which is advertised as resembling Visual Basic (groan), and all the documentation and sample code is on the web, without an all-in-one download.

So… probably gonna be a while.

The other SDK I hope may pull me out of my funk is the Ford SYNC/AppLink SDK at developer.ford.com. After a long ramp-up period — I originally mentioned going to a developer event promoting the Ford SDK back in October, 2010 — Ford now has actual iOS and Android SDKs for talking to the AppLink, allowing drivers’ apps to use the in-car display and voice recognition systems.

I have long wanted to voice-enable Road Tip, since my whole design concept for the app was to make its visible interface as minimal (and thus as minimally distracting) as possible. Its small number of list views would map more or less one-to-one to the D-pad-controlled right-dash display in our Ford Edge, and it’s even more appealing to consider banishing the screen entirely and just work by voice, letting the app read off upcoming exits and their distances, or finding your favorite brand by voice command. Right now, Road Tip badly needs some updating for iOS 6 and bugfixes, and a price model more in line with user expectations in 2013, but its low sales don’t justify further work. SYNC-enabling it might give it a second lease on life. Probably in the next six months, I need to either do that, or pull it from the store altogether.

Ford’s iOS download is packaged as a .a binary, header files, and two sample Xcode projects. An emulator for Mac and Windows is in the works; apparently, you can also test on real hardware with a USB stick and your app, but since my car can’t support AppLink, I’m waiting for the emulator.

I feel like I did back in 2008, when the iPhone SDK came out and I flipped the switch from Java to iOS. I should be able to keep going in iOS for a long time, but could something else catch my eye? More likely now than it’s been for a while.