EuroRack 6HP Arduino Mozzi Module – Basic VCO

By Kevin on January 5, 2025

This is the first project based on my EuroRack 6HP Arduino Mozzi Module. It is loosely based on HAGIWO's Arduino Mozzi VCO Module.

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are some previous posts for the main concepts used in this project:

If you are new to Arduino, see the Getting Started pages.

Parts list

Build EuroRack 6HP Arduino Mozzi Module
Amplification
CV sources

The Circuit

This uses the EuroRack 6HP Arduino Mozzi Module with the pots and jacks assigned as shown below.

The four potentiometers control the following:

POT 1 - OSC 1 core frequency offset (from V/Oct CV).
POT 2 - OSC 2 frequency ratio OSC1.
POT 3 - Waveform for both oscillators: sine, triangle, saw, square.
POT 4 - Octave: 1 lower, normal, 1 higher, 2 higher.

There are three CV inputs:

V/Octave pitch.
OSC1 vs OSC2 gain.
Pitch modulation.

The Code

The code is inspired by that of HAGIWO's Mozzi VCO, in that I'm using Mozzi with two oscillators, with multiple waveforms, and I'm using HAGIWO's gain profile for CV. But I've added a few extras and have rewritten the core Mozzi code to hopefully be a little more optimal.

The main V/Oct calculation has to happen every scan and HAGIWO uses a look-up table in PROGMEM for the fractional voltages that correspond to each value of the ADC and then uses those in the standard Volts to frequency equation:

Freq = BaseFreq . 2^CV

For a 10-bit resolution (the resolution of the Arduino ADCs) this requires 1024 values across the whole 5V range. That equates to 4.8828mV per step (5/1024) and as full octave of 12 steps is 1V that equates to 83.3mV per semitone.

The various CV recommendations I've seen suggest using a BaseFreq equal to C4, which is 261.6256 Hz in the calculation unless it is for a LFO or clock in which case a BaseFreq of 2Hz is recommended - which corresponds to 120 bpm if used for a clock. The BaseFreq is the frequency used for 0V. Many analog synths will accept negative voltages to go lower, but as this is an Arduino it only supports 0V to 5V.

HAGIWO uses a table of float values and uses floating point arithmetic to work out the frequency. I've opted to use fixed point arithmetic and also rather than store the CV "step" values in the table have pre-calculated the whole 2^CV for each step.

Here is some Arduino code that will output the required look-up table values. My full version will first output the individual voltage steps to 6 decimal places; then for the float version of 2^CV; and finally for the fixed point 16.16 equivalent - that is 16 bits for the integer part and a fixed 16 bits for the binary equivalent of the decimal part.

The code below just does the last part. This is using the FixMath library which was written for use with Mozzi (more here).

#include <FixMath.h>  // Designed for use with Mozzi

int res = 10;        // 10-bit resolution
float maxv = 5.0;    // Max voltage

void setup() {
  Serial.begin(9600);

  int max = (1<<res) - 1;
  float cvstep = maxv / ((float)max+1.0);

  Serial.print("\n\n");
  Serial.print("Resolution=");
  Serial.print(res);
  Serial.print(" bits (0 to ");
  Serial.print(max);
  Serial.print(")\tV/step=");
  Serial.print(cvstep,6);
  Serial.print("\n");

  float cv = 0.0;
  for (int i=0; i<=max; i++) {
    if (i%16 == 0) {
      Serial.print("\n");
    }
    float freqpow = pow(2, cv);
    UFix<16, 16> q16n16fp = freqpow;
    Serial.print("0x");
    Serial.print(q16n16fp.asRaw(), HEX);
    Serial.print(",");
    cv += cvstep;
  }
}

void loop() {}

I've used this to create the q16n16 version of the 1024 values required to calculate the frequency for each of the 0..1023 values that the 1V/Oct analog input could provide, covering the full 5V range. This is stored in the header file v2voct.h that is part of the code.

This does mean that any calculation of frequency must be done using the FixMath 16.16 values, for example:

UFix<16,16> q16n16potfreq = mozziAnalogRead(POT1);

This code takes the unsigned integer value (0 to 1023) from mozziAnalogRead and automatically turns it into a 16.16 fixed point format value in variable q16n16potfreq - note that in each case the decimal part will be zero as the starting point is an integer between 0 and 1023.

When reading values in from the look-up table, they have to be pulled in "raw" as they are already in the 16.16 format. But as Arduino doesn't know anything about this format, they have been declared as uint32_t values in the PROGMEM structure, but then need to be read back out and treated as 16.16 values as show below.

#define CVSTEPS 1024
static const uint32_t q16n16fp [CVSTEPS] PROGMEM = {
0x10000,0x100DE,0x101BD,0x1029C,
...
};

UFix<16,16> fpow = UFix<16,16>::fromRaw(pgm_read_dword(&q16n16fp[voct]));

All calculations related to frequencies are performed using 16.16 values. The Mozzi oscillator setFreq function has a version that takes 16.16 values too, making everything actually quite straight forward once you get your head around what its doing.

Other notes on the code:

There are two gain values maintained - one for each oscillator. The values used come from another look-up table (that I took from HAGIWO's original) that allows the CV to pan across from one oscillator to the other. I'm using 7-bit gain values (0..127) so that when the final audio sample is worked out at the end, it should all fit within a 16-bit value give or take.
The octave selector changes the octave of both oscillators and is determined by POT 4 and can select from 0V = C3 through to 0V = C6.
Oscillator 2 is set to a frequency between 2 octaves below and 1 or 2 octaves above the frequency of oscillator 1 at all times, as determined by POT 2 - quite how to do this was the subject of a bit of experimentation (see below).
The frequency of oscillator 1 is given by the setting of POT 1, the V/Oct CV, the mod CV and the octave.

The following code sets up the two frequencies for the oscillators.

UFix<16,16> fpow = UFix<16,16>::fromRaw(pgm_read_dword(&q16n16fp[voct]));

UFix<16,16> q16n16freq1 = q16n16oct * (q16n16c4 + q16n16potfreq + q16n16mod) * fpow;

UFix<16,16> q16n16freq2 = q16n16Mult * q16n16freq1;

aOsc1.setFreq(q16n16freq1);
aOsc2.setFreq(q16n16freq2);

q16n16c4 is the frequency of C4 in fixed point 16.16 format. It is essentially the "BaseFreq" in the original equation. Notice how the base frequency is also affected by POT 1 and the modulation CV. The whole lot is then multiplied by the octave setting, which will be one of 0.5, 1.0, 2.0 or 4.0.

The multiplier used for the second oscillator (q16n16Mult) comes from POT 2. I have included two approaches to using this: discrete values or continuous.

For discrete values, the setting of POT 2 selects one of 8 fixed ratios to use to set the frequency of OSC 2 compared to OSC 1. I've chosen the following options (with 0.0 effectively being "off"):

{0.0, 0.25, 0.333333, 0.5, 0.666666, 1.0, 1.333333, 2.0}

For continuous values, I take the raw reading (0..1023) and convert it into a 2.8 fixed point number by shifting left by 8 bits and then treating it as a raw 16.16 value. This works as the number is a 10-bit value, so shifting left 8 bits makes it a 18 bit value - but then when read as a 16.16 bit value, the lowest 16 bits of those 18 are treated as the decimal...

UFix<16,16> q16n16Mult = UFix<16,16>::fromRaw(((uint32_t)mozziAnalogRead(POT2)) << 8);

Note I have to ensure it scales the return value from mozziAnalogRead up to 32-bits first otherwise clipping will occur. This allows me to have fractional octave values for the second oscillator compared to the first.

As the second oscillator starts 2 octaves below the first, this gives a range of multipliers starting from nothing (i.e. "times zero"), to almost two octaves below oscillator 1 (00.01000000 in 2.8 fixed point binary) through to 1 octave below (x0.5 = 00.10000000), to the same as oscillator 1 (x1 = 01.00000000) to 1 octave above (x2 = 0x10.00000000) to almost 2 octaves above (x4 would be 1024, but 1023 is 11.11111111).

The downside of this approach is that the response to the potentiometer setting isn't linear. Or rather, it is linear, when really I'd like it not to be... I might go back and correct that in software at some point, but it is fine for now.

Note that if POT 2 is set to zero, then oscillator 2 is turned off. One option to always keep it on is to always ensure a minimum POT 2 reading. I've included that as an option to have the minimum reading of 64, which when converted to 2.8 format is 00.01000000 or 0.25 in decimal - hence a multiplier that gives "two octaves below".

The final calculation that is performed for each audio sample is given by:

AudioOutput updateAudio(){
  return MonoOutput::from16Bit(bOsc1Gain*aOsc1.next()+bOsc2Gain*aOsc2.next());
}

This combines the audio samples of each of the oscillators, multiplies them by the 7-bit gain value and then tells Mozzi to take this as a 16-bit value to be turned into a Mono output value.

Right at the start, I've told Mozzi to use "HiFi" mode, which should give me 10 bits of PWM output range using D9 and D10. I've also used a slightly higher MOZZI_CONTROL_RATE to help with scanning the IO.

Find it on GitHub here.

Closing Thoughts

As can be seen from the video, I don't really anything much to use this with yet, but I've driven it from my "Baby8" CV Step Sequencer and the LFO from my Educational DIY Synth Thing and I think it seems to work ok. The video includes the following:

Changing basic OSC 1 frequency via POT 1.
Changing OSC 2 ratio compared to OSC 1 via POT 2.
Chaning the octave via POT 4.
Chaning the waveforms via POT 3.
Generating a V/Oct CV from the Baby 8.
Setting a low sweep of CV1 to control the relative gain of OSC 1 vs OSC 2.
Swapping to CV2 to provide additional pitch modulation to the oscillators.

This isn't quite using the final version of the code, but gives an idea.

Note that the V/Oct input won't work at true audio frequencies, so it can't be used for frequency modulation, but otherwise I'm quite pleased with the performance considering it is updating from three CVs and four potentiometers each scan.

It might be possible to up the MOZZI_CONTROL_RATE even more and scan the CVs more frequently than the pots, but for now they are all scanned at the same time using a MOZZI_CONTROL_RATE of 128 (twice the default 64).

The output seems pretty clean to me too, but that is really thanks to HAGIWO's original PWM output stage.

I'm just waiting for some spray-on adhesive so I can make a simple panel for it now.

Kevin