Running two experiments concurrently has its advantages and disadvantages. The good thing is that when you get stuck on one thing, you can flip to the other and vice versa. These hitches can be technical and creative, but there’s also the despondency factor that comes into play — those moments when you ask yourself “why am I doing this? what on earth was I thinking?”. For those moments, it’s nice to have something else to turn to.(Of course, there’s always the possibility that there will come a time when you lose faith in both projects simultaneously. So far that hasn’t happened, but that’s not to say it won’t.)
It’s probably also a good idea to have the projects be in broadly different areas, so that when you get tired of exercising one creative muscle, you can switch to another
Anyway, on the projects. I’ve decided to use code-names for the moment, not because anything’s bound by an NDA, but because it’s more fun.
Project Braun has been a rollercoaster, even in its short existence. It spawned from a story I wrote a few years ago called The Reader, which was one of those quite good but not quite there things that I never managed to get into a decent shape. It was science fiction, which is a genre I don’t much care for, but keep coming back to , perhaps because it feel like a legitimate framework for speculation and half-baked concepts. Anyway, the story wasn’t great but at its core was a technological concept I really liked. It’s not something that I can make happen, but there is a version of it I can make. This involves learning some electronics, getting to grips with microcontrollers and a few other things on the periphery of my skillset.
It’s going… OK. I think one of the problems with it (aside from my ignorance) is that I made the mistake of giving myself two options to work with: the Arduino starter kit I’ve had on the shelf for about a year now and a Raspberry Pi Pico, which is smaller, cheaper and more powerful, but has less documentation and examples out in the wild. The Arduino has its own programming language which is quite similar to Processing, something I’ve used on and off for a while now (again, not with great success, but I’m familiar enough with the core concepts and syntax to bodge together basic programs). The Pico uses a variation of Python, which I’ve also used before, although nowhere near as much and not for years. I’m not good at programming so I rely on the familiarity to get me through.
This project relies on audio and the Arduino isn’t powerful enough even to play back a .wav file without an additional board to power it. The global components shortage means these are difficult to source and the one I was able to find comes in the form of an unassembled kit. My soldering skills are also poor and even reading the instructions for the kit made my head spin.
Theoretically the Pico has the horsepower to playback audio on its own, but I’m finding everything about it difficult to understand. The diagram explaining what the different pins are forbidding to the newcomer and there’s various complications that I can’t get my head around. I know that the Pico has the power and flexibility to do whatever I want, but my lack of Python coding and a few other things (why are the pin numbers on the underside of the board, where I can’t see them?) means the Pico just isn’t for me. For the moment, anyway. You can use the Arduino IDE with the Pico, and I suspect this is going to be the way I go. I just need a sense of the pin references and a few other things and I think that might be good to go.
For the moment, though, what’s been most fruitful has been using Arduino and Processing in tandem, with Arduino handling the sensors and sending messages via the serial port and Processing interpreting the sensor data and doing the things I want done. Ideally, I would have all the computation happening in one hardware box, but that’s a ways off now. For the moment it’s a board and some sensors and a pair of headphones, all connected to the Mac.
I’ll have to settle for this Arduino / computer combo for the moment. I might be demonstrating this in a couple of weeks, so I’m telling myself that the perfect is the enemy of the good.
Project Gielgud was my backup, a project that I turned to when I was getting very depressed about my ability to make progress on Braun. It’s an idea that I had a few years ago and has been in the ‘I should do something with that’ file for some time. It shares some low-level DNA with Braun in that its a story-telling mechanism, but you could probably say that about most of what I do. Unlike Braun, though, the technology involved is limited to bits of card that slot together. That’s very much in my existing skillset, although it’s not been implemented in quite this way before.
I had a crit with Work Show Grow on Sunday, so rushed to get a presentation together for it. One thing that came from that was using Blender as a way of putting together a virtual physical version of the structure. It was very rough, but Blender’s SVG import function makes it easy to move 2D shapes around in 3D space. After 15 odd years of using the open-source 3D software, it felt good to actually use it for something practical.
I don’t know about Gielgud. I think it might be all right, but I feel enthusiasm waning a bit. But even if it’s just something to bounce off, I think it’s worthwhile. That tick-tock schedule seems to be working pretty well for me. I do my best work when I’m meant to be doing something else.
I’ll try and post updates as I go, but that’s something I’m pretty bad at. Feels a bit like homework and I spend all day working at home anyway.