Happy holidays and happy almost 2026!

It's been a while since my last update, but things are progressing. The firmware is now essentially feature complete - not complete complete, there are still bugs to be fixed and rough edges to sand down - but all of the major pieces are there. I've been adding a lot the past few months and think I've got a pretty solid feature set for launch, with plenty of room for improvement and further feature development via firmware updates. Some recent additions:

• MIDI clock sync for the LFO. This one was quite a lot of work, and isn't perfect yet - I actually plan to do a post just on this topic, as it's pretty interesting. What I've got working will be sufficient for release, but there's a lot more to be done in the future to really nail it down. I take back all of the bad words I've said about other gear I have that has MIDI clock sync issues.
• Every onboard oscillator is now available for use as an LFO, including the 8-step wavetable! This, combined with MIDI clock sync and either pitch modulation or filter modulation, opens up some new sound possibilities, essentially becoming a simple 8 step sequencer with a nice tactile interface. The LFO selector also has cute icons.
• One shot LFO mode. The "LFO reset" button is now an "LFO mode" button that switches between several options:
  • Continuous - all voice LFOs are synced and are free running
  • Reset - Each voice's LFO phase resets on note start
  • One shot full - Each voice's LFO starts on note start and runs for a single cycle and remains at the end of the cycle
  • One shot half - The same as "one shot full" but only half the waveform. Handy if you want to use the sawtooth waveform with LFO modulation as a second envelope but don't want the negative component of the wave (especially useful for pitch modulation).
• There's a new "oscillator drift" button, with "low" and "high" settings. This will add a random offset to the target frequency of every new note.
• The oscillator envelope modulation knob is gone, and I added a new "LFO waveform" knob. I just wasn't using the oscillator env modulation much, and with the one shot LFO mode you can get something approximating env modulation pretty easily.
• Instead of having a button to toggle polarity of the filter envelope modulation, the filter modulation knob is now bipolar, putting both positive and negative modulation amounts on the same control. There's enough room on the knob that it still feels responsive, and having that control on a button never felt right.
• Filter keyboard tracking.
• Output stage hard clipper has been replaced with a proper limiter. I went back and forth on this for a while, and am pretty happy with the sound of the limiter now. Playing all 6 voices and pushing the "amp" knob beyond about 60% will push the limiter, but if you're only playing 1 voice it's nice to be able to get more gain out. It's pretty transparent, I decided not to try to introduce any intentional additional distortion or saturation.
• Parameter display values are all 0-255 (or -127 to 127 for bipolar controls). Behind the scenes there's a little more precision, 9-ish bits, but it's not necessary to display the full precision I think (it would be a little confusing, as I need to fudge the values a bit to handle settling, debouncing, etc). Plus, there's interpolation for the important knobs, so changing the filter cutoff from 254 to 255 has no audible "stepping" as the values are changes gradually over a few milliseconds.

The remaining work is all in the physical domain:

• New production candidate PCB, addressing some audio issues on power loss and moving things around to fit into an enclosure.
• Design the production panel, and determine whether the manufacturing process I'd like to use is feasible (JLCPCB black aluminum panel).
• Iterate on the wood enclosure idea, experiment with different wood options and finishes. I know so little about woodworking, I have a lot to learn here.

There will be a lot more to do that I haven't discovered yet. But completing - by one definition - the firmware feels like a big step. On track for a 2026 release!

One of the nice things about building a digital synthesizer is that everything is just code. My code is responsible for generating a series of integers that my DAC turns into audio, but I can do a lot of other things along the way as long as I can deliver those integers to the DAC in time (or a buffer underrun will occur, something that used to be a common occurrence making computer music).

For example, I wanted to generate a realtime oscilloscope view of the waveform being generated. The final result looks pretty good:

Building a single cycle oscilloscope on its own would be a challenge - a general purpose scope has to be able to determine the frequency of an incoming signal in realtime, and if it contains many frequencies, which does it pick? If you've ever had to fiddle with the tracking on a bench scope you'll know what I mean. In my case however, I'm the one generating all of those samples. I know exactly when a cycle starts and ends, and even though it's a polyphonic synthesizer (e.g. can play 6 notes at once), I can decide which single frequency waveform to display. It's just data - numbers I'm already doing the work of generating to make sound, so it's just a matter of picking the right numbers and getting them to the right place for displaying a screen (along with some scaling).

The code for doing this is only a handful of lines. It's a little sloppy - the FPU on the ESP32S3 is surprisingly capable, so I'm doing more floating point operations than I should, but here's the idea. In Voice.h, some setup:

  float prevPhase = 0.0f;
  std::array<float, 128> pendingBuffer = {0};
  std::array<float, 128> outputBuffer = {0};
  uint8_t lastPendingBufferIndex = 0;
  

And in Voice::Process(), which generates a sample for a single voice:

float newPhase = this->wavetableOscs[0].GetPhase();

// if osc1 has reset, reset the output buffer
if (newPhase < prevPhase) {
  outputBuffer = pendingBuffer;
  pendingBuffer = {0};
}

uint8_t index = static_cast<uint8_t>(newPhase * 128);

// interpolate in the case that a buffer has fewer than 128 samples
if (index - lastPendingBufferIndex > 1) {
  for (uint8_t i = lastPendingBufferIndex; i < index; i++) {
    pendingBuffer[i] = pendingBuffer[lastPendingBufferIndex];
  }
}

pendingBuffer[index] = processed;
lastPendingBufferIndex = index;

prevPhase = newPhase;

It's pretty straightforward - we initialize two buffers of size 128 (the OLED is 128 pixels wide) and a few variables for keeping track of where we are. Every time we generate a sample, we check the phase of the primary oscillator (I've chosen to sync the oscilloscope to the primary oscillator, but it could be the secondary). If it has wrapped around, we know the pending buffer is complete - assign the output buffer and carry on. The rest of the code is just mapping the floating point phase value to the correct index in the pending buffer. This includes accounting for the case that there are fewer phase indices than the width of the display - as we go through the array, hang onto the previous sample, drop it in until we get to a new one. A possible improvement would be linear interpolation here, but a) I think it looks cool with the quantized waveform and b) I'd have to rework this a bit to have dynamic length arrays - or deal with extra floating point math in the sample generation loop - and I don't really want to do either!

In the main audio loop, where we gather up and sum the samples from the voices and send samples to the DAC, we grab a pointer to the latest completed buffer from the last used voice and assign it to a variable in the displayState struct. This means that the scope will always be displaying the last played note, which feels correct to me (displaying a true summed output of all voices would be complicated and look less interesting).

// update the display's scope view buffer to show the latest voice
state.displayState.outputBuffer = state.voices[state.lastVoiceIndex].GetOutputBuffer();
state.displayState.outputMultiplier = state.activePreset->amp;

And finally in the display code - iterate through each horizontal pixel, clamp (in the case of a clipping sample, the filter is quite resonant) & normalize the vertical pixel, then either draw it to the framebuffer directly or connect it to the previous vertical pixel with a line.

ssd1306_clear_screen(display, 0);

uint8_t prevY;
auto outputBuffer = *state.outputBuffer;

for (int i = 0; i < 128; i++) {
  // fclamp to hard clip signal
  float normalized = fclamp(((-outputBuffer[i] * state.outputMultiplier) + 1.0f) / 2.0f, 0.0f, 1.0f) * 64.f;
  uint8_t y = static_cast<uint8_t>(normalized);
  if (i == 0) {
    ssd1306_fill_point(display, i, y, 1);
  } else {
    if (abs(prevY - y) > 1) {
      ssd1306_draw_line(display, i - 1, prevY, i, y);
    } else {
      ssd1306_fill_point(display, i, y, 1);
    }
  }
  prevY = y;
}

ssd1306_refresh_gram(display);

The display libary can push the framebuffer out at about 45 hz over I2C, so this looks really cool.

Here's a more interesting demo, running MIDI to the device for the bassline from my 2012 track "With You ft. Kotomi":

When I first started implementing the SSD1306 OLED on my prototype, I grabbed the quickest and easiest to implement driver I could find - a driver Espressif shipped as part of ESP-BSP that has since been removed. It worked great, updated the screen at about 40 hz, and was very light on resources. However, it only supports a single font, and isn't set up easily to support adding others without doing a fair amount of work to get each glyph into a specific format of C array. I wanted to add a different font, so I started looking around at other options.

That driver is no longer supported, and Espressif has replaced it with a lower level driver that doesn't actually support any fonts, just direct bitmap drawing. The recommendation is now to use LVGL, a fully featured graphics stack that has widgets, buttons, all sorts of things. So I went about implementing LVGL, which - sure enough - has good support for adding your own fonts, but can't hit more than about 18 - 20 hz on the ESP32 (running at full speed I2C, 400khz). It's also set up with its own timer and draw loop, and after fiddling around for quite a while I wasn't able to get the display to update faster. In addition, the draw loop persistently uses about 5% of a core on the ESP32 regardless of how much work there is to do - it just didn't feel like the right thing for me. Additionally, and I didn't look too much into this, when I use LVGL an audible whine comes out of my SSD1306 display. Maybe that's something I could debug, but I had already planned to move on at this point.

U8G2 is a popular library that supports dozens of small displays, including the SSD1306. I had used it before, so figured I'd give it a shot again. It's going a ton of fonts built in and has a system for importing additional fonts into its internal format. It doesn't natively support ESP-IDF, but there's a wrapper that works pretty well. However, after getting this implemented, again I hit the issue of slow update speed - the fastest I could get is around 18 hz (at 400khz I2C). After doing some research, others had noticed the same thing, but consensus seemed to be that that was good enough. Not good enough for me!

I found another promising SSD1306 driver that, when running a simple text test in isolation, could hit 30+ hz. It also had an example supporting BDF (a popular font format for vintage fonts) fonts, so seemed pretty promising. However, that example was quite slow for a reason I was able to fix but left me a little confused. Additionally, the kerning wasn't quite right with the BDF example, and I wasn't keen on trying to fix that. And finally, when I included the driver in my full synthesizer project, it was using more resources than I expected, and wasn't drawing fast enough.

At this point I was close to despair. I know AdafruitGFX is a popular graphics library, but it doesn't support ESP-IDF (only Arduino) natively. To implement it in my project I'd have to bring in an Arduino compatibility layer, and even then, I don't know anything about the performance or resource usage, so it felt like a risk that might not pay off.

I decided to back to the one driver I knew worked really well - the ESP-BSP driver that has been deprecated. I had since upgraded my ESP-IDF version to 5.4.x, and could actually no longer use the driver as written, as it only supports what is now called the "legacy" I2C driver. So I forked the code into my own repo and replaced updated all of the I2c API calls (something I had already done with my ES8388 driver), which worked. And it was still fast! Faster than any other driver I had used. Why is it faster? My hunch is because of how it pushes framebuffer data to the I2C bus in a single transaction, whereas U8G2 pushes bytes to the display in chunks, I'm guessing because of its support for many different variants of displays (I'm not sure about LVGL or the others, but might be similar).

static esp_err_t ssd1306_write_data(ssd1306_handle_t dev, const uint8_t *const data, const uint16_t data_len)
{
    ssd1306_dev_t *device = (ssd1306_dev_t *) dev;
    esp_err_t ret;

    i2c_cmd_handle_t cmd = i2c_cmd_link_create();
    ret = i2c_master_start(cmd);
    assert(ESP_OK == ret);
    ret = i2c_master_write_byte(cmd, device->dev_addr | I2C_MASTER_WRITE, true);
    assert(ESP_OK == ret);
    ret = i2c_master_write_byte(cmd, SSD1306_WRITE_DAT, true);
    assert(ESP_OK == ret);
    ret = i2c_master_write(cmd, data, data_len, true);
    assert(ESP_OK == ret);
    ret = i2c_master_stop(cmd);
    assert(ESP_OK == ret);
    ret = i2c_master_cmd_begin(device->bus, cmd, 1000 / portTICK_PERIOD_MS);
    i2c_cmd_link_delete(cmd);

    return ret;
}

...

static esp_err_t ssd1306_write_data(ssd1306_handle_t dev, const uint8_t *const data, const uint16_t data_len) {
  ssd1306_dev_t *device = (ssd1306_dev_t *)dev;
  esp_err_t ret;

  uint8_t *out_buf = (uint8_t *)calloc(data_len + 1, sizeof(uint8_t));
  out_buf[0] = SSD1306_WRITE_DAT;
  memcpy(out_buf + 1, data, data_len);
  ret = i2c_master_transmit(device->i2c_dev_handle, out_buf, data_len + 1, 1000);
  free(out_buf);

  return ret;
}

But I was basically back to square one. I have a display driver that works great and is fast, but it only supports one font.

At this point I started thinking more about handling the font drawing myself - can I add a library to render a font to a bitmap, and then draw the bitmap directly using my driver? After some research I came across nvbdflib, which actually parses BDF fonts directly and allows you to provide your own drawing function! This seemed pretty promising - maybe I can include this library, give it a BDF font and a function that draws directly to my framebuffer, skipping the intermediate bitmap altogether.

void bdf_drawing_function(int x, int y, int c, void *ctx) {
  ssd1306_dev_t *device = (ssd1306_dev_t *)ctx;
  ssd1306_fill_point(device, x, y, c);
}

...

bdfSetDrawingFunction(bdf_drawing_function, (void *)device);

It took a little fiddling - I don't have a filesystem on my device yet, so to load a BDF file into a buffer I used this (alternatively could compile in as an object file, but wasn't sure how to do that with ESP-IDF). It worked! It does load the entire font into memory, but the BDF format is just plain text, so I edited and trimmed it down to the 94 characters I needed. The trimmed down font I loaded in, the 8x16 IBM VGA font from 1987, was about 10 kb. I'm not memory constrained in my project - CPU is my primary constraint - so this was a perfectly fine compromise for being able to drop in another font very easily without a compilation step into an intermediate format (an improvement to memory usage would be to add that compilation step, but it's not important for my use case). After some tweaks to nvbdflib to pass along the consumer's context into the provided drawing function, I had the library working nicely inside of the display driver.

STARTFONT 2.1
FONT -IBM-VGA-Normal-R-Normal--16-120-96-96-C-80-ISO10646-1
SIZE 12 96 96
FONTBOUNDINGBOX 8 16 0 -4
STARTPROPERTIES 34
FOUNDRY "IBM"
FAMILY_NAME "VGA 8x16"
WEIGHT_NAME "Normal"
SLANT "R"
SETWIDTH_NAME "Normal"
ADD_STYLE_NAME ""
PIXEL_SIZE 16
POINT_SIZE 120
RESOLUTION_X 96
RESOLUTION_Y 96

So that's where I am now - I have a SSD1306 display driver capable of hitting full speed (40 hz), but also supporting any font in BDF format! I'm going to keep refining the driver and added things I need - calculate bounding box for a string, for example - but I feel good about where it is already. No big dependencies, no compatibility layers, and using modern I2C APIs. Neat!

For a little over a year now, I've been building a digital synthesizer. I'm a musician & artist so I've spent a lot of time with synthesizers but never tried building one of my own. I find the history of synthesis fascinating and spent a lot of time reading about the origins of digital synthesis (I highly recommend Musical Applications of Microprocessors).

Wavetable synthesis is very simple - generate samples by continually stepping through a waveform at a speed relative to the frequency of the note being played. Modern wavetable synthesizers allow you to draw enormous, complex waveforms built of thousands of samples, computed via a variety of methods, but I was curious what it would sound like to build something using a very small wavetable. Typically you'd interpolate between the values in a wavetable to smooth over the discontinuities in the resulting waveform, but I was curious what it would sound like if you didn't do that. So, for fun, I started writing an implementation of this idea using a prototyping device I had sitting in a drawer.

The waveform that this creates is essentially an 8-segment step function, and there's a lot of harmonic content in each of those steps. After experimenting with a few values in code, I threw together a quick protoboard prototype using 8 slide potentiometers and mapped those sliders to values in my step function. It worked, and it was fun! It didn't really sound like what I thought it would, but I found it interesting nonetheless.

From there I started thinking about how to build this into a larger device. I'm a fan of polyphonic synthesizers, so I added multiple voices. I wanted a resonant filter, so I spent a lot of time experimenting with different virtual analog filter simulations (eventually landing on the Cytomic SVF, which sounds good and is computationally inexpensive). The Daisy platform is nice for prototyping, but I wanted to go lower level and understand both the software and hardware more. I've built a few small projects with the ESP32 platform before, so I ported my prototype to the ESP32 and started migrating everything from C to C++20 (I'm a web developer by trade, so C++ is a fun challenge). This resulted in a fair amount of my own reimplementation for things like MIDI input, but I enjoyed getting closer to the metal and losing unnecessary abstractions. I'll write another post about the software architecture, but it's all built on the ESP-IDF framework and makes a lot of use of FreeRTOS for scheduling, multitasking, etc.

It's now a year and a bit later than that and I'm still just iterating on the same idea - a very simple wavetable mapped to 8 sliders, no interpolation, only anti-aliasing (a story for another post). Digital synthesis - inspired by a time when memory was greatly limited - combined with modern emulations of analog technology to make an instrument that sounds good and is fun to play and tweak. Still have a long way to go until I've got a production ready device but it's already quite usable!