Pitch Transposition Methods (Arduino Due Based Pedal)

[Jbenward]

Hi all,

Long time lurker, first time poster.  I'm designing a pedal that achieves the pitch transposition of the Digitech PDS8000 Echo Plus or the EHX 16 Second Echo.  This will be my first digital build- I've built and designed several pedals, and modded even more.

My initial design is to have dual 1/4" inputs run through an opamp/buffer stage, biased, then into a 24-bit ADC. The data is then stored on an Arduino Due (written to an SD Card), then through a 24-bit DAC into a opamp buffer, then into another opamp to be summed with the dry signal, and then output.  The design is similar to the Pedal Shield design, with 2 channels and much better quality components.

Right now I'm looking at data sheets to try to find which opamps / ADC / DAC would work best for my purposes (voltage, current).

What I'm really curious is- would pitch transposition be best achieved by changing the sampling rate (or clock speed) of the ADC/DAC via the micro controller, or would some DSP method be better?  I'm thinking about sound quality and programming ease.  I was curious if I could replicate the methods that the older digital delays/loopers I mentioned earlier could be used in my project.

This project is a learning project for me, so any thoughts or ideas would be welcomed.

Thanks!
-Ben

[Digital Larry]

Here's what I "know" about DSP pitch transposition as done on the Spin FV-1.  The pitch shift you get depends on the difference in input and output sampling rates.  If you wanted to do this totally by manipulating the actual sampling rate (by clock), you will get glitches where the read pointer wraps around and passes the write pointer.  Since you're reading out faster than you're writing, at some points you'll be playing some audio segments twice.

The FV-1, and I presume other DSP methods use two separate Ramp LFOs that read out from the buffer, and the delta in sampling rate so to speak is handled by sample skipping and inter-sample interpolation.  At the point where one ramp jumps back, you have to fade that signal to zero to avoid that glitch.  So there are also two cross fade signals which suppress the glitches. 

The Spin AN-0001 document (you can Google it) describes this fairly thoroughly in a qualitative way.  The problem with this approach is that doing this crossfading introduces amplitude modulation to the signal - the two outputs are not completely phase aligned in general.  If it's not going too fast, it is like a tremolo.  If it is going too fast, it's more like a ring modulator sound which is not too pleasant.  You also have latency issues depending on the length of the buffer.  There are several competing constraints that are difficult to completely optimize.

[SISKO]

Why are you witing on a SD? I think this would lower the overall time performance.. Btw, this is for a real.time aplicattion isn it?

This may be of your interest http://www.electrosmash.com/forum/software-pedalshield/14-octaver-pedal?lang=en

[Digital Larry]

Why are you witing on a SD? I think this would lower the overall time performance.. Btw, this is for a real.time aplicattion isn it?

This may be of your interest http://www.electrosmash.com/forum/software-pedalshield/14-octaver-pedal?lang=en

I've written video at 3 Mbps to SD cards, so I don't think that's going to be a problem.  However, constantly writing and reading a relatively small section of the flash memory could get you into write-cycle wear-out territory, even with a 1,000,000 cycle spec.   FV-1's longest pitch shift buffer is only 4096 samples, about 1/8th of a second.  125,000 seconds is, err.... 35 hours.  RAM would probably be a better choice and you don't need much of it.

[Digital Larry]

This may be of your interest http://www.electrosmash.com/forum/software-pedalshield/14-octaver-pedal?lang=en

That's interesting.  I don't think that using two buffers or two DACs is necessary though.  All crossfading can be done with a single buffer, two read pointers offset by half the buffer length, a crossfade waveform (and its complement), and one DAC.

[g_u_e_s_t]

I've written video at 3 Mbps to SD cards, so I don't think that's going to be a problem.

ive also found that writing and then quickly switching to reading from an SD is horribly inefficient, and you dont get nearly the same data rates.  also, writing small chunks (just a few bytes) is not as efficient as whole blocks, as there is preamble to the writes that needs to be repeated with each chunk.  luckily a pitch shifter doesnt need much memory (as you pointed out).  the overlapping buffers create their own tone, and its best to keep this in the range where it isnt very audible, but yet isnt so long that you hear it as a delay.  somewhere around 20Hz or 40Hz is good, so about 30ms of samples.  although it is fun to have really long sample times, and then feed the sound back.  you get these ever-increasing layers of notes.

there is example arduino code for a pitch shifter, and schematics for anti-aliasing filters up here:
http://wiki.openmusiclabs.com/wiki/StompShield

the opamps used there arent the greatest.  i like the TLC074, but you would need to run it off a slightly higher voltage (9V or so) unless your CODEC is a 3.3V device, then 5V is fine.  otherwise look for rail-to-rail opamps with similar specs.  some of the higher end microchip devices are great for their price.  analog devices has some really nice opamps, but are pretty expensive.

[slacker]

What I'm really curious is- would pitch transposition be best achieved by changing the sampling rate (or clock speed) of the ADC/DAC

Changing the sample rate on the ADC/DAC won't change the pitch it will just change the sample rate, to change the pitch you need to change the rate at which you write to the DAC relative to the rate you read from the ADC. If you just want to replicate what the EHX 16 second delay does you need to play the loop back at half or twice the speed you recorded it.
If you want to do actual pitch shifting you need to follow Larry's advice, I've got a pitch shifting example here http://www.diystompboxes.com/smfforum/index.php?topic=106741.0

[potul]

...
Long time lurker, first time poster.  I'm designing a pedal that achieves the pitch transposition of the Digitech PDS8000 Echo Plus or the EHX 16 Second Echo.  This will be my first digital build- I've built and designed several pedals, and modded even more.
...

Do you want to record a loop and then play it at a different pitch/speed, or do you need real time pitch shift?

[harmless]

Windowing and playing back buffers at varying speeds isn't too tricky, but it also doesn't sound that great for bigger intervals like octaves.

For an arduino, it's likely the best you're going to get though.

I've been playing with the stellaris launch pad that has an 80 mhz arm proc and an FPU and even then doing any sort of FFT based method will be tricky due to limited computing power.

[Digital Larry]

I've been playing with the stellaris launch pad that has an 80 mhz arm proc and an FPU and even then doing any sort of FFT based method will be tricky due to limited computing power.

That looks pretty cool, and affordable.  Does it have decent audio I/O on it already or are you going to have to add something?  I'm not into PWM audio, even for something as crude as guitar effects.  Are you programming in C/C++?

[harmless]

I've been playing with the stellaris launch pad that has an 80 mhz arm proc and an FPU and even then doing any sort of FFT based method will be tricky due to limited computing power.

That looks pretty cool, and affordable.  Does it have decent audio I/O on it already or are you going to have to add something?  I'm not into PWM audio, even for something as crude as guitar effects.  Are you programming in C/C++?

You'll want the tiva launchpad (not the msp430 one).  It's got 2 12 bit ADCs and uDMA so I have a timer setup for 44khz along with uDMA configured for the ADC so with very little CPU utilization I get frames completely filled for me with simple interrupt notification. It's pretty nice.

For output, I'm just using an SPI 12bit DAC (tlv616) running off the same 3.3V the MCU needs. I've got a basic rail to rail opamp with some amplification going in, but it's generally low parts count.

I'm programming in straight up C using Code Composer Studio, which is ok I guess.  I'm totally spoiled by visual studio and the fantastic msdn docs, but CCS works well enough.

[SISKO]

Be sure to check the Teensy 3.1 and its audio module

[Jbenward]

Thanks for all of the info here, guys.  Sorry for not checking back in for so long- I've spent the last few months digesting this info and researching other avenues.  I've come up with a little better idea of what direction I'm heading in.  My plans have changed somewhat- I'm wanting to implement a more flexible audio effects system.

I've invested in some hardware (an Oscilloscope) and a few software packages (NI Multisim, NI LabView, MatLab, Simulink, as well as a few other items) to assist in the planning & building of this project.  I am definitely an amateur in this regard, but I'm coming along.  I am picking up the software pretty quickly- especially MatLab- it such a nice package to use to design audio filters and other algorithms.  I'm doing schematic design and simulation of the hardware in Multisim (along with LabView), but I only have a couple of systems designed.

One of my first decisions was to change this project into something more than a stompbox-guitar pedal project.  I'm looking to create a small modular synthesizer/audio effects platform.  I would like this to be smaller than the Eurorack format.  I'm also designing the modules to function by themselves using a 12v power supply, so they aren't totally tied to the system.

I'll give you a basic rundown sales-pitch... I'm calling it the Modular Lab Project (for now).

"I am working on a design that is powerful, flexible and extensible; it is easily reprogrammable and easily reconfigurable.  I wanted to build a system that allowed me to add or change components.  The overall design uses the best aspects of microcontrollers, FPGAs, embedded systems programming, idiosyncratic integrated circuits, analog circuitry, silicon, germanium, circuit bending.... anything else that goes bleep, boop, tweet or buzz.

This is an attempt to plan, design and build a feature-rich and highly modular audio recording and total sound manipulation system.  The core of the system are the embedded microprocessors and high quality AD/DA I/O that samples, stores, manipulates and plays audio.

The system's modularity, programmability and mixed digital/analog signal structure allows an almost unlimited amount of sounds to be created, modified, stretched, and tortured beyond all recognition.

The Modular Lab allows sampling, sound processing, analog + digital synthesis, all in a system which can be used alone and/or with other digital/analog gear.  The pristine digital sampling/effects can also emulate older digital gear via adjustable sample/bit rates, adjustable clock jitter, circuit noise, compression and analog distortion.  As another bonus, classic sound generating chips can be emulated on the FPGA.

The hardware consists of several microcontrollers and an FPGA, with many modular add-ons for sound processing in both the digital and analog domain.  There are also ports for patching other effects into and out of the signal path.  The effects can be controlled and modulated both in the digital and analog domain, via MIDI and CV (control voltage) respectively."

That's the basic info part- if you want to know the nitty-gritty, see below.

The modules I've currently planned for are:

1. Main module - 2 audio ins, 2 audio outs utilizing high-quality burr-brown OPA227 op-amps, PCM4202 ADC and PCM1791a DAC.  After the input buffers and ADC, the audio is fed into the micro controller core for storage in RAM, then stored in nvRAM if it is saved.  There is an ARM core (functions as the main audio processing unit), an MCU which handles user interface (and MIDI serial messages from the MIDI/CV module-see below), an FPGA (which I have thus far been leveraging as an SRAM memory controller, using to interface the MCUs, as well as a handful of other tasks which I feel will likely grow) and a system bus scheme for routing data intra-module.  This unit contains the systems display, controls, audio inputs and outputs.  The main module, by itself, would allow you to sample and playback audio, process the samples digitally, as well as using the FPGA to simulate audio chips (right now I have a catalog of old chips- C64, NES, etc, but you certainly could create whatever you want on it).  I've also looked at the Analog Devices DSP line, and might swap the general purpose ARM core for a DSP.  It's a matter of cost and best usage of resources.  I have a couple of novel ideas when it comes to control schemes for this unit- first, I am working on a motorized fader for interactive sample playback control (the fader moves as the sample plays at another control's set rate, and stopping, slowing, or moving the fader forward changes the sample speed- like a physical, interactive progress bar.  The fader movements can be stored in memory, so any manipulations to the fader can be saved (non-destructively) to the sample).  Secondly, I have designed a lighted button interface that is laid out similar to a keyboard- this will be sample storage, and can also be used for sample playback, midi messages, etc.  A key lights up when a sample has been saved in each bank.  There will be other visual cues as to the sample state, ex. unsaved changes, deletion, etc.


2.  MIDI/CV module - this is the module I'm currently programing- I already have a basic prototype of the hardware built.  It has it's own microcontroller- an Atmega 644a w/ SPI 8 channel 12-bit DAC.  This has DIN5 MIDI in & DIN5 MIDI out (w- switchable MIDI thru); USB-over-MIDI; 2 bipolar 5v CV ins; 8 unipolar 5v CV outs (configurable as 6 unipolar, 1 bipolar/4 unipolar, 2 bipolar/2 unipolar, 3 bipolar/4 bipolar) all individually assignable as Gate, Envelope, 1v/Oct Pitch, Hz/Oct Pitch, triggerable & controllable via MIDI.  I will likely add some other features, possibly, such as sync-able LFOs outputs (MIDI or CV), CV mixing, CV delay- I will be seeing how much this 8-bit AVR can handle.  The unit also can transmit/receive MIDI data through the main modules UI MCU.  I wanted to create a one-stop shop for MIDI.  With that in mind, I'm also trying to keep it (relatively) simple, cost effective, while still being extremely flexible.

3.  Compressor/Distortion module - this is an analog compressor and distortion module that each parameter can be controlled serially from the main module's micro controller, or via CV 1/4" inputs.  The serial control is accomplished via an AVR.  I've done the least work on this guy, so far, so there's not much to say except for wishful thinking.  This unit is a stand-in for any effects unit- I would like to create the ability to add 4 or 5 effects units to the unit.  I'm designing these to operate in normal knob & CV control mode when used as a pedal, but when connected to the Main module, there is more controllability available.

So that's the breakdown.  Long read, I know.

I decided to stay with the Arduino Due ARM platform for the main processor (at least for this prototyping phase)- I've done several tests and have found it to be able to handle 2 channel audio sampling and playing adequately.  The first full prototype will not be using the Arduino board- I'm designing a PCB that will take the specific ARM or DSP chip I have yet to decide on.  But that's still at least 6 months off.

Right now I'm working on this all by my lonesome, so it is going to take a while to get this to 100% complete- maybe looking at a couple of years.  I'm making good progress now as it stands, I'm probably a month away from having prototype boards of the MIDI module created.  My main obstacle is deciding what form-factor to use for this- I'm resistant to use Eurorack, since everything associated with that format seems very very expensive.  I would like to go with something that is more pedal-like.  If you have any suggestions, I'm all ears.  I've had a lot of coffee and not much sleep, so I need to end this novel where it is.  Have a good one.

-Ben