Staying motivated

It does seem odd to make part 2 of this OSCar series about how not to give up. Especially as this is one of my actual jobs.

Here’s the thing: I spend a lot of time working with just myself and the ghost of Chris Huggett. This project will have taken me over a year by the time the synth is ready to demonstrate (hopefully at Superbooth in May). Even Paul Whittington, who is in charge of the OSCar brand, spends most of his time running PWG and dealing with the problems of supply chains, distributors, retailers, and customers. Being a company director is, after all, a picaresque adventure which is largely out of your control but always your responsibility. Anyway, long story short, his focus is not always on making the next product.

Meanwhile, I go for weeks without having anything playable, or even explicable, to show for my efforts. This stage of the project, with a desk full of hardware with a few desultory blinking lights and some quickly-moving voltages, is largely about getting the psychological barriers out of the way.

This post is not:

1. The usual ‘go out and walk occasionally’ post: I went and took a walk a fortnight ago.
2. A ‘beast mode’ post about how to distil measurable productivity from every mean minute of your life on this planet. Honestly, those people think they’re winning, but in any healthy society they would envy the homeless.
3. A post exploring technical best practice. That theme, I hope, will be mostly implicit in everything I write.

If this about anything, it’s accepting the fact that most of the things that make our planet a nice place to live were embroidered on a fabric of pissing about in company time. (You’ll find this idea expressed in myriad ways by everybody whose books you like to read, whose music you like to listen to, and whose company you enjoy.) So this, and writing about it, is basically how I keep myself in a frame of mind to finish a long, solo project that began with the intention of bringing people some joy. If you’re serious about that, it can feel like a zero-sum game.

Designing and building the hardware part was fun in its own right: I’m lucky to appreciate this stage of proceedings as a miniature challenge, on a par with a cryptic crossword. There are many right ways to translate a design to a new platform, and this choice is quite satisfying.

The doldrums for me began when I had a large amount of 1980s-era firmware to port before my synthesiser would do anything at all. I can’t just replace it with bits of the Mantis that I’d already written myself: authenticity to the original OSCar is the principal point of the exercise. First, appraise it critically and completely. Then, translate it into C for a new platform.

Firmware is where all the complexity is hidden, and people care about whether it’s done just right. The problem is that it wasn’t, really: it was written by an electronic engineer in 1983. A masterpiece in terseness it may be: scarcely a byte is wasted and the EPROM has only six left. But bugs jump out from inspection as well as in use: some weren’t noticed; others might have been, but what can you fix with six bytes free? And the user interface is of its time, which means it’s appalling.

But owning the firmware is tough. It’s high-difficulty, high-stakes, and needs to be approached with the kind of reverence that requires leaving the desk occasionally to drink tea while subjugating one’s ego. What follows is a few personal rules I made to make it more bearable.

Rule one. De-scope features that aren’t important until the end

The sequencer and arpeggiator are big parts of OSCar, but the synth is playable and demonstrable without them. 90% of the fun is in the way the thing plays, sounds, and responds as a simple instrument. We could take the prototype to Superbooth, let people play it, and those features would be missed, but not desperately. So I’ve decided to afford them no thought until I have to.

Meanwhile, the cassette interface probably won’t make the final unit because there’s no point in having it there. More on that later, and probably in a later post.

Rule two. Playability always wins

This is really an extension of rule one. Once I’d brought up the basic hardware, and proved to myself (for example) that the power supplies, timers, USB, and MIDI all work, the question was how to port Chris’s firmware. There’s thousands of lines of it, and it all has to end up inside somehow.

What, then, to do next? If I’m optimising for my own motivation, the right answer is whatever gets us closest to having an enjoyable musical instrument. So I started with the wave tables and oscillators, just so I can bodge a connector onto a test pin and hear the synth making a noise. Then I got the pitch conversions working so those waveforms can be made to respond to musical pitch. Next, I’ll get the key scanner logic going so I can play the keyboard. That will provide a very bare experience with no presets, no filters or envelopes, no pitch bend, and no real voice management. It’ll sound like a Stylophone. But it also gets me to a stage where I can play to people, get some pleasure out of my work, and hear all subsequent progress.

There are a few awkward corners of hardware that still aren’t completely tested or don’t work properly. But, as no deadline looms, even locking the PCB design is a secondary priority to having something that plays. At worst, I’ll find something off with the filters, and have to spend a day or two fiddling with resistor values and green wire. But a confrontation with my failure at the hands of the physical world is less humiliating if I can suck it up while playing a line of Bach. Also, having something playable makes debugging somewhat easier.

Rule three. Make progress visible

OSCar lends itself well to a progress-o-gram. I last messed with these when I was writing my PhD thesis at the end of 2004:

It gave me a visual evidence of the thesis word count growing. I posted it on this blog so people would hold me to account. (It was eventually submitted on 30th March 2005 at 45,508 words, 65 figures, and 108 references. Not a long thesis, but it got me there.)

With OSCar, there are 8 kilobytes of Z80 code to inspect, take ownership of, and port onto the modern platform. (8 KiB doesn’t sound a lot, but written in assembler on an 8-bit CISC processor, believe me it is.) Porting the firmware is a process of two distinct stages. The first job is assimilation. I start with a combination of my own source code (starting with an automatic disassembly the ROM and, with the help of the hardware schematics, working out what every line did over several hundred hours), and Chris’s source code, which we recovered several months later. The exercise is to determine exactly what’s going on inside the synth.

You’d think it’d be easier to junk my own disassembly and just continue with Chris’s source code, but in practice I spend little time with his work. The reasons can be explained in a later post.

A couple of things make progress-o-grams easier than they used to be. First, we have Python for this kind of scripting nonsense. Back in the early 2000s, I had to write my own GIF compressor in Object Pascal. We also have Claude so, rather than scrape the resources together to generate my own chart, I can just write a spec and see what it comes out with.

Here, then, is where we stood a couple of days ago:

The module names are from Chris’s source code: my version, of course, came out as one big lump. The striped areas are the ones I’m leaving until last because of rule one. The reason why I went through the whole cassette interface is because we have one old cassette, full of drop-outs, that contains original presets followed by a couple of demo songs by an unknown band, and then an album by The Police. At the time, we thought this was our last stand.

When users bought the MIDI retrofit, they were provided with a pre-recorded cassette that allowed them to load the original factory presets onto a new battery-protected RAM chip, because there was no longer any room for them in ROM. In a world where the compact cassette was the only reusable storage medium for music, it’s unlikely that anyone besides the Oxford Synthesiser Company bothered to preserve this data for posterity.

I decoded the old cassette routines, just so I could recover what I could from the cassette. It is, to say the least, a nonstandard modulation scheme. Again, that’ll be another post.

Fortunately, on a floppy disk backup of Chris’s dated 1983, I found the source file for the original ROM-based presets that we’d thought to be lost to history. Problem solved.

But the graph is important, because what often looks like endless, contextless, meaningless toil suddenly turns into painting a wall. As I scroll between different date-stamped versions, the wall turns red to orange to yellow to green, and I gain some small hit of dopamine that cannot be found in the minutiae of the envelope gating and triggering routines.