Need is as I defined it previously: something beyond a want. Something that can't be satisfied by a decent attempt, a good try, or anything short of actual success. Something that's necessary for me to live, either because I wouldn't be alive without it, or because what's alive wouldn't be me.
Beautiful is, in some sense, just my subjective sense of aesthetics. But I also believe in objective beauty. Something can be beautiful in function by achieving its purpose so well that it becomes an ode to the platonic ideal of that purpose. And something can be beautiful in concept by bringing together ideas and connections in such a profound way that experiencing it gives you a new understanding, even enlightenment.
A thing is an object that exists outside of myself, with some kind of tangible, reality-based nature. A balloon animal is a thing, but an idea for a new video game is not a thing. An idea for a new video game that you write down is a thing, but the thing is the writing, not the idea. And, of course, it's the plural: not one thing, but many things; enough that you don't think of them individually, but rather as an awesome mass of stuff rolling together and picking up speed as it goes.
I've been thinking about this for a while; different wordings, different concepts, different qualities that could make the cut. But I keep coming back to this one. I think if there's anything that's defined my work, not just over the last few years, but back as early as I can remember, it's this. I need to create beautiful things.
What do you need? Food and shelter? Friends? Relationships? And what makes these needs as opposed to just wants?
The first and most obvious difference is consequence. When you can't find shelter, that's a lot bigger problem than when you can't find a decent cafe. If you run out of ice cream, you might be sad, but you won't starve. Measured that way, needs are just the wants with the highest stakes. But that doesn't tell you how much consequence you need for a need.
And as soon as you get beyond purely physical needs, consequence becomes tricky to define. Eating is high-consequence, sure, but what about a relationship? You might be deeply unhappy without it, sure, but you won't die. And if you set deep unhappiness as the bar, then getting to see your favourite football team is a need too. We'd be unhappy to miss out on anything we want, but that just puts us back at the question of, well, how unhappy is unhappy enough?
I think a better way to look at it is to work backwards from behaviour. How do you act when you want something vs when you need it? If you want to eat, you might check the fridge, realise there's no food, find that the restaurants are closed, and then give up. But if you need to eat something, you don't stop there. You go to the supermarket. You check if the neighbours have food. You go door to door. You beg on the street. Needs don't permit giving up.
It's easy to give up on wants because often you just want to feel like you tried. Well, couldn't find a good cafe, but I had a look around. Couldn't buy ice cream, but I checked the shop. This is the minimum effort required to show that you did something that could feasibly have resulted in your goal. Who's going to criticise you when, clearly, you put some work in? But you can't say, look, stomach, I tried to find food so don't get hungry at me. A need doesn't care about effort, only results.
So I think there are more things that we can recognise as needs. Food and shelter, sure, you're always going to do everything you can to get them. But what about things where the consequence isn't starvation, but a slowly growing sense of dissatisfaction? What about the things you need, not so that you stay alive, but so that being alive is meaningful?
Letting your dreams be wants rather than needs – saying that you want to make music or write novels or raise chimps in Zimbabwe – is to say that you'd be okay if you gave them a shot and they didn't work out. But are you really okay with that? Would you be satisfied, looking back on your life, knowing that, well, it was worth a try?
If not, then what you have there is really a need. And it's worth thinking, what would you do for that need? Quit your job? Ask people for help? Move countries? Leave a relationship? If you'd do those things for food and shelter, why not do them for a dream?
2017 was a strange year for me. I started the year in retreat from my goal of writing every day and I don't think I really found my feet again. Since I began this part of my life in 2015, my posts here have acted as my monologue, my stage directions, and at times as my Greek chorus. I set out realising that the paths laid down by others weren't working for me, and resolved to make my own. I spent the last few years on a quest for meaning, and storytelling is a way to pull meaning from the chaos of real life. I deeply regret having stopped.
I had a lot of unconsummated plans in the last year. I began the Conventional Wisdom Project which, appropriately enough, ended on Better Late Than Never, which I never finished. I started looking for ways to commercialise my creative output, which resulted in somesuccess, but mostly I floundered on that front. I began a residency with the intention of producing an exhibition at the end, but I had an unforeseen family health crisis that ate the end of the year when it would have happened.
I did manage a few projects I was particularly happy with, Automata by Example and Cardiograph, but all told I would call my creative output for the year pretty lacking. Instead, it was really a year for introspection. I realised that I need to take the commercial side of my work much more seriously, that I need to make a concerted effort to define and promote myself and what I'm doing, and that my main letdowns have been lack of execution and lack of ambition. I realised that I can't achieve extraordinary goals by ordinary means, and that pride, humility, restraint, reasonableness and moderation are all ways of being ordinary.
So my aim is for this to be a year where I aim higher, push harder, and make more noise while I'm doing it. That starts, as is tradition, with this site. I'm going to spend some time writing about who I am, what I do, what I want and what I have to offer.
Most importantly, I'm going back to writing every day. I may need to change the way I write to make it work, but I can tell now that this means more to me than just a creative outlet; it's me telling the story that I'm living. Or maybe vice versa.
Today I'm releasing Starboard, a fun demo I made to recreate the sound of Bag Raiders' sleeper internet hit Shooting Stars using Web Audio.
This was an interesting one to make, because the code was actually not that difficult, but trying to recreate a specific synth sound turned out to be way beyond my expertise. I originally intended it to be a 1-day project but it took a whole week to finish, of which around one day was spent writing most of the code, another papering overgaps in theWeb Audio API, and one more making it work in Safari. The rest of my time was just fiddling with parameters over and over again trying to get it to sound right.
I tried a bunch of different effects, filters, EQ, compression, etc, but in the end the thing that sounded the best was just the basic synth, a bit of vibrato, and some reverb. It still doesn't quite have the thin cheesy sound of the original, but that may actually be for the best; a couple of times I had something that sounded close when I played it with the real track, but when I listened to it without any of the bass or backing synths it just came out hollow. In the end, I think just focusing it on making it sound good and letting go of exact reproduction was what I needed to do to get a sound I was happy with.
Most of the internals proceeded fairly normally, though this was the first time I'd had to write an actual sequencer (as opposed to, say, the node-based scheduling code in Markov Technology). I just used timeouts, which was basically fine, except that the scheduler loses time under heavy CPU load, which can happen pretty easily on mobile. I was, however, really pleased with how I represented notes internally; I'd previously used frequencies or scientific pitch notation (like A4), but this time I used MIDI numbers and everything suddenly became way easier.
But the one thing I think I'm most proud of is the way I did the starfield animation. In Markov Contact I started trying something I think of as deterministic animation, where every frame is a pure function of time and a (usually random) initial state. I cheated for a few of the animations back then, but this time I really nailed it. The code is super small, loops seamlessly and, even better, if you hide and show the starfield (like I do a bunch), the stars "keep moving" even when the animation isn't running.
So all up, this was a bit of fun, and a good chance to refine some existing audio & animation techniques and re-remind myself of how hard audio production is. If you'd like to check out the code, it's on GitHub.
This is a write-up for Cardiograph, a social/technological experiment I ran as part of Culture at Work's event Science: A Body of Facts. Each entrant to the event had their cardiac activity measured by a homemade ECG and drawn in real-time on an ID badge that they wore throughout the event.
For a long time, I'd wanted to do something interesting with ECGs (as opposed to EEGs as in Project Brain or Mind Music). For one thing, the collection and processing on ECGs is much less complicated, and for another, people feel a much more direct connection to their heartbeat than their brain activity; they can feel it, manipulate it fairly easily, and it has significant and obvious health implications.
To that end, I'd bought an Olimex EKG-EMG shield, basically a glorified differential amplifier with a huge gain and some filtering. The thing is super cheap, pin-compatible with Arduino, and works great with a little fiddling and smoothing on the software side. It comes with an example Arduino sketch which I used to stream the data over USB serial to my computer.
However, while I had the data, I didn't really have an application other than just gawking at my heart rate. The perfect opportunity presented itself when I got a chance to play with my friend Joseph's AxiDraw plotter. I used it for a tech demo with Scrawl, which gave me a pretty good idea of its capabilities. It turns out to be very easy to interface with via USB serial.
These two pieces together gave me the idea to make an ECG that would actually draw on paper. Although modern ECGs use digital displays and have fancy built-in analytical functions, the original ones were completely analogue: just some large electromagnets, conductive string, and a photographic plate. Reproducing this using the combined powers of modern digital amplifiers, high-precision stepper motors and an overpriced laptop seemed delightfully anachronistic.
I wrote the code entirely in Rust, a language I'd experimented with before but never built an entire project in. It was very nice to use compared to C, and extremely fast compared to Python – all up a good fit for the problem space of "low-level code that doesn't make you wake up in the night thinking about memory bugs".
Since I had to manage the plotter and ECG at the same time, I needed a way to manage concurrency. I could have used threads, which, at least in Rust, are moderately well-behaved. However, I'd heard a lot of interesting things about Tokio, a kind of Nodejs-style event driven programming framework. It tries to do a lot and, although the final code was pretty neat, I'm not sure the burden of the extra complexity was worth it.
The code itself needed to do three things: process the input from the ECG, turn that into smooth drawing commands for the plotter, and manage the plotter's command queue (too many commands would make it lag behind the ECG, too few and it would stutter while waiting). Of these, the input processing was the only easy one; I just did a rolling average of the ECG values which acted as a simple low-pass filter and got rid of basically all of the noise.
Managing the command queue wasn't theoretically hard, just very annoying in practice. The plotter itself was actually quite well-behaved; it would send an OK in response to a command that it had received, and if you filled up the queue it would wait until the queue had space before sending OK. I just filled up the command buffer on start, then sent a new command every time I got an OK. I say just, but this was really tricky to get right.
However, that was nothing compared to the difficulty of figuring out the right drawing commands to send. The plotter only really accepts commands like "move x distance over y time", and if you make the distance too high, or the time too low, the motors will skip or shudder. And it's not just velocity, you have to think about maximum acceleration, and maybe even jerk.
With this, I had entered the dark and scary world of control theory. Too much acceleration or velocity and I got jerky, inaccurate movement. Too little and the plotter couldn't adjust fast enough to keep up with the ECG, leaving it oscillating wildly back and forth.
Truthfully, the right answer to this would have been to sit down for a week or two with some serious reference material, learn enough about control theory to really get a sense of the fundamentals of the problem, figure out how to apply that to the real-time inputs I was getting, maybe finally get good at differential equations... Anyway, I didn't do that. Instead, I wrote something that felt like roughly the right idea and tuned it until it seemed to work well enough. Some day, control theory, I'll come back for you.
Ethically, it's worth mentioning that this ECG has very little medical validity. While it does definitely show a reliable signature generated from cardiac electrical activity, it's not a medical instrument, and unlikely to be useful for diagnosis unless you have a really obvious problem. The setup is just one lead (Lead I) compared to the 12 on a real ECG, and with the layers of smoothing and cowboy control theory, the waves end up squished at the extremes, making small fluctuations look larger.
One other point worth mentioning is safety. When you're putting electrodes on either side of someone's chest it's really important not to accidentally put high voltage through them. That means you need isolation, and almost all of the ways to do it for a serial device are expensive, inconvenient, or don't actually work. After a lot of research I can safely say that the only decent option for less than many hundred dollars is Adafruit's USB Isolator. Most USB isolators have different ratings for data and power, for example Adafruit's is 5kV/2.5kV but a lot of the cheap ones on eBay were 5kV/1kV. I don't understand this; surely someone getting zapped to death doesn't care which wires the electricity came through?
Anyway, the end result worked great and didn't kill anyone. I set the plotter up on a whiteboard, using plain office paper to do practice runs and then drawing the real thing on perforated ID badge inserts. The whiteboard being metallic meant I could use magnets to hold the cards in place while the plotter did its thing. With one other operator fitting the electrodes and me lining up the cards for the plotter, things proceeded quite quickly; about 1-2 minutes per person, but I think we could have hit 30 seconds if we needed to.
The social element went even better than I anticipated. I figured the individual differences in heart rate and morphology would make for an interesting and distinct signature for each person, but I didn't realise how striking the differences in amplitude would be. Some participants had big, sweeping waves that took up most of the badge. Others had little more than a wiggly line. These were normal variations (I believe mostly due to differences in body resistance), but they turned out to be the most noticable.
The people with very small waves took to calling themselves "flatliners" and commiserated together. One lady had an abnormally fast heart rate, which started a conversation about her heart condition and ongoing treatment. A few people came back later in the night to see if drinking had changed their graph much (it was about the same). People with particularly photogenic graphs got a lot of compliments, in a curious twist on the genetic lottery. Only one person declined; she'd had a scary ECG result before that turned out to be nothing, and didn't want to worry about what she'd see this time.
One of the most curious things about medicine is the way it turns people into data. Doctors aren't looking at you; they're looking through you to see what's wrong with your numbers. My goal with this project was to make that part of the conversation. What happens when you wear your heartbeat like a signature on your chest, putting your vital numbers on display for everyone to see?
It definitely made for some unique social experiences, but really drove home the tyranny of physical characteristics and the rapid onset of pseudoscience. In a nearby possible world, is it so hard to imagine the flatliners being stereotyped as wimpy and effete? Or looking for one weird trick to boost your cardiac amplitude? Or Ask Einthoven: I'm a regular dating a flatliner, can it work? The worst thing is, these aren't qualities you can develop, they're facts about you that you can't change.
Even if we restrict ourselves to the real universe and real science, we're not so far from a situation where DNA sequencing, facial recognition, social media, targeting databases and real name policies converge to eliminate the possibility of forging our own identities, leaving us with just one bio-authenticated persona, an indelible history tied to our very cells. The computer scientist part of me can see that this is quite clever, but the human part is horrified.
If you'd like to take a look at the code for this project, you can find it on GitHub, or check out my prototypes from July and August to see some drafts along the way.