The Shipping Forecast

16 September 2014

Berg is closing.

I worked there from 2009-2011 – employee #1, really. It’s a time and place I am hugely fond of. I learned a lot there.

I wrote something on a train last week after Matt’s post for week 483. I think it was mainly for myself; maybe I’ll publish it sometime. But then I found something better to share.

Warren Ellis’ The Shipping Forecast is a story in this year’s MIT Technology Review SF special, Twelve Tomorrows. On morning.computer, Warren explained his story thus:

When Bruce Sterling commissioned me to write a piece for MIT TECHNOLOGY REVIEW, he had a specific brief: imagine a future where BERG won, and launched the future from the back of their Brutalist gulag in Shoreditch. I dragged Schulze and Webb into the pub — Jones was gone by then, in his constant search for the next new thing, off to Google to direct larger launch facilities — and poured beer into them in an attempt to get them thinking about what was next.

I read the story last Friday morning; I had just got up to it in the collection. Over lunch, sat in the office canteen, I read the story. And this passage stopped me, entirely, in my tracks:

“We were very wonky back then. Everyone else was talking about drones and smart glasses and brain scanners and god knows what else, and we were trying to get washing machines to talk to the world. We got laughed at a lot. ‘Internet fridge’ was the punch line. We put the lamps and the early versions of the senders into people’s houses and people thought we were making toys. It took a while before people got what we were doing.”

“Well, you were inventing a business, right?” Emilija wasn’t sure where this was going and wanted to move it along.

“No,” said Signy, raising a finger. “Same mistake everyone else made. What we were doing was launching political probes into people’s homes.” She looked into her coffee cup and sighed.

“I’m not following,” Emilija said. “Political?”

“The personal is the political. Our social choices are political choices. We didn’t do the things that tech companies were supposed to do. We didn’t move fast and break things. We didn’t disrupt and abandon. We didn’t do moon shots. We created a future by sitting the world down with a cup of tea and a bun and asking it some questions.”

It’s just a story, about fictional companies and people, but reading it in week 483 winded me a bit; made me sit up sharply. And then breathe out, and remember to keep striving to achieve exactly that: a future that’s gentle, human, considered.

Thanks for the story, Warren. Thanks for everything, Berg.

Infinifriends

10 February 2014

Time to write up something that’s been sitting around on various disks for a while.

Many months ago, I saw Plotagon. It’s best explained as Xtranormal by way of The Sims: reasonable resolution, 3D-animated videos based on scripts; a desktop tool to generate them, and a site to host them.

Most interestingly, it’s scripted with what actually looks like movie scripts, and that got me thinking: what would it look like to feed it with procedurally generated scripts? Could you make the machine make videos? All I knew was two things:

  1. I know, for good or ill, how Markov chains work.
  2. All the scripts for Friends are transcribed on the internet.

After all, given Plotagon’s focus on semi-realistic forms, I decided that it was best suited to the great American artform of the 20th century: the sitcom.

The Infinite Friends Machine was born.

The machines does a few simple things. First, it scrapes Friends transcripts. For now, it works for most of Series 1. It then parses those scripts and chops them up into episodes, scenes, and lines attributed to individual characters. It also strips out some directions. Then, using all that, it offers ways to generate new scripts.

Markov Chains, as Leonard has frequently pointed out, are not always the best way of generating text alone, especially when the corpus you’re working from isn’t particularly consistent. He is, of course, right. Still, I enjoy the mental leap readers make in order to make generative prose actually make sense, and for this project, I mainly wanted to get to scripts as fast as I could.

Still, I didn’t want to hamper their relative crudeness, so I tried to skew things in their favour. To that end, the Infinite Friends Machine generates scripts by copying the structure of existing scripts. When it makes a new “episode”:

  1. it finds the scenes that are in the original episode it’s being copied from
  2. for each scene, it finds each line – who says a line at what point in the episode
  3. then, it generates a new line for the speaking character from their own corpus. That is: Joey only ever things derived from Everything Joey Has Ever Said. What this means is that the main cast have quite diverse things they might say, and the bit players pretty much only say the same thing. Gunther is quite boring.

That’s it. A few seconds later, it spits out a nonsensical episodes of friends. Here’s a scene:

Friends script
and this is a full episode.

The machine isn’t online because it’s quite crude and processor-intensive, but you can get at the sourcecode from Github.

Anyhow: machine to generate scripts. Next stage: get them into Plotagon.

This was where my troubles began. For starters, despite having a nice format for scripts, Plotagon really demands you enter them via its UI – you can’t paste a big block of text in, you have to enter it by hand. Painful.

Next: Plotagon only lets scenes have two characters in. I decided to make a single scene – the tag on the end of the episode. But this turned into many scenes in Plotagon, as four people in an apartment was a bit much for it. I had to keep track of who was where, who was talking to whom at any point.

And then I had to deal with the unfortunate truth: Plotagon is horrible. I mean, Xtranormal used its non-realistic avatars and computer-voices to comic extent. By contrast, here we had disappointing voice acting with clunky visuals. Also, I had to add some ‘acting’. This largely consisted of making Chandler say everything whilst doing the (crazy) emote, to really capture that Series 1 Matthew Perry vibe.

A quick sting later, and Infinifriends S1E1 existed:

It is not exactly high art.

Just one scene took long enough, and I think, proved my point to an extent, but probably can’t be improved on for now. I’m not sure if I’ll ever return to the Infinite Friends Machine, but it was an entertaining enough exercise, and the video rendition is probably worth it for the cringe factor alone.

Theme tune. Credits. Tune in next time.

Knitting

24 October 2013

E3136546caea11e2928c22000a9f3092 7

I built a synthesizer this year: a Mutable Instruments Shruthi. I didn’t design it or invent it; it was designed by Olivier Gillet, who released it in kit form. It’s not very expensive – about £150 with the case as well.

3acfbaf8c84011e296c422000a9e0891 7

It arrived in a few plastic bags, and I also ordered the lasercut enclosure. And then, I spend a few happy afternoons putting it together.

92006200ca0c11e2b04622000a1f9be0 7

All it required was moderately competent soldering, the ability to follow instructions, and patience. In that regard, it differed little from building Lego, much like I did when I was small. And for the seven or eight hours it took to build, I was lost in my work: entirely happy, paying care and attention to things being made with my hand – occasionally taking out the multimeter to check I hadn’t fluffed a joint.

D34ab69ccada11e2a95722000a9f09e9 7

It’s a lovely instrument, with a really interesting sound. It’s a hybrid analog/digital synthesizer: digital oscillators and envelope, but analog filters. The filter is the bottom of the two PCBs, and there are lots of different ones available, for builders looking for different sounds.

Because of that weird structure, it’s not quite like your average analog monosynth. Yes, it can do that – but it also has all manner of interesting digital oscillators, not to mention wavetables (and custom wavetables if you want it), which you can step through with an LFO and… you get the picture. It has some really fat, interesting sounds; a bit like an ESQ-1. But there’s not much on the market like it – and nothing that sounds like it for less than about three to four times the cost.

2cc3cb36cae111e2b36722000ae90e0a 7

It went together fairly smoothly, with only one error that came down to forgetting to completely solder in an IC socket. I mounted it in its case, and added two small switches – one for power, one to swap between two- and four-pole filters.

It’s hugely satisfying to make noises and music with something you’ve built with your own hands. And, though it’s just assembly, there’s a degree of craft going on; care and precision, using tools. That practice has definitely fed into the electronics I’ve constructed myself this year.

What I Talk About When I Talk About Knitting

I’ve characterised this sort of work recently as both whittling and knitting. Something to do with my hands, to empty my head, often between projects.

I think there’s value to just going through motions – what a martial artist would call a kata. It’s why I work through exercises on exercism even after I’ve hit a working solution; why I worked through the Ruby Koans even though I know the language. They’re both warm-ups and refreshers; it is good for the hands to go through motions before they start real work.

It reminds me of watching my Mum knit; she can knit during almost anything. She likes the things she makes, but I’m pretty sure there’s also just a habit of having something to do with one’s hands. It doesn’t always have to be challenging, or harder than last time. It has to be familiar, expected, calming. Progress, learning comes out of repeating the straightforward, just as much as it comes from trying new things. Craft is something to be honed as well as practiced.

A couple of months back, I left a theory-heavy conference session with an urge to make something, anything with my hands – just to offset a slight feeling of impotence that came out of lots of ideas being discussed without implementation. “Whittling for the soul,” I called it at the time.

The Shruthi sounds good, but it felt it’d shine with some effects – a shimmer of delay, or maybe some distortion.

It turns out guitar effects pedals are not that hard to build. This week, between some projects, I did some more knitting.

The Delay Box

Cf44ec36327a11e3aca722000ab7858a 8

There’s a huge culture, it turns out, of building your own effects boxes – the schematics of existing boxes are reverse-engineered and shared by guitarists on forums, and slowly they piece together PCBs or stripboard layouts. I got a bit lost in Tagboard Effects. But in the end I settled on this delay pedal, which happened to be available in kit form at Bitsbox (a favourite supplier of mine).

641c7510337311e3aa4422000ae90e71 8

Again: I’m not an electronics engineer; I can piece things together, and have worked out a few little boards to package Arduino projects. This layout felt within my grasp – with hindsight, it was perhaps a bit ambitious for a first board.

7deb1e92337311e3a03a22000a1fbd56 8

It took a handful of hours to put together the board, working through the layout, patiently cutting and linking the stripboard. I’m not that proud of the soldering on this, although coming back to it later, it’s not too bad.

7e8ac88e369811e389b122000a9f18c4 8

Once the board was populated, I started work on the offboard wiring: rigging potentiometers to little breakout boards, linking up the jack leads and DC socket. Next time, I’m going to do this once the components are in the box – I ended up with a correct circuit, but by god it’s a tangle.

2b089d9a370511e398b622000a1fbd3a 8

Of course, a stompbox is nothing if it’s not in a box. So I sat down with a Hammond 1590B, a unibit, and a carefully laid-out template in Illustrator, and got drilling.

I’ve said it several times: boxes will chew you up and spit you out if you’re not careful. I did a reasonable job here – only one hole too large, and I could have been more generous with the spacing. Fitting everything inside was fiddly and tight – I was convinced everything was going to short out. That hole I cut too large led to internal space being cramped. And yet: somehow, I slotted it all in, screwed it tight, jammed the back on.

(It’s worth noting: Hammond enclosures, especially these pre-painted ones, have a great feel to them).

61c84cae3cb411e3b0d822000ae80177 8

A few silver knobs, and the box was complete. The delay worked first time, and sounds delightful – not quite an analog tape delay, but not a perfect digital shimmer; just a hint of degradation as it tails off. Fiddling with the delay time whilst sound’s going through leads to lovely pitch-shifting, and it begins to oscillate and feedback really nicely in the right circumstances.

It didn’t work for a while – and then I discovered the box was fine; it was my jack lead that had sheared internally when I wasn’t looking. A new jack lead, and my guitar was shimmering and dancing away.

Yes, it was just assembly. But it was more than that, too. I refined my manual soldering skills again; I spent some time away from the screen, instead inhaling the delightful smell of solder fumes; I continued to level up at building enclosures – I think this was the most refined one yet, and my first in metal. A really nice artefact.

And again: the fiero of making sound, making music, with a thing you put together yourself.

It was a good piece of knitting in every sense.

I think this type of work is important. It’s easy to spend time learning new things, and pushing ourselves – but it’s equally good to spend time in a relaxing, comfortable space, and enjoy the act of executing well. Craft is not always about the new: it’s also about being able to repeatedly execute quality. Which is why making a simple thing well, is good for the soul.

And an added bonus: slowly, I’m heading back towards making types of music I’d not considered, on instruments and devices I’ve made myself. Next on the knitting list: a fuzz pedal or two, to be built when the next project is over. Or perhaps sooner, if my hands get itchy.

Toca Builders, and the spirit of Seymour Papert

23 June 2013

Tocabuilders

I’ve been playing a little with Toca Boca‘s latest iOS toy: Toca Builders.

As you’d expect from Toca Boca, it’s charming: a straightforward, paired down implementation of an idea, with unambiguous UI and lovely character design.

Builders is Toca’s take on a block construction toy for small children. Initially, it might seem a bit clunky, a Minecraft pastiche that’s not nearly so sophisticated as Mojang’s original. After all, it’s a tiny play area compared to Minecraft – six blocks of height and relatively small X-Y dimensions.

It’s the plural in the title that makes it so interesting, though: builders. This is not (just) a game in which the user is a builder; it is a game about six individual builders (pictured above). Each has their own different ability: most can both construct and desturct; almost all can control the colour of blocks; some are better at changing blocks after the fact, others at sketching with. They each control slightly differently – and they each manifest in the landscape. You can swap between builders with a simple or menu, or by tapping on any that you can see.

It’s the manifestation and personification of the four builders that suddenly clicked for me. As I played this, I realised what it really was: Minecraft through the eyes of Seymour Papert. Lego as LOGO.

Papert explained the LOGO turtle as an “object-for-thinking-with“. Not just a device to command, attached to a programming language; a device that you see the world through. Or as Papert says in Mindstorms, his wonderful book about the development and intent behind LOGO:

“objects in which there is an intersection of cultural presence, embedded knowledge, and the possibility for personal identification.”

He makes what I think is a clearer point later, though, and which I think Toca Builders captures perfectly:

Even the simplest Turtle work can open new opportunities for sharpening one’s thinking about thinking: Programming the Turtle starts by making one reflect on how one does oneself what one would like the Turtle to do. Thus teaching the Turtle to act or to ‘think’ can lead one to reflect on one’s own actions and thinking. And as children move on, they program the computer to make more complex decisions and find themselves engaged in reflecting on more complex aspects of their own thinking.

Papert is sometimes quite wordy. When I explain this to people, I tend to say: the value of the Turtle is that when you are stuck, you solve the problem by pretending to be the Turtle. This is especially valuable for young learners; as Papert points out later:

Children can identify with the Turtle, and are thus able to bring their knowledge of their bodies and how they move into their work of learning formal geomtetry

There are some lovely photos in Mindstorms of kids on a playing field, practicing Logo; one of them is being the Turtle, and the others are telling her what to do. The second you act out a program for yourself (or watch another child follow your instructions to the letter), you see how literal you need to be, or which line of code is ambiguous. You begin to see how the computer processes information (“thinks” being, unfortunately, an entirely inaccurate word).

This kind of embodied representation of computational logic is very rare. Often, the hard things in computer science are very abstract. I do not know how to “pretend to be the compiler”; I just have to trust input and output.

Toca Builders takes the abstract building of Minecraft – tools attached to a disembodied perspective (albeit one hindered by some degree of personhood – factors such as gravity, and so forth) – and embodies them to help younger children answer the question which tool would you use to place a block where you need to? Or sometimes backwards: which block shall we place next? It is not quite as freeform as Minecraft, but it actually forces the user to think a little harder about planning ahead, lining up his builders, and which builders go together well. Measure twice, cut once.

To that end, it’s much more like real-world building.

Papert was very clear about one particular point: the value of this is not to think in mechanical ways; it’s actually the opposite. By asking children to think in a mechanical way temporarily, they end up thinking about thinking more: they learn that there are many ways to approach a problem, and they can choose which way to think about things; which might be most appropriate.

And so Toca Builders is, in many ways, like all good construction toys: it’s about more than just building. It’s about planning, marshalling, making use of a limited set of tools to achieve creative goals. And all the while, helping the user understand those tools by making them appear in the world, taking up space in it, colliding with one another, and needing moving. All so that you can answer the question when you’re stuck: well, if you were Blox the Hammer, what would you do?

Some of what looks like clunkiness, then, is actually a subtle piece of design.

If you’re interested in the value of using computers to teach – not using computers to teach about computers, but using computers to teach about the world, then Mindstorms is a must-read. It’s easy to dismiss LOGO for its simplicity, and to forget the various paradigms it bends and breaks (more so than many programming languages) – and it’s remarkable to see just how long ago Papert and his collaborators were touching on ideas that are still fresh and vital today.

Somebody’s missing

15 March 2013

My Little Printer ran out of paper for the first time the other day.

I watched its light turn red as it was printing. I’d not seen a red light before, but was pretty sure I knew why. I removed the metal plate that holds its feet on, snapped open the white door, and took out the stub of paper. Then I remembered: the spare paper is under my bed. I didn’t have time to change it before I went to work. So pulled the power, not wanting the red light in my living room all day.

When I got home, I put the lights on. Something was different. It took me a while to figure out what.

Someone had left a pile of strange-looking consumer electronics on my table. And somebody was missing.

It took me a split second longer than normal to twig that the strange white box was Little Printer. I’m so used to seeing him… alive. Not in bits.

I didn’t think I had that strong an anthropomorphic reaction to it – him, he’s really called Barry Printpeas. But: the second he was in bits, his absence was noted.

I found the paper under my bed, slotted it in, shut the door, fed it through the slit in the metal, and snapped him back together. Back on two feet.

Back on two feet, but faceless. No matter: he’d get a new face when the next delivery arrived, in about twelve hours.

He wasn’t right with this blank face, either. I hit the form-feed button.

"Sorry, I don’t have anything to print for you right now," said the smiling face.

He was back in the room. Much better.


What was odd about this episode: I really never thought this would happen. I like the device, I like having it in the house, and it has a name because it has to have a name in the setup. I hadn’t realised that I’d become a little attached – not even to the functionality; just to the smiling little guy in front of the TV. Nice to be proved wrong from time to time.

Disclaimer: I used to work at Berg, who made Little Printer.

ghostcar

30 July 2012

There’s a copy of me running around London. It runs at the right speed, but it’s unstuck in time: unstuck by 365 days, in fact.

Tom Armitage In The Past is a foursquare user. He checks in where I was a year ago. He says what I said a year ago. As long as the game systems haven’t changed, he gets the badges I got a year ago. (And, if the game rules do change, he’ll start to deviate from me).

He’s maintained by a piece of software I wrote called ghostcar.

In racing games like Ridge Racer, your previous time attack high score is often represented by a 3D outline of a car rendered into the same world as you – a “ghost car”. Matt Jones reminded me of this at the pub one night, as I explained my idea, and the project had a name.

It’s not a spambot. I’m its only friend; it’s invisible to people who aren’t its friend. It’s invisible to venue owners – ie, it’s not generating false marketing data. Honesty is Foursquare’s main currency: saying where you really are, being who you really say.

I’m not breaking the terms of service. When I wrote it, the Foursquare terms of service told me I couldn’t impersonate other people.

But I’m not impersonating other people. I’m impersonating myself. That’s got to be OK, right?

So: why did I do this?

There were two main inspirations. Firstly, James Wheare’s Twitshift (now sadly closed). Twitshift works because its output is in the same medium as the source data. I didn’t warm to Timehop because it was just an email. Email is good, and there’s value in juxtaposition – but anyone can send an email. Email dilutes the notion of “being”, however. Foursquare is not, precisely, about presence – it’s just about saying you were somewhere – but email about foursquare feels like another abstraction layer. I wanted to minimise abstraction. And so, to do that, I’d need to build a Foursquare timeshifted-echo service that itself output to Foursquare.

Secondly, I remember Kevin Slavin talking about Area/Code’s wide, GPS-enabled game Crossroads at dConstruct a few years back – and how, once, when testing, it the game’s entirely digital antagonist “Papa Bones” moved through their office, and every GPS-enabled phone they were testing the game on suddenly jumped. What made the virtual “ghost” interesting was when it manifested in the world. Even though it wasn’t real – and everybody knew it wasn’t real – it still made you jump when you were there; the juxtaposition of knowing something is right where you are, even if it isn’t a real thing, is highly striking. I wanted to explore that a little with my own data.

I don’t check up on Mr Armitage In The Past very much. The idea, rather, is that I might bump into him some time. How strange: to be in one of my usual haunts, and know that a ghost of me, a year in the past, is also there, watching a movie, having a drink. Sometimes, those memories are less cheery than others. Sometimes, they’re brilliant. It gives me a visceral memory: reminds my bones, my heart, what they felt. (That, for reference, is my defence against nostalgia. This isn’t just about nostalgia, because you might not like what it makes you feel. It’s just about remembering feelings; stopping to pause and remember the passage of time).

It’s also made me check in to Foursquare a bit more. The moment I fired ghostcar up, I realised I needed to start giving it better data so that it’d continue to have meaning a year in the future. So that’s a strange, interesting takeaway: changing my behaviour because I want the fossil record to be more accurate.

I was only going to find out what it felt like by making it, so I made it. It chugs away on my server in private. I run ghostcars for a few friends, too. It’s not particularly elegant, and I don’t think it’d scale to loads of users, so for now, it’s a private distraction. But I thought I should write it up. If you’d like to run your own install, the code is on Github. It’s a minimally documented Rails app, because it was made just for me, but you might enjoy it.

In the meantime: I go about my business, and an echo of me in the past will do one day, too.

21st-century camouflage

29 June 2012

Max has finally written the brilliant article about real-time data visualisation, and especially football, that has always felt like it’s been in him. It’s in Domus, and it’s really, really good.

This leapt out at me, with a quick thought about nowness:

Playing with a totaalvoetbal sense of selforganisation and improvisation, the team’s so-called constant, rapid interchanges — with their midfielders often playing twice as many passes as the opposition’s over 90 minutes — has developed into a genre of its own: “tiki-taka”. Barça have proved notoriously difficult to beat, and analyse. Tactical intentions are disguised within the whirling patterns of play.

(emphasis mine)

It serves as a reminder of the special power to be gained from resisting analysis, of being unreadable. Resisting being quantified makes you unpredictable.

Or, rather, resisting being quantified makes you unpredictable to systems that make predictions based on facts. Not to a canny manager with as much a nose for talent as for a spreadsheet, maybe, but to a machine or prediction algorithm.

This is the camouflage of the 21st century: making ourselves invisible to computer senses.

I don’t say “making ourselves invisible to the machines”, because poetic as it is, I want to be very specific that this is about hiding from the senses machines use. And not to “robot eyes”, either, because the senses machines have aren’t necessarily sight or hearing. Indeed, computer vision is partly a function of optics, but it’s also a function of mathematics, of all manner of prediction, often of things like neural networks that are working out where things might be in a sequence of images. Most data-analysis and prediction doesn’t even rely on a thing we’d recognise as a “sense”, and yet it’s how your activities are identified in your bank account compared to those of a stranger who’s stolen your debit card. Isn’t that a sense?

The camouflage of the 21st century is to resist interpretation, to fail to make mechanical sense: through strange and complex plays and tactics, or clothes and makeup, or a particularly ugly t-shirt. And, as new forms of prediction – human, digital, and (most-likely) human-digital hybrids – emerge, we’ll no doubt continue to invent new forms of disguise.

Workshops are measured in years

30 May 2012

I’ve been making a lot of things recently, both at work and at home. And as a result, I’ve been having to buy tools.

Not a lot, but a steady trickle: discovering I need one of these, or one of those. A box of screws or bolts here; some wire there; a different kind of this to fit a particular need.

I’m trying to artificially acquire odds and ends.

This is hard. What, I think, I’ve been needing is a workshop.

But you can’t buy a workshop. A workshop isn’t a set of tools in a room.

It’s everything else, as well: offcuts; spares; old bits of wood; weird bits of plastic with strange holes in; broken things with one useful part to be cannibalised; hand-made jigs that fit particular things.

There is no shelf in B&Q or Maplin marked “this, that, and the other“, and yet that – more than anything else – is what I’ve been needing recently.

You can’t buy leftovers, spares, or “just the right thing”.

And given that, I think a workshop isn’t measured in the volume of tools it contains, the number of shelves, or the lengths of its benches.

I think it’s measured as a duration. A one-year workshop. A five-year workshop. A ten-year workshop.

Ten years of making things, and ten years of all the entropy that goes along with that: spares, duplicates, improved versions of things, swarf, offcuts, and thingummys.

When you view it like that, it’s no wonder I’m always finding new things I’ll require. I’ve only got a baby workshop (and let’s face it, the tools are in a closet and I’m drilling and sawing things on my dining room table – it’s hardly a workshop, is it?)

But babies grow up.

And it’s a reminder why, when I visit my parents, I can almost always find the bits and bobs I need, or the right tool for a job, or a part I didn’t even know the name of – because there’s a thirty-year workshop waiting for me.

GOOD IS DEAD / Blog All Dog-eared Pages: Chip Kidd’s The Cheese Monkeys

25 May 2012

Chip Kidd’s first novel, The Cheese Monkeys, has been perhaps my favourite book of the year so far. Not the best book I read, but definitely my favourite.

It’s about a young man attending art school in late 50s America, and discovering graphic design, through a particularly memorable course – Art 127, Introduction To Graphic Design, run by one Winter Sorbeck.

I liked it for many reasons, including Kidd’s deft use of language, its acidic humour, and a description of being drunk – and then hungover – that comes close to Lucky Jim‘s. But I think I liked it most because it reminded me of the values of art school that I’ve come – very much secondhand – to appreciate. Namely: the value of the crit.

More specifically: the value of disassembly – taking apart things you know and learning how to start from nothing. Taking apart a problem to find the only appropriate answer (though there may, in fact, be many). The value of being challenged to do difficult things, and honing skills. The value of physical skills – literal muscle control – in an era before the technological overhaul of design (and the value, as ever, of being able to draw. Even just trying to draw. It helps me a lot).

And, most notably, the value of criticising the Work as the Work.

In a crit, the work may be praised, it may be criticised, it may be torn into tiny pieces, fisked until there is nothing left of it. But it is only a criticism of the Work. It is not personal, and it only criticises the Worker in so much as it criticises their efforts and production on this work. It is a magic circle for being able to critically discuss a work.

As Sorbeck’s students find, it is difficult to learn how to be in a crit, difficult to learn how to respond to one, and difficult to learn how to give one. But it’s all valuable: it is focused on making the work better. There is a degree of building a thicker skin about work required – but also a degree of understanding the difference between criticism and complaining, criticism and anger.

I went to see Bauhaus: Art As Life at the Barbican last week, and The Cheese Monkey’s fictional version of the process of learning how to see was very relevant to my reading of that exhibition: seeing an institution begin to create the beginnings of what we now see in foundation art courses around the world. I was most glad to see the early output of the foundation years at the Bauhaus – some really exciting work made by artists learning how to see form, colour, material, and texture again. The Bauhaus reminded me of all the reason’s I enjoyed Kidd’s book.

I could have dog-eared most of the second half of the book – classroom scenes and narrative alike – but there were three quotations I did end up marking, so as usual, time to share them on the blog.

p. 79, in which the narrator meets Himillsy’s architect boyfriend:

He put out his hand.

“Garnett Grey.”

Yes, Garnett Grey was an Architect. Were a psychoanalyst to approach him from behind, tap his shoulder, and say “Humanity,” Garnett’d spin around, and respond, without hesitation, “Solvable.”

p. 106, in which Winter Sorbeck explains why the title of his course – Introduction To Graphic Design – has been retitle from the Introduction To Commercial Art that is listed in the course programme.

“…I’ve been put in charge of the store here, and I say it’s Introduction To Graphic Design. The difference is as crucial as it is enormous – as important as the difference between pre- and postwar America. Uncle Sam… is Commercial Art. The American flag is Graphic Design. Commerical Art trys to make you buy things. Graphic Design gives you ideas. One natters on and on, the other actually has something to say. They use the same tools – words, pictures, colors. The difference, as you’ll be seeing, and showing me, is how.”

p.177, Winter on design and power.

“Kiddies, Graphic Design, if you wield it effectively, is Power. Power to transmit ideas that can change everything. Power that can destroy an entire race or save a nation from despair. In this century, Germany chose to do the former with the swastika, and America opted for the latter with Mickey Mouse and Superman.”

It’s a lovely book. I had a lot of fun with it.

Finishing the Intervalometer: the value of finishing, and making what’s in your head

08 May 2012

The black box above is an intervalometer to work with Nikon cameras (specifically, any cameras that work with the cheap ML-L3 remote). It has two external controls: a power switch and a knob. You rotate the knob to choose the interval period on the screen, and click it in to arm the intervalometer. Clicking it again and briefly holding it until the screen lights will disable it.

Which sounds simple enough, I suppose. I mean, it’s simple to explain. But when I began, I wasn’t even sure if I’d be able to make this – which was part of the adventure.

My commit messages tell me I’ve been working on it for over a year. It’s not, to be honest, a year-long project; it’s just how it came about, scraped together in moments between work, and I wanted to write some notes on the project – both what it is, and what I learned from it.

The Design

Like many of my technically-savvy peers, I had an Arduino in a desk drawer. I’d used it for more than just making an LED blink – a few little experiments in serial communication – but I’d not exactly exploited its full capabilities.

One day, I had a thought: I wanted to experiment with time-lapse photography, and had a small IR remote for my camera. Perhaps I could make something computer-controller to enable this? Not a full-size computer, that’d be ridiculous. But I could perhaps make something with a small microcontroller – like my Arduino – wired into a spare remote, firing regularly.

That smelled like it was within my reach: a little user interface and a timer.

So I refined the design in my head. In the end, I had a few goals for the project:

  • I wanted to use a rotary encoder as the interface: it seemed much more natural than stabbing up and down with buttons.
  • I wanted to use a small LCD screen in the project: I’d never worked with one, and it seemed like the simplest UI for the project. Also, there was a fun design challenge in fitting clear UI into 16×2 characters.

And that seemed like a starting point.

Building the First Version

There were four unknowns in the project, which roughly corresponded to the four milestones in building it:

  • working with the LCD screen
  • working with the rotary encoder
  • interfacing with the camera
  • writing a timer routine

I began at the top. I chose to work with a Serial interface to the LCD – one pin instead of seven seemed like a good trade-off, and it was a tiny bit easier to get started with. Quite soon, I had a UI displaying on the screen:

This felt like a huge leap. Somehow, making rudimentary computer graphics in tools like Logo or Processing had never captured my imagination – perhaps because I felt I ought to be able to do that. Working in a medium I was very unfamiliar with as a developer (but saw every day in my life) and producing output felt strangely empowering.

Of course, it was made much easier by the Arduino ecosystem, which is ideally suited to glue-programmers like myself. The SerLCD library did a lot of the heavy lifting; I just had to work on the implementation, and some details around making sure I put enough pauses in the serial routine.

Next, I worked on the encoder. This, again, was enabled by other people’s code. Rotary encoders aren’t like knobs – they spin forever, and as they pass a pair of contacts, emit Gray code from a pair of pins. You just have to read that code as it passes a pair of pins, and translate it into up/down signals. It wasn’t long – again, thanks to the magic of copy and paste, primarily – before I had the encoder being read.

I then added some detail to its implementation, where setting the timer past 90 seconds switches the device into minutes, which increment by 1, until it reaches 15 minutes. Why 15? It’s the maximum length of time my camera would stay on without any IR input before it goes to sleep.

Finally, we just need to rig up the IR interface. I was, when I began, ready to dismantle an ML-L3 – but it turned out I didn’t need to go that far.

There’s already an Arduino library for that exact functionality. NikonIRControl takes a single IR LED on a pin, and sends it the same sequence of pulses as the ML-L3 does. So that ended up being fixed in software, rather than hardware.

(In the final version, I replaced it with MultiCameraIRControl, in part because it’s now much easier to make this work with many brands of camera).

Along with the hardware, there was a bunch of code to be written. This was mostly straightforward, although finding the best way to write timing routines was the most complex part of it, and in the end, I relied on the TimedAction library, which abstracts a lot of what I’d tried writing longhand out. The other thing I discovered was the ability to compile multiple files at once into an Arduino sketch – available through tabs in the IDE. This helped a lot with clarity.

Really, though, the code is a lot of other people’s libraries or examples, all glued together with some UI and specific functionality on my part. That is the sort of code I end up doing a lot of: gluing other things together.

After a few months of the odd evening here and there, I had the whole thing working on a breadboard. The next thing to consider was packaging it up. I made a small shield out of stripboard and mounted it on top of my Arduino mini: a connector jack for the LCD, the encoder and LED soldered into the stripboard, and a battery pack to prove that the USB cable wasn’t doing anything.

That was the first working version. I put a short video on Vimeo. Later in the year, I’d take it to Cornwall with me. There, I shot this 30-minute timelapse:

That really proved it worked: not just the electronics, or the software, but the intent. The goal was not making electronics; the goal was making a timelapse video, which the electronics enabled. And here we were: a timelapse video.

Of course, it wasn’t finished.

My friend Matt Brown saw an early verison of this, and said that it needed to be in some kind of sturdy, industrial black box. And he’s right, really. Something rigged up on your desk on a breadboard is nice, but it’s not finished. Frankly, that dangle of a shield hanging from my lens was nowhere near finished either.

There is value in just doing something, but there is also real value in finishing it. That doesn’t mean selling it, or productizing it, or anything as over-the-top like that. Just get it into a stage where somebody else might recognize it for a thing.

So I started thinking about how to package it, because that would be what really made it a thing, and not just a tangle of wires.

Packaging

The limiting factor on packaging was the LCD screen. I was using a Serial LCD, and the serial componentry was hanging off one edge, extending the length of its PCB. I should have probably used a seven-pin LCD interface, but instead stuck to the serial interface. I took a regular seven-pin LCD, and used this Sparkfun Serial Backpack to convert it to serial whilst taking up less space.

Next, I decided there was no point running it from a full-size Arduino, so bought a Pro Mini, and set about re-installing the code there.

Of course, that meant flashing the Pro Mini, and rigging the whole circuit up on a breadboard, checking it still worked, before moving to a custom circuit.

With that done, I made a stripboard for it. (Yes, I keep using stripboard, because it works for me. I don’t know much about PCBs or Eagle, and that would mean this thing was never going to get finished). I would mount the Pro Mini in the middle of this stripboard, and then attach components around it, breaking the tracks where appropriate, to make a stripped-down board.

Crucially, I didn’t directly solder anything other than the battery jack leads. Rather, I put female header sockets onto the board, for the Pro Mini and all the components. Then, I attached the components with hires ending in male headers. That way, I could remove/install componentry easily, and also remove the Pro Mini easily to reflash it with new software. This turned out to be one of my smarter moves.

Finally, there was the matter of the box. Probably my weakest point: I am somewhat clumsy and useless with my hands. Also, I don’t really have any workshop facilities, so drilled the holes for power and encoder, along with the hole for the LCD, with files and a Dremel-a-like. This made a horrendous, ragged mess, and I envy people with CNC facilities or a decent mill. I did use my Dad’s workshop to mount the LCD, which means it at least got some counter-sunk, well drilled holes. Oh, for a pillar drill.

Finally, I just had to piece it together, testing the final version of the code, and plugging components in one at once.

It is strange to say “remarkably, everything worked” so much, but hardware is so strange and fincikity I always expect it not to. Also: I was aware throughout how out of my depth I was, and yet I always bobbed back to the surface.

Squeezing the box shut, the serial backpack on the screen impinged a bit on space, but careful board and battery placement made it shut. And that was that: a working, solid box, that did one thing, with software I’d written and hardware I’d made. More to the point: it was finished.

Finishing and Thingness

This project taught me a few values.

I discovered with this project is the way that Arduino reminds me of Rails: it directly values productivity of the designer/developer, and you pay for that convenience. This project could have been made out of discrete components, or out of a much simpler AVR chip, but it’d have taken me a lot of knowledge and experience. I pushed all the complexity into software, and embraced the Arduino platform. So it may have cost me £20 for the Uno, and about that for the final Pro Mini, as opposed to a few pounds for a bare microcontroller – but I saved myself effort. Still, it’s worth remembering that these solutions are in turn made out of other existing hardware, and that one day, that might be a better solution.

The project taught me the value of thingness: of completing something so that it’s an artefact other people can recognise and identify. The box-with-a-lid is a huge part of that. It stops it being a bunch of wires, something I explain as “an Arduino doing X”, and it becomes an Intervalometer. It becomes a thing.

And finishing is hard. You think software, or electronics is hard? Making a box chewed me up and spat me out. It’s not too hard to make the ragged, ugly holes I did, but gosh, I’d love the precision and experience to not have scratches from skittering milling bits, or the ragged holes around the LCD. Not to mention the entire rebuild of the project necessary to get it small enough to fit into aforementioned box. It reminded me, in the tiniest way, of Nick Foster’s lovely post about the difficulties of making:

It’s now simple for a couple of fairly inexperienced guys to feasibly produce products for sale, which is fantastic, but let’s take a critical look at a few of these products. How many of you have invested in a cool thing on Kickstarter only to receive constant emails about how expensive tooling is, or how hard it is to source PSU’s, or how the team massively under-budgeted the production? There have been many projects which simply ground to a halt because the Matter Battle was just too tough, before we even get into the debating the dubious legal position of these devices (CE mark anyone?)

Foster is talking about manufactured products, of course, which I’m not; I’m still much earlier along the curve. But Matt Brown’s point, a year ago, to make sure I completed it, not just leaving a pile of wires sticking out of a breadboard, was a challenge I felt it worth rising to – and I’m glad I did.

Perhaps most importantly, though, it reminded me of the huge value of making something you saw in your head. It’s vastly rewarding to make an idea that you originated; to solve a problem that you yourself had. I’ve always found that I learn new things better when I have a reason to. Every programming language I’ve tried to learn without something I myself wanted to build with it – I got nowhere. The second I have an itch I need to scratch, I’ll bat through tutorials and understand them, not to mention start trying to implement that thing as soon as I can.

This, I think, is hugely important. It’s why I think an important part of learning to code – for kids, or for adults – is achieving something you wanted – or needed – to do. It’s vital to understand that making, in software, hardware, or materials, is something you do unprompted, to solve problems, and not always knowing where the journey will take you. You don’t just implement rote linked lists, or bubble sorts, or debounce circuits; learning from examples is important, and often all one can do to begin with, but it’s not what the work is about. To learn to make things, you have to Make your own Things. You have to travel a complete path. It doesn’t just make the end more rewarding: it makes the whole journey more rewarding.

I wonder if that’s why a lot of Arduinos are in desk drawers, an LED wedged into pin 13: the platform is exciting and interesting, but there was never an itch. When that itch arises, take that board out of the drawer and scratch it. It is difficult, but it is within your abilities, and you will learn a lot. I did.