silent night

Our last episode was about bad experiences with iMovie and frustration with the state of licenses for movie soundtracks. I left on a high, though unlicensed, note and told you about my happy times with the python program 'webkit2png'.

It would have been a fine post with which to end the year if I had included an example. I couldn't figure out how to include the video I made in the course of writing that post and still preserve my anonymity.

I'm back with a new example that pinpoints my location as the northern hemisphere of Earth. I'm comfortable with that.

'Silent Night' was built from 251 ten second exposures taken at one minute intervals on Christmas Eve. The images were post-processed and stacked in webkit with an HTML canvas and getImageData/putImageData.

The sound track 'Silent Night' was licensed from friendlymusic.com for $1.99. That fee got me the rights to include the thirty second track in exactly one personal video uploaded to a 'User Generated Content' web site. My theory is that Google Drive is a 'User Generated Content' web site and that my hosting the file there is within the scope of my license.

Google Drive allowed direct access to the video for a few hours last night. That's what I wanted. This morning, Google gives me a fat HTTP 403. Perhaps this has something to do with copyright police. You ought to be able to get the full video from Google with this direct link. If your browser is a modern one, you ought to be able to skip the wonky flash player and just view the file directly below:


Merry Christmas.

cinema

Yesterday was a rare whole-family snow day. It was actually that rarer thing -- the nearly snowless snow day. The morning's lack of snow and relative leisure gave me a chance to set up a time lapse rig to catch the expected snowfall.

I shoot most of my time lapse movies with a Canon 40D SLR camera. I love the camera, but my time lapse machinery is a little unsatisfying. The camera is about six years old. My Mac appears ready to do tethered shooting with many camera models, Canon included, but not this one. I think this model was too new at first. Now it too old. Canon probably has an free and unscriptable app for this purpose. I'm sure that grownup photographers have expensive software that makes this all go. I don't use the words 'workflow' or 'post-processing' unironically to describe my modest endeavors. I'm not really interested in a complicated solution.

It is a strange sign of the times that my idea of an uncomplicated solution is an Arduino and a transistor. I bought a cheap wired remote for the camera and hacked it and the transistor onto the Arduino. A tiny sketch runs the project. My original project had no user interface. The delay was embedded in the sketch source. Every new project meant recompiling the shutter sketch. Though this sounds clunky, it is no more complicated than using Apple's own 'Automator' facility for this purpose. Who knows? Perhaps the Arduino IDE itself could be scripted with Automator.

I now use a TFT touch screen shield from Seeed (by way of Radio Shack) as a little user interface. That contraption uses nearly all of the available I/O pins on the poor Arduino. Good news, then, that the actual function of the whole bodge -- connecting two pins from the camera -- requires only one.

This assembly of camera, Arduino, touch screen, and transistor worked well enough to get me 497 pictures of the day's precipitation with a 30 second interval between shots. The camera's battery was about three quarters full at the start and the event wrapped up when the battery gave out. I shot from a Duplo rig.

The shooting took about five minutes to set up and ran unattended for the next four hours. These were, by far, the most pleasant hours of the project. The next four hours boiled away in front of iMovie as I tried to put the frames together. I have used iMovie dozens of times to stitch together little time lapse movies for my kids. It is always frustrating but I usually get a movie out of it. Not so this time.

I hadn't used iMovie as much since it was sent off to a reeducation camp for the redesigned iLife '11 suite. I adjusted my workflow and ambitions downward towards and kept going. Yesterday was the first time I tried the still newer 2013 version. It cheerfully upgraded my library and spent much of the rest of the evening crashing.

The basic idea in cinema is that a series of still images can be displayed in sequence in a way that an observer will perceive as fluid and continuous. That's the fundamental concept. The difference between a time lapse movie and a real time movie was once maintained by clockwork camera drive or the evenness of a cameraman's cranking cadence. In the digital world, it exists only in post production.

iMovie treats still pictures, the most basic and primitive element of movie making, as some sort of second class citizen. For years, you couldn't have a still picture on screen for less than .2 seconds. You can't have a title or effect span more than a single frame. Pictures are converted into 'Ken Burns' movie clips by default. The older iMovie 11 let users turn this default off. The newer version has apparently hidden this knob. Both versions let you set the duration of several stills together at one time. The new version seems to have lost the feature that lets you crop a bunch of stills to the same box.

iMovie accomplished a lot in the Power Mac G3 days simply by showing that it was possible to do something with digital video on a consumer machine. Job well done. I believed. Even today, a bunch of clips put together in iMovie usually look better than the raw concatenation of the footage.

It is no longer surprising that consumer machines can handle enough data to string together a movie. Apple themselves distribute a version of iMovie for their telephones and tablets. What is the point of iMovie now? What does it demonstrate? I don't know. Many of the signature iMovie effects seem not much better than HTML5 CSS demos available from Apple and others.

After four hours in front of iMovie, I decided to find a better way to make time lapses. My only rule was that it had to be free, simple, and not involve anything called an 'App Store'. I searched for tools designed to let you make movies with HTML5 and CSS3. There may be a good search result out there somewhere. I couldn't find it among the many articles about viewing videos in the browser with HTML5.

A more complicated query found me webkit2png. Webkit2png was described modestly as a command line tool for making screenshots of web pages. It is much cooler than that. It is a simple python script that uses the python to objective-C bridge to create a webkit view offscreen, load an URL into it, and dump the virtual frame buffer to a file. The screenshots have absolutely no browser chrome, just edge to edge web goodness.

I wrote a simple HTML file that accepts a frame number as part of the query string and generates a web view filled with that image. Titles are superimposed and styled with CSS. Webkit2png turns each of these rendered frames into a PNG. ffmpeg turns these PNGs into a movie. My titles can fade out over as many frames as I like.

There are some rough spots. My movie script is basically a javascript program. I use CSS for titles and transitions, but I'm not actually using the browser animation facility. Each movie frame is rendered by a completely independent webkit instance. Time exists only as a Javascript variable. Rendering is slow. ffmpeg turns 720p PNG files into 720p video at about 30 frames a second. I can render only about 2 frames a second with webkit2png. iMovie may have lost its mojo, but it at least has an interface that looks good in the Apple Store. My approach does not though I think one could be built for Safari with little trouble. Safari has evolving support for 'Web Audio' but this support does not translate directly into a soundtrack story for my movies.

My shell-based workflow is not an alternative to Apple software. It runs in a terminal window on my Mac. webkit2png runs only on a mac and depends on the fact that WebKit (also Apple) can be manipulated through a bridge to Objective-C (also Apple). Once ffmpeg generates a video, I open it in Apple's great Safari broswer and watch it full-screen. I don't know how to do this as simply with any combination of Linux, Windows, Firefox or Chrome.

I think Apple could decide to make the MPEG encoder and a few other toys available from Safari and then do iMovie as a web app. iMovie would have a point again. It would demonstrate that it is possible to do something with digital video on a consumer machine. The difference between now and iMovie of the twentieth century is that the leading consumer machine is the browser.

In the mean time, several groups are beavering away to bring you video editing in the cloud. I fear these efforts will be linked irretrievably to a 'platform', like YouTube. Apple could remind us that a local machine actually does a fine job. They could add some value along the way. They have the cloud facilities to offer automated closed captioning. They have the clout to offer a portal for licensing music for use in videos. Getting synchronization rights to incidental music in a home video is now more difficult than digital video editing.

One firm trying to sort the soundtrack issue is FriendlyMusic. They offer a catalog of at least tens of thousands of tracks available for your video. They offer 'Mash' licenses -- good for non-downloadable videos hosted only at youtube.com for as little as $.99. A 'Personal' license, $1.99, lets you host your
video on 'any social video website, such as YouTube, Vimeo, Animoto or any other UGC site.' A 'Commercial' license, $25.00, lets you make a video for your small business. They mean small -- fewer than ten employees and less than $1m in annual revenue. I hoped to find 'A Hazy Shade of Winter'. I expected that finding a specific track would be dicey. I was right. I looked around for alternative ideas. I flipped through about a hundred track clips before settling on silence as my alternative soundtrack concept.

Nick Wingfield reported last month that an Apple ][ machine donated by Steve Jobs to SEVA, a non-profit humanitarian organization in Nepal, has returned to his estate after 33 years. One point of that piece is that Steve Jobs was actually a philanthropic creature by some measure -- a response to a criticism often leveled at the man. Let me borrow a Steve Jobs quote from that piece:

“I only know how to do one thing well, I think I can help the world by doing this one thing.”

My Mac does at least four things well. It is beautiful and reliable. It has a good operating system. It includes a good web browser. It may be greedy of me to expect more from it or from Apple. For the moment, I am limited by my vision, not by my tools. I'm exceedingly grateful to Paul Hammond for webkit2png. It's cool. It scratched an itch. It reminded me of my joy using an early NeXT workstation. These reminders do not come often.

surprised

I have a friend who mines Bitcoin. He wondered aloud today if an alpaca might make a good animal for home. Alpaca scarves for all! I was surprised to hear myself say that Bitcoin might be the better investment.

filling

I had it all planned out. I was going to give you a thousand word piece on the history of canned pie filling, from its invention by DuPont during the Great War to the special fillings of peace exchanged this year aboard the International Space Station.

Two problems. The first is that Wikipedia doesn't have an article on canned pie filling for me to crib from. Look for yourself. The closest I got was this. Words fail me.

The second problem is that I had pies of my own to make.

I didn't stand in line to buy the original iPhone. I waited until there was a decent software unlock before I bought one. In the six years since, I think I have used my phone as a timer more frequently than I have used it as a phone. I love it. For all its foibles, Siri just sweetened the deal. The summer of iOS 6 was the summer of my content as Siri timed all my barbequeues. I hoped iOS 7 would erase my top problem with iOS.

I had my iPhone on me when my daughter was born. I pressed a few buttons from the delivery room and I set up a three-way cellular call for the first time in my life. It was easy. Both sets of new grandparents would hear the news at the same time. The marvel of that call, however great, was overshadowed by the joy of parenthood. I haven't set up a three-way call since.

As we fast forward from the original iPhone -- before iOS even had a name -- to the majesty of today's LTE enabled fingerprint reading speech recognizing 64 bit iPhone 5s, one feature key to me got left on pause. the iPhone has one timer.

i'm using a Cook's Illustrated apple pie recipie this year. This one features apples in a pile more prominent than the one in Christopher Kimball's throat. The recipie is great but it features a series of time line gymnatics that only a Time Lord could love. Step four -- fool around with apples then preheat oven to 425. Step five -- spend an hour rolling, chilling, and filling crusts. I don't know how long it takes to preheat an oven with contributions from viewers like you, but my ordinary GE oven gets the job done in a few minutes.

I somehow wound up trying to time three things at once. A chill step on my phone, a second chill step on the timer built into the oven, and a third thing I thought I would do on my phone. "Siri, set another timer for thirty minutes." "your timer is already running. Would you like to change it?" "Siri, do you mean to tell me that you can understand my voice but you can't keep track of two times?" "I'm sorry. I can't answer that."

I understand that free meals at work is the default mode for many folks in the Bay Area. Most of the rest of us use fire in our houses to cook food. More people cook food in a day than use Facebook. I use my phone in the kitchen constantly to check recipie details or to time steps. With Siri, I can do much of it without grabbing my phone and then re-washing my hands. it's awesome.

Apple, could you please do for multiple timers what you did for multi-way calls? Thanks.

Happy Thanksgiving to all.

board

I wrote last month about an Arduino program for emulating a BMW CD changer. That program has been working well for me but the actual Arduino connection has been a mess. I kept a loose Arduino rattling around in my trunk with little jumper wires connecting it to the IBUS and audio connectors in the trunk.

I found Fritzing while searching for a better answer. Fritzing is a combination tool and service. As a software tool, Fritzing is to Eagle what the Arduino IDE is to Emacs. As a service bureau, Fritzing is to PCBexpress what iPhoto is to Kinkos. I mean these as kind comparisons for all involved. I actually like Arduino, Emacs, PCBexpress, iPhoto, and now Fritzing.

Fritzing is a graphical tool for building circuits with a handy button that sends the entire assembly back to Fritzing HQ for manufacture. The key Fritzing hook is that it has three views of the circuit you build. The novel view is a breadboard view. You can wire up a device on a virtual breadboard that corresponds, perhaps, to an actual breadboard sitting in front of you. That view can switch to a traditional schematic view and a PCB layout view. I used it in exactly this way to copy my simple IBUS adapter from breadboard and Arduino into the breadboard view and then into a board designed to be an Arduino shield. The entire exercise took minutes, in part because Fritzing has a reasonable set of default libraries built to suit a modern maker.

I submitted my order on October 31. Fritzing told me the batch would run on November 5 and that the board would ship on November 11. It actually shipped on the 13th and it arrived by post yesterday. The cost for one copy of the board and shipping was 33.10 Euro.

I populated the board this morning and put it back in the car. It works fine. The board is mostly headers and has only two components -- a pull-up resistor and a BSS138 MOSFET. The rest is pins for the Arduino, the car data and audio connectors, stereo jack, and aux power for a bluetooth A2DP dongle.

I scavenged the MOSFET and the resistor from the Sparkfun bi-directional level shifter board I had been using. This is an expensive way to buy transistors, but not much worse than other ways to get them in quantity one.

I'm a happy customer. I think I'll try Fritzing to build a home automation board for my Haiku fan.

gently

I complained too loudly in the last installment about the difficulty of mashing up web audio in static pages. Ian Gilman got me back on track with the simple Rdio player hosted on his site. That page uses the Rdio API without unwelcome branding. It also works in Safari and Mobile Safari without Flash!

Ian has got another project, Fathom, that I haven't really looked at. I did notice that he has a link to still another project, Anthm, on his blog. You'll simply have to forgive these hipsters their vowel blindness.

Anthm has since been renamed Jukio. A fitting vowel penance.

In Douglas Adams' post-Hitchhiker's novel 'Dirk Gently's Holistic Detective Agency', Fathom is the name of Michael Wenton-Weakes' loss-making magazine. Good name for a startup project. Anthem also appears in Dirk as a fabulous new form of spreadsheet software that converts ledgers to music. This modern version of Anthem hopefully does just the opposite. Are Fathom and Anthm secretly related? Stay tuned for next week's installment of 'Least Interesting Internet Conspiracy Theory'.

I tried copying Ian's simple app into my Google Drive storage and using my OAUTH 1.0 developer credential. No dice. The default credentials handed out by Rdio don't allow use of this Flashless API.

I complained that API users would resort to hosting to protect a secret key needed for accessing the API. That's true for Grooveshark, but not for Rdio. Rdio application keys do come with some limits (10 requests per second, 15000 per day) and several web apps leave the necessary client app credential embedded directly in the page they furnish to end users. This is the intended design, but this is not smart. It takes only one mean spirited soul to consume the entire resource grant that you got from Rdio.

I requested access to the beta program for the flashless API and I got a credential, from Ian, less than a day later. Thanks, Rdio! It took me about an hour to port an existing HTML5 audio web app to the Rdio interface. I was able to turn around and have the whole app running out of Google Drive moments later. This porting is unnecessary for my own use, but essential for sharing the app.

I promised to not make any public comments about the beta API and I can comply happily. I like it just fine, but I'm not done complaining about the authentication.

I take no position on the merits of OAUTH, Rdio's choice, as an authentication protocol. If you want to be on the right side of history, you should probably get on board with same sex marriage, the end of capital punishment, the metric system, Major Leauge Soccer and Dippin Dots. You would probably also be on the right side of history if you said that the OAUTH protocol schemes, like most protocols built on Earth, are irretrievably broken. That's not my problem.

My problem with the authentication is that the supporting machinery is far out of scale for a system that protects essentially no secrets or valuable treasures. A Rdio membership that lets you listen to as much as you want on an iPad costs $9.99 per month. If I listen for four hours a day and an average track lasts three minutes, then a track play is worth about four tenths of a cent. I don't know if this is a fair price for music or not. I do think that it's close to that long-ago ideal for nuclear electric power -- too cheap to meter. Why do I need an API key at all?

I don't need access to your Rdio playlists or account information to let you check out a little mashup that plays Flaming Lips' 'Fight Test' and Cat Stevens' 'Father and Son' back to back. I don't need to know who you are. I don't need to know if you're paid up with all the right people. I just need a way to give you an indirect pointer to some tunes that you can decide to pay for or not. I don't need you to get my mashup from my site. I would be happy for you to get my wares as Free Software capable of working out of the box with nothing but your existing streaming account.

Some writers favor 'one' over 'you'. Here's the rule at reograph: if a piece of prescriptive guidance is intended for a reasonable person, then we use 'you'. You should eat leafy green vegetables, drink lots of water, and read reograph. If guidance is for an unreasonable person, then we use 'one'. If one must set off in one's hovercraft, then one simply must! The guidance for 'you' at reograph is often actually meant for me. If you are looking for a shareable audio service, try to find one that will let you use the service without requiring a separate, discretionary API credential grant.

I haven't found this perfect service yet. I'm picking on Rdio an awful lot but they are as close to right as I can find. They seem to have the first system worth programming at all. If you unspooled an entire Maxell XLII-S CrO2 cassette tape, it wouldn't be long enough to reach from Rdio back to their next most programmable competitor.

Much of what Rdio lacks is beyond their API to provide. Their terms of service specifically forbid you, as a developer, from building a web page that lets a user arrange a slide show with music. Connecting the 'The Wizard of Oz' with 'The Dark Side of the Moon' is right out. That would be tricky anyway. Netflix dropped Wizard and seem to have discontinued their API for all but those able to fill shipping containers with cheap set top boxes and related Christmas cheer. I bet the guys at Rdio HQ find the terms imposed on them by Big Media as silly as I find the 'no slideshow' rule.

Before I get a lot of helpful comments highlighting my total ignorance of the fine points of copyright mining -- derivitave works, mechanical rights, and so on -- I thought I'd bring up the case of CleanFlicks. CleanFlicks bought commercial DVDs and produced edited copies that carefully trimmed sex and foul language away from violent movies. That's copyright no-no.

Rival firm ClearPlay runs a similar racket but they keep their play in-bounds. ClearPlay doesn't distribute movies. They distribute patch files for movies that consenting adults can apply the privacy of their own homes. ClearPlay's edit list appears comprehensive for this summer's 'Man of Steel'. It mutes all fifteen profanities while leaving the rest of the violent masterpiece almost untouched. ClearPlay's 'Lawrence of Arabia' Lawrence is merely flamboyant. I looked for ClearPlay versions of 'Brokeback Mountain'. I got no results except a quote at the bottom 'I find your lack of faith disturbing -- Darth Vader'. Brokeback won the Academy Award for best director. I searched for 'Baraka' and I got the quote 'You must unlearn what you have learned -- Yoda'. I believe that enough searches for troublesome films on their site could reveal the entire hidden George Lucas plan to draw you back to Christ. ClearPlay's site preserves the Vader quote above but their edit list for Star Wars elides the accompanying throttling. I have no idea if Han shoots first in their version.

If ClearPlay can do this, then is a web page that mashes up a song and a picture really such a threat to Western civilization? Is it about 'irreparable injury to the creative artistic expression' -- the argument made against CleanFlicks -- or is it about money?

I also complained recently about the Blogsy blogger app for iOS. It spammed an earlier post of mine with a useless 'Posted with Blogsy' footer. Blogsy can be brought to heel and the footer removed. Irritating but reversible. I think I understand the confusion. Apple has inserted a footer in iOS email for six years. The difference is that the Apple footer is offered to recipients as a kind of apology -- meaning 'the above message is short, composed while driving, and full of hilarious auto-correct substitutions'. I recall that BlackBerries offer a similar apology by default. Blogsy doesn't really have that much to apologize for and so the footer is unnecessary.

audio

In our last installment, I wondered why software developers collectively allow iPad web applications to stink. I think the reasons are mostly non-technical.

Last time, I tried and failed to use Google Drive to host some static content. Unsurprisingly, the culprit was a web page that worked poorly on the iPad. I eventually got Drive hosting static content by finding the 'Desktop' view. Even then, I had to click through a "The browser you're using may not support all the features of the desktop version of Google Drive" to get there. The Google Drive hosting hack is one step more complicated than sharing a folder. You also have to open your HTML page in Google Docs and press 'Preview' to get an URL. That step does not work on the iPad no matter the browser mode.

I hauled out a laptop and repeated the process. I got the URL. I opened it in the iPad. Success.

The app that I'd like to share with you is the HTML5 audio player I built this summer for a memorial service. The player is a straight client-side web app. It runs fine out of Google Drive. Here's the lin....

Oh. Never mind. I'll go to jail if I share the link with you. You're not allowed to have my music. I can't afford to license a hundred tracks of commercial music for a free web app. I can't replace ten playlists with a random collection of Creative Commons tracks and have a memorial that is representative of my friend's actual tastes and habits.

No problem. Ads for 'All Access' audio from Google Play, a streaming subscription service, are in heavy rotation on the blog now. They say it works on every device. You and I can both subscribe and I'll fish out the URLs for these playlists and put them into the web pag....

Oh. Google Play may work on a lot of devices and in the browser, but not in the browser on all those devices. I tried to open play.google.com on my iPad and I got nothing but an empty page and the message 'database error: Error: SecurityError: DOM Exception 18'. Too bad. It worked in Safari in 2011 when Sharon Vaknin wrote about it for CNET. It wouldn't have helped me then. Google didn't offer an all-you-can-eat service that would allow me to build a player for the music pooled in a subscription we share.

No problem. Google's just the latest entrant in the subscription music biz. One of the others will have done this properly. I'll try iTunes Rad... No I won't. That would never work. Who am I fooling? I'll try Spotify. Hmm. Spotify seems to use flash on my laptop. On the iPad browser, spotify.com offers only account maintenance functions. I'll try Rdio. Rdio redirects to the App Store in the iPad browser. No, thanks. If Google can't play me some subscriptions tunes with HTML5, then they can at least let me search for an HTML5 audio subscription app.

Hmm. forte.fm. That plays audio in the browser on the iPad. forte.fm is actually an HTML5 Rdio client built for the app-poor BlackBerry BB10 environment. It works on the iPad. It looks good! It almost works! It seems to play only track previews on iPad. I haven't had time to diagnose this strange behavior.

So Rdio works in iPad's Safari except when we get it from Rdio's official web site. I can deal with that. I'll just do the same trick in my web pag... Oh. forte.fm violates the Rdio API terms of service, which require that 'Your application will at all times display and promote the ability to subscribe to the Rdio Service, including, without limitation, making available and displaying promotions of Rdio’s subscription tiers, and without limiting the generality of the foregoing, will at all times make available ecommerce opportunities (including Rdio subscription tier offers and Rdio a-la-carte download offers) for free trial users and registered users listening to 30 second clips of music recordings.'

I don't want to clutter a web page with a bunch of Rdio branding. I'd be grateful to them for serving the streaming tunes but my premise is that this would work only because the end user of the web page was already paying Rdio for access to those tunes.

The branding issue is actually the smallest problem with using Rdio this way. The bigger problem is that their API requires a key. If I get an API key, I'd have to keep it secret from you. That's right. If I want to deliver a web page that presents you a selection of the music you already pay for, then I need to keep a secret from you to do it. I can't give you a client-only app and keep a secret from you. Rdio didn't invent this ridiculous model. They just didn't think hard enough before adopting it.

On to Grooveshark. Their HTML5 player works on the iPad. I'll just check their API developer term...
Oh. Same problems as Rdio. Never mind.

Most developers resort to some form of web hosting to square this secret circle. They spin up a lot of very complicated machinery to bring up a web server that runs PHP for no better purpose than to hide this API key from you. This is crazy and wasteful. Google actually show us the way here. AdSense works. AdSense uses an opaque identifier just like all these API keys. I get to share it with you.

I didn't really believe in the browser until I saw Google Maps. It wasn't just the best web page I had ever seen -- it was one of the best programs I had ever used. It delivered a smoother interface to the actual world than most games provide for their imaginary worlds. It didn't just embarrass many other mapping solutions, it embarrassed data visualization tools across domains. The easy, and easily available, API is a cherry on top. The simplest example from the developer site is really simple. You can try it yourself without credentials.

I keep believing in the browser. Surprisingly, Google Maps still embarrasses other data tools -- including much newer music offerings from Google themselves and from others.

Now we have two non-technical reasons that web apps lag: hosting and copyrighted assets. We'll visit more in the next installment.

entitlement

I complain about blogger a lot for a guy who pays nothing for the service. I know that. The main thing about it that gets at me isn't really Blogger's fault. It's that the web page works poorly on the iPad. George W. Bush was fond of the phrase 'soft bigotry of low expectations'. Blogger didn't set out to make a web page that worked poorly. I guess they just lost sight of the fact that the web can be really good and let their preconceptions be their default.


John Gruber is one of many luminaries who enable this bigotry. I have blogged before about this post of his. I think my real objection is to his claim "Today, in 2013, even the best-crafted mobile web apps come nowhere near the quality of experience of the best native apps". The claim bothers me but I can't really disagree. I know the many technical limits of 2013-era web apps. My problem with Gruber's line is the leap many make by asserting that the technical limits of the browser are the same limits that separate the best web apps from the best native apps. This is not the case.

One non-technical problem with web apps is that it's difficult to charge money for the app. That's not the biggest problem. The biggest problem is that web apps have to come from somewhere.

I know many folks who have built a forge in their backyard, or at least dream of it. I know nobody who wants to do their own colonoscopy. The intrinsic joys of running an SMTP server seem closer to the colonoscopy and the joy of running a public facing web server is headed in the same direction.

I don't really want to run a web server. I don't want to maintain an SQL database or apply software updates or even deal with the e-commerce site of a web hosting provider. I don't even really want to hassle with the domain name system. If I just give Apple their $99 and send my apps their way, then I don't have to do any of that.

What I do want to do is write Javascript. I love it. I love the browser. The combination feels to me like the ultimate victory of the LISP machine. Apple, Google, Mozilla, Opera, Microsoft, and others have all actually done a lot for the world by rowing in more or less the same direction with this technology. As large as their differences have seemed, I think they are all more interoperable than were the LISP or UNIX machines and dialects of the '80s.

I have written apps with Cordova. I admire that project but I don't think of it as a cross-platform development tool. I think of it as a tenacious effort to keep the Javascript/DOM platform relevant. I admired Palm's WebOS more. I already feel sad about the pending failure of FirefoxOS. I like the web, I think it's important, but I love a good browser.

I wrote previously about developing and deploying an HTML5 web audio app using Kiosk Pro on iOS.

I would like to share that serverless app with you but the the logistics are frustrating. Blogger won't host the files. Dropbox won't serve up a web app. I found a LifeHacker post from last year about serving web apps out of Google Drive. I uploaded a simple web app I built for my kids to my Google Drive account. The Google Drive iOS app doesn't seem to let me make a folder public. Google themselves provide some notes on this topic, though their notes do not work on iOS. They work a little better whenever you can find a link that lets you opt-out of 'mobile view'.

I'll keep trying. If I can figure out a way to anonymously serve a couple of files for less than the cost of my lifetime AdSense earnings to date (about seven dollars) then I'll share some web apps.

I wrote this post in 'blogsy' for iOS on my iPad. Five bucks. It's better than the free Blogger app. It supports hyperlinks -- a critical feature that somehow didn't fit the Blogger app view of the world. I think it's better also than the Blogger web interface. I think the blogsy people just cared more. I'm about to publish but I have some trepidation. Blogsy looks like it may attach 'Posted with Blogsy' to the bottom of the post. It's a waste of five dollars if that is the case.

Posted with Blogsy

haiku part II

(This is part two of a three part review. Blogger has reorderd them. They now appear to run two, three, one)

The fan is dead! Long live the fan!

Last week saw the execution of my old Honeywell ceiling fan. The crime? Conspiring with a known bad in-wall control unit. Sending secret radio messages. Total dereliction of duty.

I chortled in my joy as I surfed, now in the dark, for a replacement fan. I scanned the entire collection at Vintage Fans. I ran through the entire online collection of Hunter fans. That site actually generates new fan combinations randomly as you ask for each page. I found sizeable collections of fan porn in the pages of Pinterest and Houzz. In all, I put together a list of about 25 fans and passed it on to my wife.

I expected her to quickly ratify my top choice -- the Hunter Hotel Original with Adaptair. I thought I would pair it with a set of custom fan blades in maple from C&R Woodcrafters. It was going to be great. I'd be able to believe I was cool in summer. The fan would work well and look good. No stinking digital controls.

My wife got back to me in a flash. She said "I was imagining something more awesome." That knocked me out of balance, like a fan that has thrown a blade. I had no backup plan so I googled "awesome ceiling fan" and used image search. I discounted novelty fans and props left over from Terry Gilliam movies. I found the answer on the first page. The 'Haiku' by Big Ass Fans.

I also found Virginia H. S********, Air Force Civilian. She has no part in this story except that the Google image search results for fans turned up a cute snap of her cat, Tabbie, staring at the ceiling fan while tugging on her badge for work. Her badge is readable in the photo. Tabbie looks like a cat caught in the act. I wonder who he really works for.

Back to fans. I hated the old fan from the first day I bought the house. I was having a fight with it only minutes after closing when I was interrupted by a knock. The knock was from my new tenant. He had just returned home from a backpacking trip to Paraguay. I had never met the man. This stranger announced that he had lost his keys in Paraguay and asked me for mine. I didn't know if his story was authentic but I was sure that his stink was. I gave him my key to the basement apartment.

He returned my key in the little paper bag from the hardware store that had held the copies he had made. It said 'Qty 3'. He came up about an hour later to tell me that his Ukranian girlfreind would be arriving imminently and moving in. I said I already knew. When he asked how, I told him that I knew he had made three copies of the key. He said "Huh. Have to practice better information management in this town." Virginia should take this advice to heart.

Really back to fans this time. Haiku by Big Ass Fans. I remember a years-ago BAF ad. Got a Big Ass Room? Get a Big Ass Fan. The have brought the line down to medium ass rooms by licensing a novel, modern fan design from a Kiwi and marketing it under their brand.

The Haiku fan is the more awsome that my wife was looking for.

The old Honeywell unit was a five bladed fan that spanned about 54 inches. The Haiku spans 60 with three blades. The blades look purposefully aerodynamic. Mine are molded bamboo. I wondered immediately why I couldn't think of an Eames piece in bamboo. Maybe Nixon visited China too late for them. The humble downrod is clad in sleek fairings. The mount was utter simplicity. Everything about the fan is beautiful.

Blogger's iPad app still doesn't allow me to insert hyperlinks in posts. It turns out that hyperlinks, not W3C browser-based DRM protected video, are the defining feature of the web. If you revived Vannevar Bush to show him the Blogger app, he would be completely blown away... by the lack of hypertext. I have to circle back to the web interface after writing these posts to touch them up with actual hyperlinks. I'll try preparing the next installment in a different environment. Maybe wordpress. Maybe a typewriter. Maybe a typewriter emulator app for Chrome running on a Google Pixel. Stay tuned.

haiku part III

A Haiku fan now reigns over my living room where a Honeywell fan once spun. I like the fan.

There are some brighter spots and darker spots in the experience. One dark spot is the lack of a built-in lamp. Big Ass Fans offer a light kit as a partial remedy. The kit is $95. That's cheap only compared to the $825 base price for the Haiku.

Darker a spot than the lack of light is the light itself. The fixture installs pretty easily over the hub of the fan. It connects to the main fan circuit board with a short cable. The lit portion is about six inches across and studded with a ring of about twenty LEDs surface mounted on a printed circuit board. The fixture is surrounded by an attractive metal heatsink casting which adds several extra inches to the overall diameter of the fixture.

The ring of LEDs is covered with a choice of either a frosted white lens or a dark smoke lens. The white lens filters little enough light that it is still easy to get an unpleasant eyeful of LED. The lens does take what would be twenty sharp spot beams and blends them into a uniformly dim and harsh light. It would take a naked forty watt bulb hanging from the ceiling to achieve the same effect. Kudos to Big Ass Fans for managing that with such efficiency.

The remote is another sore point. Credit card sized remotes were pretty cool in 1993 when the Macintosh TV came out. They were still a bit cool in the late nineties when Bose bundled them with Wave Radios. In 2013 they are just cheap and nasty. You can buy essentially the same remote from dozens of alibaba vendors for a couple of dollars. The remote battery tray interchanges with the cheap remote included with my kids' color-change novelty lightbulb ($5.97).

The fan side of the remote is not so bad. Blue LEDs illuminate for a short time to indicate what fan speed is now active. this is especially helpful when you want to be sure the unit is off, not just very very slow. It also beats pull chain systems that cycle back from high to off. That would be a real pain with the Haiku's seven speeds.

Worse than the cheap remote is the cheaper wall bracket for the remote. The bracket looks like some type of one time use medical thing. Maybe it started life as a complimentary floss cutter to be given out twice yearly by dentists. The sharp edges on the inexpensive part could manage that well.

Hunter remotes frequently hang on a hidden bracket that allows the remote to be used as a wall control when docked. The Haiku fan bracket covers at least five of the ten remote buttons. The light controls are completely obscured.

Big Ass Fan's answer to this criticism might be to point to the available wall control unit. That unit adds an additional $175 to the fan price. Worse, it dumps me back where I started with Honeywell -- a hard-wired unit that collaborates secretly with a fan over an RF link. No thank you.

Neither of these stories provides any good options for integration into a home automation system, unless the RF module supports an open standard and bi-directional communication.

I watched the online installation video for the RF module. The fan does not ship with the RF receiver. The small receiver board ships together with the wall unit. I imagine that this is for regulatory reasons  as much as cost.  It is a tiny board that plugs into the main fan board with a single row pin header with few pins. Maybe another module could install there. Maybe a wifi module. Maybe an Arduino. If Nest can solve the user interface challenge of configuring a wifi smoke detector on your ceiling, then it must be possible for a ceiling fan.  

haiku

seasons turn slowly /

honeywell fan slower still /

leaves and fan come down

I live in an old house without central air conditioning. Just before I bought it, the house was subject to a thoughtful remodeling undone only by poor judgement and shoddy workmanship. The house gained all of the bulk and ugliness of central air conditioning with almost none of the benefit. The previous owners installed a useless central fan with ducted registers throughout the house. I suspect that it would all have to go in order to properly install a central air system.

I prefer to pretend that it is not hot. In winter, we heat with cast iron radiators and a hot water boiler. We love them. I support my summer comfort fantasy with a variety of window and portable air conditioners and ceiling fans.

The previous owners took the no-AC dividend -- probably ten thousand dollars -- and plowed a hundred dollars of it directly into one of the worst ceiling fans that they could buy. That fan hung in my living room until last week. I had hoped it would be difficult to buy a fan that bad by accident but these appear to be the new default.

The fan was tied to an Honeywell branded in-wall combination light and thermostatic fan control. It had five buttons for fan control, a thermostat slider for automatic operation, and a single button to control the fan light. The thermostat never did anything but turn the fan on at unwelcome moments. The light switch was the real problem. It was never easy to operate. Near the end of its life, the rubbery button required more than 50 pounds of force for the unit to register a press. That's 1% of the thrust produced by the Garrett (now Honeywell) ATF3 turbofan.  The wall switch had none of the familiar roundness of Honeywell's most beloved products.

Honeywell products (above: HFT7000) should be round
Photo courtesy Honeywell

50 pounds of force seems like a lot for a computer scientist to muster but this wasn't even the worst problem. The switch included a dimmer function. Once you jammed a stick into the button and pressed hard enough to engage the switch, you had about two microseconds to let go before the built-in dimmer started dimming the fixture. Once dimming started, you have to press and hold until the dimmer reaches bottom and then starts to rise. You have to let go just when it reaches its apex.

I finally ripped this control out of the wall and I expected to install a SmartHome FanLinc Insteon controller in the fan canopy. When I got the control out of the wall, I saw many fewer wires than I expected. I took the fan apart and found out why. The in-wall control is really an RF control that matches a large honeywell fan/light control mounted in the motor housing of the fan. The fan does not want to be controlled by anything but its module. I didn't want to map out the tangle of wires to adapt another control to this motor.

All gone. Fan, module, control, everything. Gone.

This scheme of hard-wired controller and proprietary RF protocol is depressingly common. My module is labelled Honeywell, but similar units are labelled Hunter, Westinghouse, Hampton Bay, Litex, or Craftmade. I wouldn't buy any of them. I have other variations on this theme throughout the house.

Wireless fan control by Hunter
Photo courtesy Hunter

I give the nod to Hunter for the ease with which neighbors can turn on your fan. Ever left for vacation and wondered if you remembered to shut the fan off? No problem with Hunter. Your neighbors need try only sixteen DIP switch combinations before they shut the fan for you.

I've put up with flakey home automation devices for many, many years. Even the worst of the bad X10 devices was more reliable than these fan units.

I would like my excellent Nest thermostat to control my fans. Nest has expanded their lineup recently with the Nest Protect smoke and carbon monoxide detector. Maybe Nest can expand their ceiling-based lineup with a few spinning blades and make a great fan. I think there is room in the market for it. There is certainly room in my house for it.

plan

It was chilly today. I threw on a fleece vest that I hadn't worn in a while. Huh. What's that bulge in the pocket? Oh. A roll of duct tape. I had to go through a Secret-Service-type checkpoint the last time I wore the vest. Same bulge.

It had been at a children's Halloween party downtown. The burly dude at the magnetometer said "Sir, what is your plan for this duct tape?" This was the best question anyone has asked me since. My plan was to use it to patch my daughter's home made foam rubber pumpkin costume. They didn't completely like that answer. I said "I'm a man. I fix things with duct tape."

With that restatement of the obvious, all was fine.

All security questions should be asked this way -- not "What is this?", not "What is this for?". I'm sure this prompt is rooted in some delicate and beautiful point of criminal psychology that I don't understand.

I think this question should be deployed in realms beyond security. Imagine what life could be like if the Radio Shack clerk was required to ask you this. I would have a much less serious ewaste problem if I had to articulate, aloud, a reasonable plan for a gadget.

Him: Sir, what is your plan for this $35 power supply?

Me: I will use it as a replacement for a lost power supply for a camera worth $15.

Him: Sir, step away from the counter.

That dialogue would have saved me $35 but it's probably too intrusive for the American people. I'm sure the $35 adapter would be closer to $100 if we had to send all the clerks to elite training schools.

I think we could get most of the benefit from this just by getting people to answer the prompt without a burly armed dude and consequences that would go down in our permanent record. Brian Wansink banged out a pretty great book "Mindless Eating: Why We Eat More Than We Think". It's the kind of book that you'll later recall was by Malcom Gladwell.

Wansink writes:

... Over coffee, a new friend commented that he'd lost 30 pounds within the past year. When I asked him how, he explained he didn't stop eating potato chips, pizza, or ice cream. He ate anything he wanted, but if he had a craving when he wasn't hungry he'd say -- out loud -- "I'm not hungry but I'm going to eat this anyway."

  Having to make that declaration -- out loud -- would often be enough to prevent him from mindlessly indulging ...

I could lose thirty pounds of gadgets in a year if I used the same trick at the point of purchase. I think I'll try. Worry not, dear readers. That still leaves about a hundred pounds a year for me to write about.

another bad habit

I have terrible discipline. I use this blog partly to conquer my fears of writing and finishing things. I think my fear of finishing things is the greater one.

Many posts here sit half-written as drafts until I have something else I want to say. Only then do I slap an ending on the previous thought and shove it out the door. Today is one of those days.

'tunes' was hustled onto the site because I had a flat tire this morning. I used my Ryobi cordless inflator for the first time and I wanted to share my thoughts about it.

I was already late getting the kids to school this morning when I spotted the flat. I grabbed the inflator from the spare tire well, slapped a battery into it, and set it up. Where did the battery come from? From a cordless impact driver rattling around the trunk, of course.

This device is not by itself a rescue inflator. It doesn't have a reflector or flashlight. It does not have a battery charger. It does not have a 12V cable. You turn up with a charged Ryobi battery, keep a charged battery installed, or keep a 12V Ryobi battery charger around. I had the inflator in my trunk only because it had been there since I bought it.

With that caveat aside, I was rescued. The charger seemed quieter and more powerful than the 12V cigarette inflators I've used before. The charger took my 205/55R16 Dunlop from 12.5 psi to 32 psi in  what seemed like a couple of minutes. My guess is that 12V compressors are probably limited to about 5 amps (for 60W total) from the cigarette lighter socket. I used the Ryobi with a 1.5Ah lithium battery that could probably supply 250W. I have no idea what the compressor actually draws.

The built-in digital pressure gauge was backlit and easy to read. The air hose was a bit short. You could comfortably inflate the 22 inch rubber on your dub ride only with the valve stem near the ground. The chuck seemed a bit cheap.

The inflator, with lithium battery, weighed less than some corded inflators I have owned. The assembly weighs far less than many junky cordless inflators built around a heavy lead acid battery.

I have no dissatisfaction with this unit but I wish Ryobi would build a box that combines the inflator with a 12V charger and a 12V jumpstarter. I think my ideal device would probably charge and hold two Ryobi One+ batteries.

I'm publishing this post the same day it was written. I wish it was because I sat down, wrote it, and published it in a fluid motion. It's not. I have to tell you about a time lapse shutter gadget I'm building for my daughter. I can't start writing that until this goes out the door.

tunes

I told you last episode about buying a used car. I got the car I wanted. Getting it was half the effort. Getting it home was the other half.

I got several estimate from car haulers who asked between one and two dollars a mile to collect a car and bring it to your door. I thought those offers were fair, but they meant completing the transaction on the car sight unseen. If Amazon offered free Prime shipping, I might have gone for it. Instead, I found a flight for just over a hundred bucks. The seller picked me up at the airport in the car. Very smooth.

When the deed was done, I set off for home. A half an hour into a long drive, the guy called and wanted to know if he had left his magnetic dealer tag on the back. A half an hour after that, I set out again.

The drive was pleasant and the car seemed almost factory fresh. I was transported back to 2001. In 2001, people still apparently listened to music on round shiny things called CDs. The factory put a hole in the dashboard just for these things. My digital tunes don't fit in the hole. My long drive was going to be quieter than I expected.

The hole in the dash is actually part of what we used to call a radio. Kids these days call that a 'head unit'. The head unit does usually contain a radio. Mine contains the CD player as well, and the interface electronics needed to speak to a remote CD changer.

I guess that these interfaces were common in factory radios from about 1995 to 2005. Hundreds of hobbyists have leapt to the same conclusion over that period -- pretend to be a cd changer and send digital tunes in that way.

Some hobbyists have even turned this little trick into a business. I remember that one of the first products to pull this emulation trick was the PhatBox. ZD ran a review of that device in 2000, not long after its introduction. The product was discontinued by 2005. The review was amazingly detailed. It said the box ran Linux on a Cirrus EP7212 SoC and managed the CD changer interface with a dedicated 8051 microcontroller.

The PhatBox product tried to solve two problems. It did a great job delivering audio to the dashboard. I think it stumbled by trying to solve the storage problem. The Phat solution was laptop hard disk drives wrapped in a proprietary cartridge. Phat didn't know about the coming iPod. They didn't know that only Apple gets to mark up commodity storage and live to tell about it.

Several firms took up the CD emulation challenge post-iPod. Many automakers got in on the act themselves. DICE electronics (now Audiovox) still sells an aftermarket unit.

Even that business is now in decline. Finally. I can leap in with both feet now that this
technology has hit bottom. I decided to build a CD changer emulator for my car.

This path is a well travelled for BMW cars of the era. These cars hide two connectors for a CD changer in the trunk. One is a three pin connector for power and data, the other is a six pin connector for analog audio. I hear that some fancy cars have only digital audio. Mine isn't one.

The three pin power/data connector provides constant +12V, ground, and a serial data line. This scheme is called 'ibus' in BMW circles. The same thing is called 'kbus' among MINI cognoscenti. The technology shows up in some Rolls Royce cars from the same era. I'm sure it has no name there. Gentlemen don't talk about data busses. Whatever the name, the bus runs at 9600 baud with 1 start bit, eight data bits, an even parity bit, and a stop bit. The bus is pulled up externally to 12V.

Most folks building amateur CD changers for these cars are using an interface built by Rolf Resler. You can get one here. I didn't. The interface, plus shipping from Germany, cost more than the Radio Shack retail price for an Italian Arduino.

Resler's interface is probably wonderful, but it is just an IBUS to RS232 (or serial over USB) adapter. There is no logic to spare in that interface for the CD changer emulator. By contrast, an Arduino has enough logic for the job and enough spare capacity to run the ibus interface as well.

You could probably connect the ibus directly to an Arduino I/O pin for a while without smoking the Arduino. You can run an Arduino directly from the 12V line though 12V is at the upper end of the range for the Arduino's linear supply. I used one of the 'TX' halves of a Sparkfun bi-directional level converter breakout board for my bus interface. Sparkfun has revised these boards recently to eliminate the distinction between 'RX' and 'TX' lanes.

These level converters are used mostly for 5V <-> 3.3V level shifting but the BSS138 MOSFETs around which they are built are rated for 50V.

My Arduino code is available here. I have used it on a Duemilanove and an Uno R3.

This sketch doesn't actually jam any audio into the car. It just pretends to be an attached CD changer. If the BMW head unit sees an attached cd changer, it will let you jam your own audio into the audio pins in the trunk. I leave that as an exercise to the reader. I used the same Tunelink reviewed here last year.

cleveland

My interest in Cleveland motoring last month was not entirely idle.

I flew to Cleveland last month to buy a car from a small pan-German garage that deals a few cars on the side.

I bought a 2001 BMW 323iT station wagon with a five speed. This is a rare car in the US. I got a sense of how rare with a persistent ebay query. Ebay sends me a note every morning with a list of new listings for station wagons with manual transmissions within a few hundred miles of home. The results are surprising.

Here's a two month tally by brand for the ten most represented brands together with the overall 2012 market share for each firm or parent firm:

           ebay    overall
brand      count   market share
_______________________________
Subaru.......153.......... 2.2%
Volkswagen....36.......... 2.4%
BMW...........17.......... 2.3%
Chevrolet(GM).15......... 18.2%
Volvo.........14............ 1%
Scion.........11.......... 2.9%
Audi..........10.......... 1.2%
Saab...........8............ 0%
Land Rover.....8........... .2%
Chrysler.......8......... 11.6%

On a recent day, there were about 36 thousand cars available on ebay in the same radius. About one thousand are wagons. About two thousand have manual transmissions. Eighty one were wagons with manual transmissions. Diesel convertibles are less common, as are manual SUVs, but that's about it.

On the same day, there were about 15 thousand sedans available in the same radius. That's almost half of cars. Six hundred of those have manual transmissions. I was surprised to find that manuals were more prevalent  in wagons (8%) than in sedans (4%). If you're buying a statistical car at a statistical future time, then this works to your advantage. If you are stuck buying actual cars, then only the actual size of the market matters.

If you want a used manual wagon today, you're getting a Subaru. More than half the Saabs in the list are re-badged Subarus. If you want a particular manual BMW wagon in a particular color with particular options, be prepared to wait a while.

I found a car in a color I liked with the close to the options I wanted -- which was none. I bought it.

If I had thought harder about it, I might have asked for some better pictures first. They would have highlighted some of rust on the car. Rust appears endemic to the area. I would probably have passed on the car if I had seen it.

I'm glad I didn't see it. The car is otherwise great. I'm glad I have it. I'd still be looking for another one if I had passed on it.

The kids love it. The Miata is for sale. The kids are sad about that. The memories they already have will  probably make them happier than would retaining this actual specimen.

peter egan

Peter Egan has retired as a monthly columnist from Road & Track magazine. His last 'Side Glances' is available from the R&T site. I kept my subscription to that magazine for an additional decade just for that column.

Peter is the inspiration for many of my own automotive dreams. He's part of the reason I bought a BRG Miata as a winter driver. His philosophies are also part of the reason I will move on from the same reliable, trouble-free Miata this fall. Life is short. The Miata is at least the second best car I have ever lived with. I need that space in my driveway for a disastrous adventure with a Land Rover, a turbocharged Swedish wagon, a Renault Fuego, or some other inappropriate vehicle.

My choices will be tempered by desire to not orphan my children, also my desire to to give them a whiff of excitement and volatile hydrocarbons. I think most choices now will have a seat for both kids. Perhaps a Matra Murena?

I used to read Jalopnik regularly when Murilee Martin blogged in residence. As a lark, Jalopnik maintained a reader-moderated 'fantasy garage' with fifty spots. I think my fantasy garage looks a lot more like Egan's actual garage -- a place where rafterage for disassembled cars must be as important a commodity as floor space. I saw tents for sale in REI this summer with footprints as large as my fantasy garage.

I live in a place where emissions inspections have taken half the fun away from 1974+ cars and where urban congestion has removed fun from cars of all ages but old cars especially. I know that all it takes is one breakdown on a shoulderless walled highway to be a guy responsible for a mile long backup.

I lived near Baltimore for a time in the 1990's. Southwest Airlines then offered a promotional fare of $19 to Cleveland. I wondered what it would be like to give up on East Coast motoring all together and rent a garage near the airport in Cleveland and visit every weekend.

Side Glances is available in anthology.

big time

I hate to brag, but I've finally cracked six figures from monetizing this blog!

It might be fairer to say that I've cracked the '6' figure. I've now earned $6.01 in sweet, though unpaid, AdSense bucks. That future payday is all you.

With this milestone, we have finally cracked ten cents a post!

Schoolchildren learn that Charles Dickens was paid a penny a word. That may not be exactly so according to the folks at Fine Books magazine. They reckon the true number is about 1 farthing, or .25 pennies, per word. If we keep riding high on the revenue curve here at reograph then I'll continue to pocket .001 cents per word. I'm pocketing 4% of Charles Dickens' take and I'm doing it on my couch. Not bad.

If we indugle some extremely sketchy bistromath, we can work out how far that farthing would have stretched in present dollars. A farthing was a quarter of an English penny. There were twelve pennies to the shilling, twenty shillings to the pound. That farthing was about a thousandth of a pound.

Dickens made .001 pounds per word and I make .001 dollars. Today's exchange rate pegs the dollar at about .6 pounds. I'm just a bit of click fraud away from trumping the all time star of serialization. We should adjust for inflation before I get too carried away. The UK National Archives site will compare the buying power of old pounds with new. I looked at currency converters until I found one that told me that an 1850 pound was worth about 100 2013 pounds. Thank heavens for round numbers.

The conversion leaves me with a bit over a half a percent of Dickens' income per word. Still not bad for the couch. Of course, Dickens cranked out my entire annual output in mere hours.

Thanks,
  Your Correspondent

side b

Beep. Welcome to side B of the blog. We'll pick up here with the second half of kiosk. This isn't just the continuation of that story. It is also side B of the whole blog. I started this blog while a close friend was hospitalized as a way to write down a fraction of the crazy things I would otherwise waste his time with in person. He started the ball rolling with his own blog. He picked the blogger service. He figured out that blogger wouldn't generate an RSS feed for a private blog. We both wound up with public blogs just to indulge the Google Reader habits of our friends and ourselves.

About a month before he died, I asked about his post-Reader plan. His response?

sorry, my plan is to no longer need such things.

Fat lot of good that does me. Bereft and without a good RSS reader.

My friend was my audience. Now you are. I may keep at this or not. It will be very different for me in any case. Back to the listening stations...

The hardware execution left a motley collection of iOS and Android tablets -- borrowed, bought, and donated -- arrayed on my kitchen table seeking only a uniform interface that could capture so many ears and eyeballs that were unknown to me. I had a terrific asset beyond the tablets. My friend's wife teased ten great playlists from their collection and her sense of his taste.

Thomas Asbridge wrote that an 11th century visitor to Constantinople might have seen at least two heads of John the Baptist. As a child, I heard a joke about a monastery that held the heads of John as a child, as a teen, and as an adult. This project aimed for a much more minor miracle -- the ten headphones chronicling the stages of a careful listener's evolution.

I rejected both the native iOS and Android music players out of hand. I was impressed when Steve Jobs offered me a thousand songs in my pocket with the original iPod. I wanted ten new songs in your head. It's a different interface problem.

There was no way that I was going to fire up Eclipse and Xcode and build two native apps from scratch. I have some limited experience with PhoneGap. That could work. It would only have worked for me if the audio handling in each was robust. I figured that PhoneGap could work if the native browsers were up to the task themselves. If they were, why not just use them directly?

I first heard audio in a web browser in about 1995. It was a terrible MIDI file that began playing in the background of a cheesy web page for a computer parts vendor in Florida. I recall that site also had an animated GIF of a swaying palm. Both were irritating. Background MIDI files and animated GIFs only lasted a few years in the mainstream of the early web. Little animated 'under constuction' signs lasted longer. These had a special, almost sacramental, role in the web as digital headstones for stillborn web sites.

Future generations will interpret this as a sign of quarantine.
What lies beneath?
Perhaps the digital plague that killed the fabled GeoCities.
image courtesy mikesfreegifs.com

It's 2013 now. Animated GIFs are back and so is audio in the browser.

I think I understand how and why they came back. I think the iPhone is at the root of both.

Apple famously ditched Flash when the iPhone debuted. This was a move that now seems obvious. It was controversial at the time. Recall that Flash was unavailable even at a time when there were no native apps and the in-frame audio and video handling in Mobile Safari was nonexistent. Apple sold millions of iPhones before the first public working draft of HTML5 turned up.

HTML5 is the next generation of HTML. It includes direct support for audio and video in the browser. The working group behind the spec left almost no detail unaddressed -- except for the what video and audio formats would actually be supported. As a result, essentially no video or compressed audio file format was supported by all browsers. Lots of ink was spilled in the wake of this apparent disaster. I recall that patents were the villain.

Nearly everyone forgot that there was a 'video' format supported in all major browsers -- the animated GIF. They crawled back to the web while we were distracted by the battle over real video.

I bet that Mobile Safari included support for animated GIFs only by accident. If they had let Flash in or left GIF out, I think there would have been no niche for these files.

Perhaps animated GIF was an accidental video format. There never was an accidental audio format. There was no 'beep' tag in HTML that could be bit-banged into bad audio. The format situation remains technically unresolved after more than four years of half-hearted trying. In practice, there is no problem. The browsers on the mobile devices all play the most common formats. Flash still exists on the desktop for browsers that don't.

I remember spending some large portion of my precious BBS upload/download ratio margin on a DOS executable -- not an audio file -- that played a 'Magic Mushroom' commercial out of the PC speaker by bit banging. I no longer have any idea what a magic mushroom was but the fact of this commercial pouring out of my PC speaker certainly made an impression on me.

The major obstacles that remain for web audio have nothing to do with the original codec battle. Now we have to deal with implementations for iOS and Android that are broken almost to the point of uselessness.

One of the first problems with web audio started out looking like a solution. Implementors at Apple decided that a web site should not be able to start an audio clip playing without a user choice. That's a completely laudable goal. Javascript programmers can call a 'play' method on audio objects, but the audio won't play unless your Javascript is executing in a context that the browser understands is user directed.

button.addEventListener('click',function(e) {
  audio.play();
},false);

this works for limited values of works. We have now unlocked the ability to play sounds with this audio element. We can even call play again later without needing to be in a user directed call. We can even assign the audio element an entire new clip and play it later.

The only catch is that there may be a delay of many seconds between the time the user presses play and playback begins. Mobile Safari, at least, will not buffer the song until we have unlocked playback. Browser audio nodes to receive an event when there is enough file loaded to begin playback. You can at least put up a 'buffering' notice until playback is actually ready and then issue the play command once the media is ready to go. That looks something like this:

button.addEventListener('click',function(e) {
  update_status('buffering');
  audio.addEventListener('canplay',function(e) {
    audio.play();
  },false);
},false);

It doesn't work at all. The interior call to audio.play() inherits the lexical scope of the surrounding block, but whatever portion of the environment is required to unlock playback is lost by the time the 'canplay' callback fires. This no longer counts as a user-initiated event.

One solution is to create an audio node as soon as the page loads and assign it some kind of 'silence.mp3' file. You can steal the first real user event anywhere on the page and use it to unlock play on this silent file. Once that audio node is unlocked, you recycle it and assign all of your subsequent tracks to it.

The obvious problem with this recycling approach is that it doesn't leave you with a spare audio node for pre-buffering a next track. It seems obvious that you could create two phantom nodes as easily as one and then double-buffer. Alas, some mobile browsers limit you to a single audio node.

The more subtle problem with this approach is that both major mobile browsers have bugs when re-using audio nodes. Google's Chrome for Android seems to work except that it decides that all subsequent tracks assigned to an audio node have a duration of exactly 100 seconds. With luck, a metadata event will later fire with a correct duration. If you are building a media player widget with Chrome, better to wait for the real duration to arrive.

Track duration seems handy but unnecessary. I needed it for two reasons. First, I wanted to actually use it. My DiscMan could do it in the '90s. I wanted to rock that style. Second, the events that would normally fire when a track ends are unreliable at best. I resorted to Javascript 'setTimeout' calls to rotate tracks.

I have almost no problems with the HTML5 audio API. It's actually pretty nice. I have about a hundred problems with the actual implementation in every browser. Here's another problem. Mobile Safari and Chrome for Android both prevent the user from controlling audio volume with the audio tag.

The audio API exposes a volume control. Apple and Google probably ignore it to keep you from nuking your eardrums with a rude webpage. The effective result was that my listening station users had to use the hardware buttons. I printed stickers for each device that pointed to the volume up and down buttons. This was probably the most embarrassing part of the whole endeavor.

The audio API is yesterday's news in any case. 'AudioContext' is the new hotness. The audio tag was really sort of like a noisy version of the img tag. You could whack up some neat tricks with it but it was never meant for real-time effects or serious programmatic use. AudioContext takes over there. If audio tag is like img, AudioContext is like canvas. (Note to non-Javascript readers: that means it's meant to be totally awesome).

Google built a snazzy demo called jamwithchrome. You can jam. With chrome. It's like a Casio keyboard from 1990 built right into your browser. It's even more than that. It's a Casio keyboard connected to the keyboards of all your friends. It even connects to that weird kid's Casio drum machine.

AudioContext is pretty cool. It's just the thing to build listening stations with. Alas, it is slightly less stable than a Casio keyboard. It also wasn't supported on some of the iOS devices I used.

I'm definitely using AudioContext the next time somebody asks me to build funeral listening stations. For this application, I muddled through with the audio tag.

Getting the audio marshaling right was only the first problem. The next problem was actually making the web app into an immersive experience.

iOS pulled ahead here and stayed ahead throughout. iOS has long supported turning a web page into a 'app' on the home screen. These apps can run in a full-screen mode without any of the usual web browser trappings. They can be nearly indistinguishable from native apps.

The only downside is that the web page still has to come from somewhere. Mobile Safari supports
important parts of the web standards for caching offline web apps but the support for caching audio is very weak. There was simply no way to make this work at the event without running a WiFi hotspot with access to a server. That was not going to work.

Android fared slightly better on this point and only on this point. Chrome on Android gained support for full-screen apps on tablets only a few days before the event and this support seemed a bit dodgy -- especially when the screen rotated. Chrome wouldn't cache audio any better than Safari, but Chrome would let me side-load the entire site into the sdcard directory on the Nooks and run it from the filesystem. Even here, Chrome or the Nooks let me down. There was no way to save a bookmark from the filesystem to the Android desktop and have it launch properly. This meant that if the browser exited for any reason then the user was dumped back at the Android home screen without a single-click way to get back.

This is about where I started looking into 'kiosk' type applications for both platforms. The search ended quickly in both cases. For Android, the kiosks all wrap the marginal default Android browser, not Chrome. Poor Audio support in that browser made every Android kiosk app irrelevant. I used Chrome for the memorial on the Nooks and hoped for the best.

iOS was a different story. The kiosk apps all wrap Apple's very good browser. I settled on Kiosk Pro and I was delighted with it. Kiosk Pro is the paid version of 'Kiosk Pro Lite'. The pro version adds the ability to run from side-loaded content. It worked. The only hitch was that the side-loaded content could not have sub-directories. I was able to flatten the web app for the memorial so this was not a problem.

Kiosk Pro inherited some of Safari's audio limitations. It couldn't auto-play or allow users to control volume on-screen. I had a crazy collection of borrowed iPads for the event. I loaded Kiosk Pro on each of them and arranged their home screens to have empty initial screens save for Kiosk Pro.

I recall that I promised pictures of the final installation. I'll share those on side c. Here's a photo of the intermediate installation -- after I built all ten prototypes and before I realized they were too deep for the shallow bar rail at the venue. The iPad at center is supported above the concrete floor by a few LEGO bricks and force of will. The tablets by themselves actually sat pretty nicely on the bar rail. Alas, the rail pushed the volume buttons on several when laid down carelessly. The stage curtain behind the rail was poised to sweep them all off in a moment.

iPad suspended above concrete by force of will
photo courtesy your correspondent

This installment is about a month overdue. It's been a hard, busy month. I'm banging this post out now because I have a backlog of about a dozen things to tell you all. They had to wait for this. Next comes everything else. Next comes life. With life comes lots and lots of gadgets.

You guys are fantastic. I'm grateful for your support.

kiosk

I went back to Baltimore last weekend for a memorial service for a close friend and constant collaborator. It was the best I have attended.

There are few downsides to anonymous blogging. Here's item 2 from the list: 'inability to shout/blog the achievements and travails of friends and loved ones from rooftops'. It can hurt.

My friend was a music lover, something of an introvert, and beloved by other introverts. His wife had the keen idea of creating a series of listening stations around the memorial, thereby letting a room of introverts reflect quietly together.

I built ten of them. Each was a pair of Grado SR-60i headphones, a tablet machine with a dedicated listening station app, and a LEGO platform/dock/headphone stand. I learned a lot. I'll be happy if I can share ten percent.

The requirements were simple. The interface had to be simple and immersive. It had to make listeners feel a connection to my friend. The system had to be reliable. It had to be built in a space of just a couple of weeks.

The cheapest answer was to burn CDs with playlists and buy ten cheap discmen. I didn't think I could do immersive with discmen. I wanted visitors to read the band names and notice the wide age disparity evident in the tracks. I wanted them to read text about the playlists.

Climbing up the expense and difficulty ladder from a pile of junky discmen was probably a pile of iPod shuffles or nanos or any of thousands of Chinese clones. In truth, I hadn't actually touched a non-iOS iPod product in almost six years. The local Apple store still stocks them and had several on display. The nanos have been fancy touch screen devices for two generations now.

When I was a child, the dinosaurs were dead. No more. Now every pigeon fouling my slate is a fierce therapod. My world has changed completely and Jurassic Park is certainly the lesser for it. The marginal operating system that powered my original iPod never actually went away. It just turned into the software behind today's nano. The poor screen and poor software of the nano seemed unlikely to please the many savvy gadgeteers in attendance. The small size and small controls of the nano seemed unlikely to please a hypothetical technophobic Aunt Sally or Uncle Horace. After seeing, and rejecting, the real deal nano I didn't pursue any of the nano knockoffs.

By the way, a nano is $149. I'm clearly missing something. I have a house full of iPads, iPhones, Macbooks, and iMacs and I'm left scratching my head over that one. It must be a price point place holder for some new type of smart jewelry dongle.

Next up in price -- and one blonde wood table over -- was the fifth generation iPod touch. $229. Maybe the answer was ten of these. My experience with iOS has been generally good and I have no complaints about Apple's DAC selection or power sections. All the Apple gear I own can drive a decent set of headphones without an external headphone amplifier.

Though I like the devices, I don't actually like the music player app. Coverflow is as neat an effect as it ever was but it's a distraction when listening to someone elses's music. The playlist screen on my iPhone is an especially unstable point to hang an interface. From the playlist view, no play controls are available and a bunch of playlist edit controls appear.

These stations would ideally present a playlist and simple play controls and nothing else. No edit buttons. No bluetooth indicators or battery graphics or wifi beacons.

This is where the iOS devices start to run away from their hobbled iPod brethren. Mobile Safari supports full screen web apps pretty well. The app store is full of alternative webview wrappers that provide an even better experience. Most of these provide an HTML5 experience nearly on par with the built-in Safari.

That HTML5 experience, by the way, is getting pretty good. Apple's browser still seems far ahead of Chrome for Android and the antique browser native to Android. My testing showed HTML5 audio support to be much more robust. Mobile Safari also supports at least parts of the nascent 'web audio' standard for in-browser audio manipulation.

I mocked up some audio web apps for iPod touch-sized screens. I was confident that I could replicate most of the user interface of the built-in music app. I wasn't sure that I could use that screen size to build an interface that I liked that that worked for the memorial.

My friend was a reader. He read the Times while driving a small car at high speed and still somehow managed to die of leukemia first. He read the inane copy on the Chipotle burrito basket liners. He read terrible journal articles non-stop. He did a lot of that reading while listening. Jony Ive can probably pull off immersive on a four inch screen. He can probably do it on the head of a pin. I can't.

I needed a larger screen and I wanted an interface that was read and not merely seen. I wanted it to evoke paper or a vintage computer terminal. For about two cents per station and the price of a glue stick I could have tacked a sheet of actual paper to a discman and called it a day. Readable, but not immersive.

I wanted to capture listeners for at least an entire track. I wasn't trying to sell the music. I was trying to reveal the soundscape that had been under those headphones for all those years. If ever Aunt Sally had been curious about the goings on, this was the time to find out. I couldn't mock up a sheet of text that I could imagine holding a grazing listener's attention for three minutes.

The interface wizards at Bally Midway know a thing or two about capturing an audience. I used a trick from them and built an 'attract' screen from a collection of quotes from my friend's correspondence. The excerpts rotated through the bottom corner of the display at about thirty second intervals. This detail provided reading, immersion, and a connection to my friend.

This was all the more reason for a bigger screen. I first considered E-Ink readers. These are still available. Nearly all have a six inch screen. A few years ago, each had a primitive web browser and an mp3 player. In the last couple of generations, all seem to have shed their headphone jacks and audio features. Some, like the Nook Simple, have even shed their experimental web browser. Too bad.

Next up was tablets. The iPad has all the same advantages as the iPod touch and offers the bigger screen I was looking for. Better still, I already had four of them that could be used for the project.

The iPod touch shares a screen size and resolution with its iPhone cousins. The most recent models offer 326 pixels per inch (ppi). The iPad mini offers 163 ppi. The original iPad and iPad 2 offer 132 ppi. The more recent full-size iPads offer 264 ppi.

I notice a big difference between the 264 ppi of the Retina display models and the 163 ppi of the mini. In particular, I noticed a big difference between these screens when I looked at the green text on a black background of my prototype interface.

Let's just recap. My opening position was $10 discmen and I'm now debating the text quality of devices that Apple sells new for anywhere from  $329 to almost $1000? Yeah.

Once I got past discmen, I started to be concerned that I was going to wind up with a giant and expensive pile of ewaste on my hands and conscience. A non-retina iPad would have been fine for this purpose. Three of the tablets that wound up in the final lineup were non-retina iPads. They were iPads I already owned. I couldn't bring myself to buy another non-retina iOS device.

This is when I looked into rental. It turns out that a lot of local and nationwide firms rent iPads for events. I decided to just rent six iPad 3 tablets and use four iPads I already owned. I got a quote in about a half an hour and I decided just as hastily that I wasn't doing that. A four-day rental for six iPad 2 tablets was going to cost $150 apiece!

I could wrap my mind around a $750 charge for this project for tablets. I couldn't wrap my mind around the usury. Getting hung up on this point is the only thing I really felt that I did wrong in the project. I should have rented the iPads. It would have probably cost less than the rented tablecloths.

$150 turned out to be a magic number. It's within a dollar of the current price of the Barnes & Noble Nook HD+ tablet. I don't claim to understand the Nook ecosystem. I didn't need to. B&N built themselves a very inexpensive 9 inch tablet that includes 16GB of flash for $269. You should expect some compromises for that low price. The tablet is wrapped in plastic, not unibody aluminum. It has no cameras or GPS. What you don't expect is the beautiful 256 ppi display.

The Nook rocks a screen almost as large and as dense as the Retina iPad for less than half the list price. B&N sweetened the deal further by lopping an extra $110 off the price and throwing in access to the Google Play store. 256 ppi in a 9 inch tablet for $80 less than the cheapest iPod touch and $1 less than a four-day iPad 2 rental.

I bought five.

You are reading this article after Google's announcement of their new, high-DPI nexus 7 tablet. It starts at $229. I didn't buy it because it didn't exist. I don't know how it would have changed my thinking.

At this point, the tentative device lineup included iPads generation one, two, and three running iOS 5 and 6 and now Nooks running Android 4.x.

All that remained was the construction of the listening stations themselves and a simple matter of programming. The stations were less scary than the software. I started there.

I had recently admired the Apple store listening stations built to showcase the traditional iPod lineup. I passed on the iPods themselves, but the stations were tasteful. I just didn't know how I could quickly duplicate them. While wondering, I passed a LEGO store.

Frequent readers know that LEGO has many roles in my household. I'm not a fetishist. I don't collect sets. It's just a medium where I find expression comfortable. The store stocked black bricks and tiles in the bulk section where parts are sold by volume. I was expecting to sketch out parameters and dimensions, but I wound up with a design I liked. The result was a LEGO baseplate covered with black tile. A tablet dock and a headphone stand rise above the tile. Small red tiles provide an accent and add an element of 1980's arcade cabinet glamour.

listening station prototype

The LEGO bulk purchase system works by volume. The volume you fill is plastic cups that would not be out of place in a frozen yogurt joint. It is a tedious exercise to pack bricks into these cups. I think it would have easily cost a thousand dollars to buy enough LEGO for ten of these stations if purchased that way.

nine stations in a row

I learned that the bulk bins are filled from boxes of LEGO which are themselves available for sale. Any of the bricks on their bulk wall are available by the crate for $70. I bought most of the LEGO this way.

At this point, it may seem pointlessly decadent to have built the final stands in LEGO instead of wood. LEGO turns out to be the right answer. I had a chance to test the stations in the event space just a couple of days before the event. Space for the dedicated table I had imagined was going to be tight. The venue did have a bar rail along a wall that was available. The rail was sturdy, but not deep enough to hold the tablets by themselves, let alone the headphones behind. I made some measurements and rebuilt the LEGO to fit the rail. Tablet and headphones were mounted side-by-side on a new station platform that was shaped to clear the lip of the bar rail and cantilever beyond. The tablets were actually dangling over concrete supported by nothing but LEGO. In the new design, all the stations were assembled together into a linear monolith about twenty feet long.

Beep. You have reached the end of side A of the blog. Flip the blog over, and wait a few days, for the story of the software and pictures of the final installation.