October 26, 2020
by GForce Software
It’s hard to put into words how devastated we are at the loss of Chris Huggett and we send our heartfelt condolences to his family, friends and work colleagues.
In short, Chris was a bonafide industry legend, the most prolific British synthesiser designer, and a dear friend of ours.
So many people will be rightfully paying tribute to him in the coming days and most of these will include his creations including the Wasp, OSCar, his contribution to the Akai S-series samplers, and his continued work with Novation, culminating in both Peak and Summit.
From our perspective, not only was Chris an icon, he was a kind and modest gentleman who became a friend. He gave us the last revision OSCar firmware for impOSCar many years ago. He graced us with his presence at our studio on one of the most fun and gloriously sunny days imaginable. And, whenever possible, he would join us and a couple of other old friends for lunch at the Victoria Arms, Oxford.
After contributing patches to Summit, we also shared a journey to Berlin with Chris for its launch, and where I got the chance to introduce him to Michelle Moog-Koussa and so he could see first-hand how his work and contribution to electronic music was respected by so many attendees.
”I’m quite enjoying this” the normally shy and super modest Chris chuckled as we walked away from yet another person congratulating him on Summit and telling him how much his work had meant to them over the years.
I’d actually been badgering Chris to let me film him for a Bright Sparks update and after a whisky fuelled evening on that Berlin trip, in the taxi journey to the airport, he said “Let’s do it. I just need to get over a small operation first.”
We didn’t press him on what the operation was for, but when we next met for lunch, he revealed a scar and explained it was cancer related. Further operations followed and while initially he remained upbeat and positive about a favourable outcome, it slowly became evident that the treatment wasn’t working.
We’re not ashamed to say that one sentence in our last email exchange made us cry. It simply read “As you see, it’s all slipping away now.”
We will remember Chris as a quiet, generous, kind, funny, delightfully cantankerous gentleman. A modest genius who enhanced our lives with his presence and brought the electronic music world so much joy via his many creations. Our hearts go out to his family, friends and work colleagues (in particular, Nick Bookman, Jerome Meunier, Jerome Noel, Danny Nugent & Chris Calcutt) and we will continue to raise a glass or two of the finest whisky in his honour.
If you want to understand why we’ve always regarded Chris as a genius, this tribute from impOSCar engineer, Jon Hodgson, reveals all.
If the world had gone all “Mad Max” during his lifetime, Chris Huggett would probably have faired quite well. He would have been the character everybody called “Doc” or “The Mechanic” that was respected for his ability to retask broken bits of technology to perform useful functions in the post apocalyptic world. In my in depth analysis of the workings of the OSCar synthesizer his knack for extracting the most out of components by using them in ways the designers probably didn’t conceive of became obvious.
The prime example was probably the oscillators. Now I’ll try not to get too techie about this, but it’s impossible to avoid it completely.
Back when the OSCar was developed we basically talked about two kinds of RAM, there was Static RAM (SRAM) and Dynamic RAM (DRAM). SRAM was fast, simple to implement, could keep its data with just a battery, and expensive. DRAM was cheap(er), slower, but every individual bit had to be regularly refreshed to keep its data. To help keep system costs down, the designers of the Zilog Z80 (the processor used in the OSCar) included a built in DRAM refresh counter and circuitry to handle the refresh, so no extra circuitry was needed.
Now the OSCar didn’t use any DRAM, it was all SRAM, so what Chris did was he retasked the DRAM refresh functionality to use in the oscillators. The refresh line was used to determine when the oscillators could access the memory (the oscillators in the OSCar were all 256 sample 8 bit waveforms) because the CPU wouldn’t be reading memory at that point, and the counter was used to toggle between the two oscillators.
Throw in a Z80 CTC (Counter Timer Chip) which was also used unconventionally (the data lines were connected to the address bus, not the data bus, so that it would step through the waveform) and the pitch circuitry involving an Intel CTC and an analogue frequency multiplier and the end result is a showcase of quirky brilliance that had me scratching my head for a while until I worked it out.
The rest of the OSCar is a lesson in extracting the most from your chips. In a time when every function on a chip was a significant part of your cost (and pcb space), you didn’t want to waste any. If you’ve ever wondered why the OSCar only has one switchable control for both volume and drive for example, the answer is simple, not only would it have needed another pot, and another knob, but also a significant amount of extra circuitry, because he’d already used up the full capacity of what was there. Any more functionality on the OSCar would have made a notable difference to the price, any less would have been wasting something that had been paid for.
What I am fairly convinced is another example of his inventiveness when trying to deal with the constraints of hardware was the “Random” preset waveform, which was introduced in version 6 of the firmware, replacing the previous “Triple Pulse”. Now you might assume the change was made because it was a better sound, but knowing how it was implemented makes me think there was another explanation. All the waveforms in the OSCar were generated algorithmically. There is a bit of code that “draws” the waveform into memory, from whence it is read (by the mad genius circuitry I described above). All except for “random”, that’s just a copy of a bit of the OSCar firmware (the actual code that the OSCar runs). I think what happened was that after improving the harmonic wave editing in version 6, Chris found there just wasn’t enough code space for all his original waveform algorithms, so he ditched the least used one and just found a bit of the code that made an interesting sounding waveform.
I included that waveform in the impOSCar (I renamed it “Gritty” because the fact that it is actually not random at all generated a number of comments from early beta testers). So the impOSCar actually contains 256 bytes of original OSCar program code (It’s just never used as code).
It’s a sad day for me hearing of Chris Hugget’s passing. Unfortunately, I never met him (and how I now regret not pushing to make that happen at least once, what an interesting conversation that could have been), but when I started impOSCar development he not only gave the project his blessing, but generously supplied his original firmware source code, which certainly saved me weeks, and quite probably months, of reverse engineering what he had done.