The Tooba Documentation

The Tooba is an electronic musical instrument built into a piece of PVC tubing (hence the name). It borrows principles from the Moog-style analog music synthesizers of past decades.


Way back when, one of my friends in high school was a guy named Dave Wilson whose father got him into 1970s-era Moog-style analog electronic music synthesizers. Dave created a museum of historical synthesizers in his home in Nashua, New Hampshire. Throughout our high school and college years, we exchanged ideas and circuits and bits of lore for various synthesizer hacks.

Music synthesizers of that era were actually special-purpose analog computers, performing arithmetic operations with integrators, summers, and other such circuits. These computations can be performed digitally by a microprocessor or special-purpose digital circuit (e.g. FPGA). So Dave and I both at various points and in various contexts wrote code to do that.

Sound generation in the Tooba (and keyboard scanning and voice assignment) is done in C++ running on a 32-bit ARM microcontroller.

Status, plans, etc

The first PVC prototype, the one shown at Providence on Aug 8th 2015, did all sound generation in the interrupt handler. More recently, the interrupt handler only transfers audio samples from a queue to the microcontroller's on-chip 12-bit DAC, and sound generation occurs in the loop() function.

• Doxygen stuff is now online.
• Removing sound generation from the interrupt handler and moving it into the main loop solved a LOT of problems, and now I can run the interrupt at 40 kHz. But I am still hearing some aliasing, so I'll need a lowpass filter after the DAC. Use this rail-to-rail op amp.
• ADSR and other slow-moving things should perform real calculations at only around 50 Hz, not 40 or 50 kHz. In between calculations they should use linear interpolation. Four billion divided by 50K is 80K, so it’s fine to use 16 fraction bits to interpolate. This will significantly speed things up.
• Never copy or move blocks of data. Move pointers instead. The persistence data for a voice should live in one place and never move.
• The next step right now is to take the code in the Voice class and split it into VCO, VCA and ADSR classes. Then add a Noise class, a Scaler class, a Summer class, and a VCF class. The audio outputs of all these should be 24-bit signed integers in the range from -0x80_0000 to 0x7F_FFFF. Use asserts to make sure they never go outside that range.
• Set up a monkey test framework that virtually pounds on the keyboard, and detects overflows, underruns, etc.
  • A SWIG wrapper will be very helpful with this.

Teensy 3.1 info

• The Freescale Semiconductor web page for the MK20DX256VLH7 processor used in the Teensy 3.1.
• The datasheet that talks about GPIO programming starting on page 1331.
• The Teensy 3.1 schematic. PTB17 is the GPIO that I want to read. The Port B input register is at 0x400FF050. There is no MMU so no need for any mmap craziness.
• Here is a great discussion of embedding assembly in C code. Also see http://www.ethernut.de/en/documents/arm-inline-asm.html.
• A C header file for registers in the MK20DX.
• Some nice info on ARM assembly language.

Earlier prototype

I want to read the GPIO in assembly to accurately measure the period of the oscillator. This code ran on the June prototype and measured the capacitance of the touch sensitive keyboard. The capacitance was used in the RC time constant of a free-running oscillator and the idea here is to get a measurement roughly proportional to the period.

1. Set counter to zero.
2. If input is LOW, go to step 7.
3. Wait for a falling edge. Proceed when input is LOW.
4. Increment counter while waiting for rising edge. Proceed when input is HIGH.
5. Increment counter while waiting for falling edge. Proceed when input is LOW.
6. Go to step 10.
7. Wait for a rising edge. Proceed when input is HIGH.
8. Increment counter while waiting for falling edge. Proceed when input is LOW.
9. Increment counter while waiting for rising edge. Proceed when input is HIGH.
10. Return counter.

So that piece is assembly, and then in C you choose a touch contact and call that function. That should ensure that you read the keyboard about as fast as it can be read. The code for this is buried in the sandbox directory.

static int measurePeriod(void)
{
    // Step 1, set up registers
    int count = 0, x = 0, mask = 1 << 17, addr = 0x400ff050;
#   define READ_INPUT  "ldr %1, [%3]\n"     "ands %1, %1, %2\n"
#   define INC_COUNT   "add %0, %0, #1\n"
    asm volatile(
        // Step 2, if input is low go to step 7
        READ_INPUT
        "beq step7"                             "\n"
        // Step 3, wait for falling edge
        "step3:"                                "\n"

        ... lots more code ...

        "step10:"                               "\n"
        : "+r" (count), "+r" (x), "+r" (mask), "+r" (addr)
    );
    return count;
}

This works well in both the Arduino/Teensy IDE and in the online ARM C++ compiler.