You can read more about the Octomod here, but it essentially allows computer control over the analog control voltages commonly used in analog synthesizers. Input a number 0 – 1023, and the device will output an analog voltage from -5V to +5V.

The OSC interface presents the inputs to the device, in the form of 8 numbered channels. The user sends an OSC message from their software of choice, and the interface program receives, processes, and communicates the data to the microcontroller in the device. I used a Teensy 2.0, which is very similar to Arduino, and any of this information should easily translate to the Arduino.

The OSC Interface

The OSC interface is simple. In your host program, you need to create a message formatted as follows:

/dac chanOne chanTwo chanThree chanFour chanFive chanSix chanSeven chanEight

For example:

/dac 256 273 50 1020 756 902 840 111

The trick here is that instead of sending an individual message whenever a channel changes, you can reduce network traffic by packaging all of the channels in one message, and updating that message at the rate of the most rapidly changing channel.

Sending OSC from Max/MSP

Here’s what it looks like in Max:

What is this code doing?

1. The pak object outputs all eight of its inputs as a list whenever any one of the inputs changes.
2. The message box below appends the /dac prefix to the list. Now the OSC message is formatted correctly.
3. We don’t want the message to send automatically whenever a channel updates, so we buffer it with the second message box. This is done by sending the first message to the right inlet of the second message box.
4. Finally, the metro object triggers the full OSC message to be sent once every 10ms.

Receiving OSC in Processing

The OSC interface program is written in Processing. OSC is easy to use in Processing as well. With a couple of lines of code, we’re ready to go:

import oscP5.*; // import the oscP5 library
import netP5.*; // the netP5 library is also required for the osc library
OscP5 oscP5;
oscP5 = new OscP5(this, 9999); // all you need to start oscp5 listening on port 9999

Now all we have to do is tell our program what to do when an OSC message is received. This is done by defining the oscEvent function.

After parsing out each of the eight input numbers, we check if a given channel needs to update its state. If so, we pass it to the writeValue() function. If not, we ignore it and don’t have to waste processor time sending the redundant data over the serial port. In my experience, this allows update rates of up to (possibly beyond) 1ms.

void oscEvent(OscMessage theOscMessage){
 if(theOscMessage.checkAddrPattern("/dac")==true){
   for(int i = 0; i < 8; i++){
     data[i] = theOscMessage.get(i).intValue();
     channelData[i] = data[i];
   }
   for(int i = 0; i < 8; i++){
     writeValue(i, data[i]);
   }
 }
}

Writing Serial Data to the Teensy

Serial teensy;
teensy = new Serial(this, Serial.list()[0], 19200);

The above lines are used in Processing to initialize a Serial object, allowing both read and write operations. The Serial.list()[0] argument indicates which actual serial port we want to write to. On my system, the Teensy always shows up as port 0 – this might be different on yours. Finally, the baud rate of 19200 is specified. Baud rate is the number of distinct signal events per second, and is a measure of data transfer speed.

Below is our writeValue() function, which was referenced above. The function is called repeatedly, once for each new sample to be written. First, we have to choose which of our two DAC chips should receive the data. Channels 0 – 3 go to chip A, 4 – 7 to chip B.

The MAX5250 is expecting a two byte word, which is assembled in the next section of code.

The SPI data expected by the MAX5250 DAC is as follows:

The first two bits select which of the four-per-chip channels to use, the second two bits allow us to write data with or without updating the actual voltage outputs, the next 10 bits are the actual data to be assigned, and the last two bits are unused. So, to write a data value of 512 to channel 3 and immediately output a voltage, we would send 1011001110110100.

As you can see, it’s a bit involved, and that’s why we want to avoid running all of this code unless the data has actually changed. We end up with three bytes to send to the Teensy 2.0, a one byte digit to indicate which DAC we want to write to, and the two additional SPI bytes. These are put into a buffer (really just an array) which is only transmitted when the buffer is full. This is to circumvent some timing weirdness in the USB to Serial conversion hardware.

void writeValue(int _channel, int _data){
 if(_channel > 3) { // assign one of two dac chips to respond
    dacChip = 1;
  } else {
    dacChip = 0;
  }


/* bit shifting and masking to assemble proper list of bits for the DAC */
  _channel = _channel << 14;
  updateBits = 3 << 12;
  _channel = _channel | updateBits;
  _data = _data << 2;   spiWord = _channel | _data;
  binaryString = binary(spiWord, 16); // at this point, we've assembled our proper list of 16 bits
  outputData.add(byte(dacChip)); // so we'll throw them into an array, to facilitate transfer over serial
  outputData.add(byte(unbinary(binaryString.substring(0, 8))));
  outputData.add(byte(unbinary(binaryString.substring(8, 16))));
  if(outputData.size() >= 24){
    outputBytes = new byte[outputData.size()];
    for(int i = 0; i < outputData.size(); i++){
      outputBytes[i] = outputData.get(i);
    }
    teensy.write(outputBytes);
    dataIndex = 0;
    outputData = new ArrayList();
    previousUpdate = currentTime;
  }
}

Initializing SPI on the Teensy 2.0

Here’s an explanation of SPI from Wikipedia:

The SPI bus specifies four logic signals.

• SCLK — Serial Clock (output from master)
• MOSI/SIMO — Master Output, Slave Input (output from master)
• MISO/SOMI — Master Input, Slave Output (output from slave)
• SS — Slave Select (active low; output from master)

Essentially, the Master (Teensy 2.0 here) triggers the Slave chip by setting the SS pin low. Then the SCLK pin outputs a periodic clock pulse while the MOSI pin transmits the data (holding the SS pin low for the entire transfer). Here’s an image of the transmission from the MAX5250 datasheet – note that they use DIN (Data In) instead of MOSI, but it’s the same thing.

The first bit of code here is just a couple of statements to simplify our SPI communication. The DACs have a “Slave Select” pin, which allows them to either receive or ignore incoming data. This allows for easier wiring, you can connect all of the SPI lines to each chip, and just select which chip should respond at a given moment. Our DAC select byte (from above, in the writeValue() function) interfaces with the Slave Select code on the Teensy, and allows us to route data to the appropriate chip.Below, in the setup() function, we set the SS pins to output and set them both HIGH, so that no data is accidentally received by the DACs.

Finally, we call the setup_spi() function, found in Andrew Smallbone’s SPI library. These settings define how the Teensy should handle SPI, whether the DACs read the data on the rising or falling edge of the clock pulse, the SPI transmission rate as related to the Teensy clock, and a couple of other settings. You might notice that the serial interface is being initialized with a baud rate of 9600. The Teensy 2.0 actually ignores any baud rate argument and runs at full USB 2.0 speed.

#define SELECT_DAC_ONE digitalWrite(PORTB0, LOW);
#define DESELECT_DAC_ONE digitalWrite(PORTB0, HIGH);
#define SELECT_DAC_TWO digitalWrite(PORTD0, LOW);
#define DESELECT_DAC_TWO digitalWrite(PORTD0, HIGH);


void setup(){
  CPU_PRESCALE(CPU_4MHz);
  pinMode(PORTB0, OUTPUT);
  pinMode(PORTD0, OUTPUT);
  Serial.begin(9600);
  DESELECT_DAC_ONE;
  DESELECT_DAC_TWO;
  setup_spi(SPI_MODE_0, SPI_MSB, SPI_NO_INTERRUPT, SPI_MSTR_CLK2);
}

The last bit of code here reads incoming serial data, and immediate sends it out to the proper DAC. The serial buffering on the Teensy is a little bit different than the Arduino, in that it receives an entire USB packet at a time. The timing of the calls to Serial.read() can then be an issue. We want to make sure that we’re reading our three bytes in the proper order, and not getting out of phase with the host app, so we check that our first byte is either a 1 or a 0. Since the SPI interface packs data into the first and last bits of our data word (the second two bytes), a byte with the value of 1 or 0 will only appear as the first byte in the series. Timing is also important here, we need to introduce some brief delays so that we’re not reading or writing data too quickly.

void loop(){
  pollAndWrite();
}

void pollAndWrite(){
 data = false;
 while(!data){
  if(Serial.available()) { // look into the receive buffering - not receiving from Max properly
    firstByte = Serial.read();
    delayMicroseconds(100);
    if(firstByte == B00000000) {
      secondByte = Serial.read();
      delayMicroseconds(100);
      thirdByte = Serial.read();
      SELECT_DAC_ONE;
      send_spi(secondByte);
      send_spi(thirdByte);
      delayMicroseconds(10);
      DESELECT_DAC_ONE;
      data = true;
    }
      if(firstByte == B00000001){
        secondByte = Serial.read();
        delayMicroseconds(100);
        thirdByte = Serial.read();
        SELECT_DAC_TWO;
        send_spi(secondByte);
        send_spi(thirdByte);
        delayMicroseconds(10);
        DESELECT_DAC_TWO;
        data = true;
    }
  }
 }
}

So that’s the software side of the USB-Octomod. Although it’s fairly involved, there are only a few tricky spots, and the OSC interface greatly simplifies what the end-user actually has to think about during composition or performance.  Once the Processing and Teeny code is compiled and loaded, it becomes a plug-and-play device.

The Lazers! release, clocking in at around 100 minutes of music, is now available for free at Stasisfield.

Stasisfield curator John Kannenberg eloquently describes the recording:

Lazers! is a Milwaukee-based trio of composer/performers including David Collins, Steve Schlei, and Greg Surges. Their collective work focuses on custom-built instruments and indeterminate notation, incorporating situational, playful approaches to performance while generating exploratory sonic spaces. Electronic instrumentation comingles with structures and forms rooted in the acoustic realm of improvisation: look for beats elsewhere, this material is more about sound’s relationship to negative space than pattern and rhythm. A multitude of approaches and scenarios makes each track on their debut album a fresh experience, its own uniquely impermanent world.

Tracklist:

Improvisation (Silver) Part A

Mediation – David Collins, 2009

Improvisation (Silver) Part B

RadioGamelan – Greg Surges, 2010

Fission (Three Parts) – Greg Surges, 2009

Improvisation (Coumarin)

Fission (One Part) – Greg Surges, 2009

Improvisation (Stilbene)

Improvisation (Pink)

Moving from the very first Arduino-based prototype (breadboarded on a Radioshack experiment lab), I decided that a Teensy 2.0 would be a better solution. Cheaper, faster, breadboard capable, and a true serial peripheral, the chip works great and can be programmed using a slightly-modified version of the Arduino environment. You can also use the usual AVR toolchain if you prefer.

This is the original, very minimal prototype on a Radioshack experiment board.

Setting up the Teensy 2.0 for breadboarding.

The next thing to do was to work on the software side of things. Originally, I developed a Max/MSP patch which directly translated integers into the proper binary string, as required by the MAX5250 DAC ICs. I wanted to make the project completely open source, so I decided to create a stand-alone program using Processing. The program essentially listens for specific OSC messages (which can be sent from any program or process the user chooses), and then translates those messages into 5250-compatible binary data. I think the solution works well, and removes any necessity for the user to own specific software.

Above, a Max/MSP patch transmits data over OSC, to the host program (below), which converts the received integers into binary data required by the DAC ICs.

After some final touches to the layout, (applying low-pass filters to smooth the output voltages, converting the unipolar output of the DAC to a bipolar voltage) I laid the circuit out in Eagle.

Here's the PCB layout as sent in for fabrication. There are a few small errors...

This is the silk-screened front of the PCB prototype.

The back side, ground plane and all.

I’d say the board looks pretty good. I got it from BatchPCB.com, part of Sparkfun. Not exactly the cheapest or the fastest, but good for a one-off. (They gave me two…?)

Here’s the front again, with my hand for scale. The board is 2.9″ x 3.05″.

In this clip, sample data is being sent from Max/MSP over the serial port to a Teensy 2.0 microcontroller. The controller sends the incoming data over an ISP connection to a DAC, the output of which can be used as a modulation source for analog synthesis modules.

Computer Generated Control Voltage Generator from Greg Surges on Vimeo.

Buzzcloud – Greg Surges from Daniele Sosio on Vimeo.

Gates (No. 1) is a software instrument, programmed in Pure Data. Inspired by other instrument builders, particularly David Tudor’s electronic instruments, Gates (No. 1) provides the performer with high-level control of musical events, while the moment-to-moment details emerge from the patch itself.

The main interface for Gates (No. 1).

Central to the sound of the instrument is a set of three feedback networks. Implemented using recursive delay lines, each network emphasizes a particular frequency range: low, medium, and high. The frequency ranges are user-selectable, allowing for coarse control over the register of a particular musical event. Slight changes in delay time and filter cutoffs destabilize the feedback, producing glissandi and other effects.

Feedback network producing low frequency sounds.

The pitch register is selected through a combination of key-presses, which also determines other parameters of the sound. The first of those other parameters is a selection of one of 6 sound-processing algorithms which is applied to the selected feedback network. The 6 processing types are: amplitude modulation by line segments, ring modulation by filtered noise, ring modulation by a sine wave, recursive delay with delay time modulation, a chorus effect, and a set of bandpass filters in series (creating phase cancellations).

ASCII-based input module.

Inner workings of the patch. Above are the different processing modules, routed through an echo effect, and out to the DAC.

The second parameter is a selection of one of 50 different, hand-drawn wave shapes. The wave shapes provide control data for the modulation sources described above.

One set of wave shapes, used to control the sound processing modules.

The key-press combination also determines the duration and number of repeats of a sound, ranging from short, repetitive events to long drones. Finally, the performer can choose to route the output of the instrument through a secondary processing unit, which modifies its processing algorithms according to the rhythmic onsets of the generated sound.

The secondary effects module adds a layer of digital grit, contrasting with the cleaner sounds of the instrument.

The variety and diversity of sound generation, processing, and control algorithms ensure that the instrument is never fully under the control of the performer. Rather than a flaw, this is a feature, as it ensures an exciting challenge for the performer, and produces performances which can retain similar characteristics while varying widely in structure and duration.