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.