Archives for : podcasting

Talking Streaming with the iPhreaks

I’m pleased to have been asked to be a guest on this week’s episode of the iPhreaks podcast, during which we talked at length about HTTP Live Streaming on iOS.

I was really happy that we were able to convey the sense that streaming is a multi-disciplinary and holistic pursuit, tying in very different kinds of expertise on the client, the server, networking, encoding, content production, and business concerns. That’s something I tried to stress in my CocoaConf HLS talks. The irony is that my speaker feedback from those sessions would sometimes say “more of the iOS part, please”, and the fact is, creating an MPMoviePlayerController or an AVPlayer is easy compared to some of the other tasks involved — encoding for different bitrates, transcode/transmux for non-iOS clients, security, etc. To say nothing of acquiring or creating something worth streaming in the first place.

So, good chat, and quite a brain-dump for a 45-minute podcast. The guys had lots of relevant expertise in encoding and hosting, which took the conversation in directions it needed to go. So, thanks iPhreaks. It was fun.


Author and speaker Daniel Steinberg always keeps his talks fresh, revising them and making changes every time he gives them. CocoaConf DC 2013 was at least the third time I’d heard his keynote “A Pocketful of Patterns” (whose framing device is based, in part, on my own skepticism about design patterns), but he caught my attention with this little pattern, showing a problem and a good solution:

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:

Tweet from invalidname: "Yay. @dimsumthinking finally told the truth about most developer podcasts: they're too long, unfocused, and unedited. #cocoaconf"

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.”

Continue Reading >>

Again with The Six Steps

About 10 minutes into Java Posse 241, an unconference session on design, Joe Nuxoll almost pulls the usual “developers talking design” chat into a breathtakingly new perspective. Really close. Picking up on an anecdote about 37signals’ creation of Rails as a tool for what they wanted to do, he points out the idea of going back to first principles:

  • What do I want to accomplish?
  • What can I do that will accomplish that?
  • How do I do that?

He points out that not everything has to be a webapp or a library; that there could be a human process that’s more practical (cheaper, effective, etc.) than building something electronic.

And then the conversation goes another direction. But this so reminded me of Scott McCloud’s exceptional metaphor and discussion of “The Six Steps” of the creative process, in Understanding Comics. McCloud presents a linear progression of choices and concerns:

  1. Idea/purpose – What am I trying to accomplish?
  2. Form – What form will my effort take (a comic book, a website, etc.)
  3. Idiom/genre – How do I address the recipient (fiction vs. nonfiction, online community vs. news site). McCloud says this is “the ‘school’ of art, the vocabulary of styles or gestuers or subject matter.”
  4. Structure – How the work is arranged and composed, “what to include, what to leave out” (the latter being a far more important choice than is often realized).
  5. Craft – The actual work of getting the thing done: problem solving, use of skills, etc.
  6. Surface – The immediately-perceivable traits, like polish or production values.

What’s perhaps most breathtaking the first time you read Understanding Comics is McCloud’s narrative which portrays the reality that almost nobody starts with step 1 and proceeds to step 6. In fact, it’s far more common to go backwards: to see just the surface gloss of something and try to mimic that, with no understanding at all of the decisions that inform the rest of the work, and how they depend on each other.

In our realm, this pathology is highly obvious. If McCloud’s version is a kid tracing Wolverine onto lined notebook paper and declaring “I can draw as well as a professional!”, then surely our equivalent is the UI “skin”, like the hackery that can make a Windows or Linux desktop look like Mac OS X, but can’t change the fact that everything below the surface is built up with the respective ideas of those operating systems.

This is why I’m convinced Linux can never succeed as a desktop OS. When I used GNOME as my desktop for a year back in 2001, I commonly complained that the desktop gave me at least a dozen places to set my visual theme, but setting the damned clock still required me to jump into xterm and do sudo date -s ... I haven’t used it since then, but I wonder if they’ve even gotten inter-application copy-and-paste working (to say nothing of drag-and-drop). McCloud’s narrative shows genuine artists eventually working all the way back to step 1 or 2, asking “why am I doing this”, and proceeding forward, making informed and purposeful decisions about idiom, structure, and craft. It’s hard to imagine the Linux community having the wherewithal and discipline to see through such a process, when they’ve proven themselves willing to fork their code at the drop of a hat (or, more accurately, the outbreak of a Kirk-versus-Picard flamewar). The result is something that’s so baroque and self-contradictory it isn’t even necessarily ideal for hackers, and there’s little hope of this community ever deciding to build something their moms can use.

A lot of projects make bad choices of “form”, and doom themselves from the start. In the 90’s, there seemed to be people who believed that every activity worth undertaking should be done in the form of a startup company. As it turned out, fairly few endeavors are well-suited to that approach.

Today, we see people falling over themselves to make everything into an iPhone app, even when it’s not appropriate. If most of the value of your project comes from data provided via servers you own or operate, it’s likely that a webapp is more appropriate than a genuine iPhone app. Clever use of iPhone CSS can produce webapps that behave much like native apps (the Facebook webapp is still as good as its App Store equivalent), can be updated for all users at any time, and can be adapted to other devices without starting over at square one (compare to the challenge of rewriting your iPhone app for Android, Blackberry, Windows Mobile, etc.).

If anything, many of the great iPhone apps are heralding a resurgence of the “productivity app”, which Broderbund founder Doug Carlston defined to Tim O’Reilly as “any application where the user’s own data matters more to him than the data we provide.” Any iPhone app worth writing is going to involve some significant user data, whether that’s classic user data like their mail, their files, audio they’ve recorded… but also data as simple as where the user is when they run the app. After all, the hundreds of thousands of records in the the restaurant-finder app’s database is useless to me; what matters is finding what I like that’s close to where I am. In other words, the data has no value until it gets those crucial inputs: where I am and what I want to eat.

Now here’s an interesting mental exercise: where would what we consider to be “design” fall in McCloud’s six steps? At first, I made a cursory decision that it was just part of step 5 (craft), as it was part of the doing of the work. That’s clearly wrong, as what we think of as design (and I’m mentally considering varying creative exercises I understand, like book writing, screenwriting, TV production, podcasting, software development, etc.) clearly encompasses the step 4 (structure) decisions of how to arrange the content. And it probably touches on step 6 too: deciding whether to use the brushed metal or plain UI look, whether to shoot in SD, HD, or on film, is a design decision as well. But would we consider step 3 (genre/idiom) to be part of design? I think not. I think that’s a decision that precedes design, one that informs just what it is we’re going to be designing (a educational game versus an electronic series of lessons, historical fiction versus documentary, etc.).

Still, I think it’s important not to make too early, too easy assumptions about the major decisions at the front of the process. “Why am I doing this” is the most important question to ask yourself: it shouldn’t be skipped.

Journey Through the Secret Life of Phones

You would think that with the iPhone 3G’s release last Friday, the posting of iPhone OS 2.0, and the final release of the iPhone SDK… that between these events, the NDA that prohibited public discussion of the SDK would be lifted.

And you would be wrong.

Apple has told publishers — including but not limited to the Prags, who are publishing the iPhone book that I’m working on — that the NDA was not lifted on Friday. And that they’re still working it out.

Ergo, despite having lots to say here and elsewhere about iPhone SDK details, I’m still sitting on my hands. Maybe I should start just banging out drafts in TextMate while the ideas are fresh, and mass-post them later when the NDA drops. If it drops. Yeah, it would be crazy to stay NDA indefinitely, but we’re already in CloudCuckooLand to be upholding an NDA on an SDK downloaded by over a quarter million developers worldwide.

Bill, Marcel, and I did do an interview last night with Late Night Cocoa, which summarized the major APIs of the iPhone SDK and gave our impressions of the development environment. Even edited down, it’s going to be a long episode, and at any rate, it’s going to be on the shelf until the NDA drops. Alas.

The App Store is, perhaps as expected, a highly mixed bag. Along with really slick apps — I’m very impressed with the Pandora Radio client, and will be buying Starmap before we head up to the woods of Northern Michigan next week — there is quite a bit of abject junk. You’ve probably noticed the hundreds of public domain books wrapped by a one-dollar reader app (as if users couldn’t just hit Project Gutenberg with Safari), the appallingly trivial game apps (perhaps ported to Obj-C from the original Fortran listings in Creative Computing… I’m looking at you, Handy Randy), and four different versions of an iPhone “flashlight” (i.e., a completely white screen, thereby turning your iPhone into a de facto flashlight). On the latter point, I’m sure that the one from Erica Sadun is good-natured and offered with the best intentions, since she’s one of the pioneers of third-party iPhone app development. But the other ones that cost a buck each… not so much. In fact, I believe this app requires no code and not even any work in IB: showing a blank view is kind of, well, default behavior.

By opening things up wide to all would-be developers, the App Store has the flavor of the podcasts directory: a wide variety of subjects and an equally large large variance of quality. Consider that the podcasts range from professional-quality audio and video to a kid in his basement talking into his laptop’s internal mic about how cool last week’s Naruto was. The App Store has pretty much the same jewels-and-junk mix, with the key difference that nearly all podcasts are free, while only a minority of the apps are.

I’ll admit — I had expected the initial app quality level to be higher overall than it’s turned out to be. Some of these apps could be written in a day, and might have been. The apps I’ve planned to do — once I get time away from editing and writing the book — are more ambitious than most of these (thnk “mobile podcast editing suite”, not frickin’ Nim), and now I’m wondering if I should take a shot at writing a simple app in a day, posting it, and seeing if anyone bites.

In fact, some of the paid apps duplicate programming examples we have in the book, like the generic shopping list app, a simple version of which I created as the example of using the SQLite database. So one thought I’ve discussed with our editor is that we might put one or more of the book examples on the app store for free, with an “about” link taking you to the book’s home page and the source. The pitch being: “Learn how to write apps like this!”

Of course, we can’t do that until the NDA drops. Tick, tick, tick.

Holy crap, Tune Studio is shipping?

So, like a month ago, I was thinking I should blog with the bold prediction that the Belkin Tune Studio, which I’d mentioned once or twice, was never actually coming out. In a nutshell, my thinking was that having slipped over a year was a bad enough sign (software trouble interfacing with the iPod, perhaps?), but that more importantly, the annual refresh of the iPod line was looming for Fall, and this year’s could plausibly be the refresh where the classic iPod architecture gets dropped in favor of Touch devices. The Tune Studio doesn’t work with the iPhone or iPod Touch, presumably indicating that Belkin has put all of their eggs in the classic iPod basket, and limiting their viability to the continuing relevance and existence of that line.

Belkin Tune Studio

So, I’m so damn smart, right? Then how come the Tune Studio page now has a big ol’ “ADD TO CART” button, replacing the “coming soon” that had been there for so long? Surprise, surprise, they actually shipped.

And yet… I’m not getting one. It would have been really useful for the three conferences where I was recording sound this year: Mobile & Embedded Developer Days, the Java Posse Roundup, and JavaOne. But those are all done now, and I’m not attending any more conferences in any authorized-to-record-audio fashion for the rest of the year. Besides, if I need something like this, instead of a plug-in mixer, maybe I’ll get a portable recording rig, like the Belkin Podcast Studio.

Yeah, if that ever comes out.

C4[1] videos available

Wolf Rentzsch, one of the rock stars of the old Mac Hack conference, launched the C4 conference in its absence. It’s already the premiere indie Mac developer conference, and I hope to go this year.

This week, he announced that videos of the 2007 sessions are being rolled out, one a week.

It’s great, but I just don’t see myself having time to sit and watch online for that length of time. Given the periodic release of the sessions, this would ideal as a video podcast. Hopefully someone is transcoding from FLV to low-bandwidth iPod-targeted M4V and setting up a feed right now…

TuneStudio not, in fact, looming

Despite my previous speculation that the Belkin Tune Studio was about to release, CES and MacWorld have come and gone without an actual release.

I think. It’s hard to tell. A press release says it’s available now in the US, but the product’s web page still says “coming soon”. Amusingly, this iPod-based audio mixer picked up a CES 2008 Best of Innovation honor from SlashGear… the comedy being that the Tune Studio was introduced at CES 2007, and picked up various honors back then. Pretty soon, it’ll be eligible for vaporware awards.

Apparently not deterred by not shipping their last clever iPod-based product, Belkin sent out a press release inviting podcasters to come check out the Podcast Studio (or is it the “Tune Talk Stereo”, as the press release calls it?), a device designed to wrap around your iPod like a sleeve and provide audio in (supporting 1/4″ and XLR mics!) and a compressor/limiter.

Belkin Podcast Studio (or Tune Talk Stereo?)

The prototype apparently shown at MacWorld didn’t work with all iPod models (for example, the 80GB Classic is supported but the 160GB is not), and a Wired blog says they’re shooting for a June release. Of course, that’s only a few months before Apple’s annual refresh of the iPod line, so if they slip, maybe they’ll hold it to ensure compatibility with the new iPods, and ultimately, it’ll be a race to see what gets released first: Tune Studio, Podcast Studio, Duke Nukem Forever, or Chinese Democracy.

If any of my dozens of readers saw either device on the CES or MacWorld show floor, I’d love to hear comments…

TuneStudio looms?

Could the vaporous TuneStudio, mentioned previously, be looming for a MacWorld or CES release? I’ve been stalking its web page in hopes of just such a release, and noticed that today the list price was reduced from $399.99 to a “special discounted price” of $249.99, matching its originally announced price. As of this blogging, you can still see the higher price in Google’s cache. The fact that they’re bothering to update price data in the page, and offer a special price that is presumably time-limited, might speak to a release soon.

Belkin web page showing $249.99 price for Tune Studio

Speaking of previously mentioned gadgets, my Bella Final Cut keyboard arrived yesterday. So far, I haven’t put it to significant editing use, so I can’t say too much yet about how well it performs at its intended task. It doesn’t come with built-in settings for Soundtrack, although the jog wheel by default rolls the playhead one tick in the timeline, which is a pretty appropriate and useful action. A very quick glance at Final Cut shows that jogging and shuttling through a video clip in preview “feels” right to me… like using a tape deck, albeit with a lot less physical resistance form the shuttle. I’ll ack back on this after doing some serious FCE work with it.

In the meantime, it’s pretty reasonable for everyday typing, though moving the arrow keys down to the wrist rest is a pretty harsh compromise. I’m willing to just abandon the arrow keys in favor of emacs keybindings, which are quietly supported by many OS X apps (BBEdit, XCode, and Mail among them), but don’t work with many modifiers, such as command-left-arrow to go back to the beginning of a line. The keypad should be able to fill in as a cursor movement device, but it turns out that the Num Lock key in Mac OS X is surprisingly non-standard. Look at Leopard’s help when you look up “Num Lock”:

Leopard help on Num Lock key

The description that only “some applications” support moving around your document with a NumLock’ed keypad is surprisingly unhelpful. How would I know which ones do and don’t? Why is there a difference? Why don’t text areas pick this up for free from the OS?

I built a quick Carbon app in XCode — just an editable text area in a window — and found it didn’t support NumLock… haven’t had time to try Cocoa, but since none of the apps that I found support NumLock are Cocoa, I’m not holding my breath.

I whined about this over in the Apple support forums. It’ll be interesting to see what the answer is.

Belkin’s TuneStudio looks wonderful, but will it ever come out?

I was looking at audio-in options for potentially using my 160 GB iPod for podcast recording, and came across the Belkin TuneStudio:

My goodness, that’s an attractive setup, and the features are wonderful: four inputs, 3 band EQ, phantom power for your mics, built-in compressor, USB streaming in or out to your Mac (so you can presumably use it as a home mixing board, without the iPod), records to the iPod at 16-bit 44 KHz, etc. Works with iPod Classic, iPod 5th Gen, and all nanos.

Only gotcha I see is that it was announced way back in January and still isn’t out. In fact, November’s update to the press release pushes the release date back to January, 2008, and hikes the MSRP from $249 to $399. Unless it’s out on 1/2/08, it’ll miss the shows I need portable gear for, so I’m holding off on ordering until it’s really really available.

But jeez, it looks promising…

Don’t fix it in post when you can get it right the first time

So last night Kelly asked if I was done with episode 26 of my unofficial Fullmetal Alchemist podcast, and I said that I’d finally finished the script after about five hours over three nights. Given the long lull in producing regular episodes (see Developers should be content experts too for why I’m trying to restart), I’d forgotten just how much time goes into it, especially in the very podcast-atypical step of writing a full 15-25 page script for every episode. “I spend a hell of a lot more time in pre-production than production,” I whined.

“Sounds about right,” she replied.

And she’s right, of course. It’s easy to forget when you’ve got all these powerful tools to do so much work for you, but one of the pivotal lessons you learn in film or TV school (we both did the latter), is that you should and will several times more hours in pre-production than in production.

In the old days, that was an economic necessity: studio time (or, heaven forbid, a location shoot) was too expensive a commodity to waste. But when the studio is your laptop, then that budgetary concern goes away. Still, the advantage of pre-production is obvious, if underappreciated: knowing what you’re doing ahead of time always gives you an advantage. In my case, instead of analyzing an episode through the ancient and sacred technique of pulling it out of my butt, and then editing out the “um”s, “ah’s, and dead-end sidetracks, I can instead nail down exactly what I want to say, and get it tracked and mixed with music and clips from the show in about two hours. Plus, my vocal delivery is much stronger when I know exactly what I’m saying than if I were thinking on my feet (though at least one iTunes review complains that it’s “obvious” I’m working from a script, and rushing it, meaning I have some performance-side issues to address).

Even on a round-table style podcast, there’s still a pre-production step of working out a list of topics beforehand, a step that’s openly acknowledged on podcasts like The Java Posse, where they talk about sharing their notes over Google Docs & Spreadsheets. Conversations that don’t at least consider what they’re going to talk about — or indeed, why they’re talking on a podcast at all — tend not to be interesting or make it past a handful of episodes.

By the way, if you want to hear what a breathtakingly good scripted podcast sounds like, try the Todd Rundgren Connection “Brief History of Todd” podcasts. The producers have taken decades of recordings (CD’s, concert bootlegs, radio interviews, etc.) and use a text-to-speech narrator to tell the musical biography of their favorite artist. The narration is never long-winded, they make great use of their audio assets, and despite the project’s massive scope, they keep episodes down to a very listenable 30 minutes. In terms of technique and content, it’s probably the best podcast I listen to.