Why has nobody made a quick and dirty pitch-shifter for the arduino?

... like this one?

Yes, I know that there are shields you can buy that can make this possible, but I would ideally be hoping for something much more compact, using the standalone 28-pin chip, with perhaps only the small amount of extra circuitry required for the dac and a separate adc if needed.

If not, I'll pick up an attiny85, but I have several atmega328 chips already lying around not doing anything, so I'd prefer to go that route.

There is one in my book:-

If not, I'll pick up an attiny85, but I have several atmega328 chips already lying around not doing anything, so I'd prefer to go that route.

Any code that can run on an attiny85 can also run on a atmega328, you just might to have to change some pin numbers.

On your second point, the atmega328 does not have a 64mhz phase-locked loop clock that the program at the above link exploits, and I'm not entirely sure what changes would be necessary to it to work correctly on the atmega328.

the atmega328 does not have a 64mhz phase-locked loop clock

Nether does a ATtiny85. A search of the data sheet brings up no results for a phase-locked loop.

From here:

The internal PLL in ATtiny25/45/85 generates a clock frequency that is 8x multiplied from a source input. By default, the PLL uses the output of the internal, 8.0 MHz RC oscillator as source. Alternatively, if bit LSM of PLLCSR is set the PLL will use the output of the RC oscillator divided by two. Thus the output of the PLL, the fast peripheral clock is 64 MHz.

Missed that sorry because I was searching for a Phased locked loop not a PLL.

So how are they using this in the voice change software?

As you can see it defaults to 8MHz which is half the speed of a Uno?

Alas, my depth of knowledge on low-level programming avr chips is not complete enough for me to feel like I can be entirely sure. I think if I were more knowledgeable, I would either know why this only works on the attiny85 and wouldn't be asking the question at all, or how to make it work on the atmega328 in the first place (and would have already done so).

Based on what I've been able to work out about it from the article, however, I think that it's the rate for PWM output.

Based on what I've been able to work out about it from the article, however, I think that it's the rate for PWM output.

There is no need to have a fast PWM output, on the Uno you can get the PWM to go at several hundreds of KHz and you wouldn’t want to go any faster, there is no advantage to going faster.

The big thing you need is a buffer and the Uno has way more memory for this than the ATtiny 85.

Grumpy_Mike:
Missed that sorry because I was searching for a Phased locked loop not a PLL.

So how are they using this in the voice change software?

As you can see it defaults to 8MHz which is half the speed of a Uno?

I think there's a typo in the link of the original post. Either the "8MHz" should be "64 MHz" in this sentence or else their division is wrong since 8 MHz/256 is 32 kHz: The frequency of the PWM square wave is specified by OCR1C; we leave it at its default value, 255, which divides the 8MHz clock by 256, giving 250kHz. The paragraph above the code snippet says they're using 64 MHz and the code comment suggests no pre-scaler on the counter.

PWM will generate a strong carrier at the PWM frequency (64 MHz / 256 = 250 kHz) which one wants to be well above the highest frequency the "DAC" is trying to reproduce, so for audio frequencies (below 20 kHz or so) there's more margin with a faster PWM frequency. It's not obvious though why the 64 kHz PWM carrier of the Uno wouldn't be sufficiently fast.

It's not obvious though why the 64 kHz PWM carrier of the Uno wouldn't be sufficiently fast.

But you can get much faster than that with a Uno. I used the PWM to generate the 135 KHz needed to make an RFID reader on one project and I recall I was still not at the fastest it would produce.

Grumpy_Mike:
But you can get much faster than that with a Uno. I used the PWM to generate the 135 KHz needed to make an RFID reader on one project and I recall I was still not at the fastest it would produce.

Sure, but there's a trade off between PWM rate and effective "DAC" resolution. 64 kHz is the max assuming one is using 8 bits of the counter/timer (effectively an 8 bit DAC). For an audio output application sacrificing this already limited dynamic range for more speed probably isn't optimum.

Given that no one can hear 64KHz not only is it not optimal it is stupid.

Check out a Teensy 3.x with Teensy Audio Library. You can implement pitch shifting with the granular class from the library. And, you get digital I2S audio I/O, 44K sampling rate, and 16-bit audio resolution.

The original question, I feel, remains.

It feels to me like this should be possible do implement with just a bare arduino chip and a few supplementary components, given the simplicity with which it can apparently be implemented with an attiny85, requiring only a handful of capacitors, resistors, and switches that even collectively have negligible cost.

But yet, I can find no evidence that implementing pitch shifting on arduino uno is even possible without purchasing a dedicated audio manipulation shield. I realize that the atmega328 is not a DSP chip, but is it truly the case that it is not even up to what seems like it should be a very basic task of shifting pitch in real time without adding at least another $20 in hardware?

I can find no evidence that implementing pitch shifting on arduino uno is even possible without purchasing a dedicated audio manipulation shield.

What about my book? Yes that uses an external D/A and external ram for a whole host of effects, but just look at the shift up and down and you will see the buffer is small and the sample playing example can be drafted in to replace the external A/D.

So you say quick and dirty. How dirty?
Shifting an octave up and down is easy because it requires a very short buffer and the output can be generated by the PWM output. If you are going into shifting other amounts finer than an octave, then it is more difficult

And the dirty part refers to the noise you get when the input and output buffer pointers run over each other.

I mean quick and dirty in the sense that it requires only a minimal number of external components and code, not "dirty" in the sense that it does not actually do the job very well.

As to the project in your book, to the best of my understanding it involves building its own "sound card", which is not really any different in fundamental premise than requiring an entire audio shield, requiring additional IC's such as ram, and a dedicated interfacing library.

Finally, the sound board in your book requires components which I cannot source in a package amenable to assembly on a tiny solderless breadboard.

to the best of my understanding it involves building its own "sound card", which is not really any different in fundamental premise than requiring an entire audio shield, requiring additional IC's such as ram, and a dedicated interfacing library.

Read replay #14 again. I said all those things could be bypassed for just the octave change.

and a dedicated interfacing library.

Nothing in my book requires that.

I mean quick and dirty in the sense that it requires only a minimal number of external components and code, not "dirty" in the sense that it does not actually do the job very well.

How do you know what that ATtiny design will perform like? Is there a link?

Anything that does not use external components apart from the odd capacitor and resistor is going to be restricted to 8 bit quality sound even when it involves no processing. That is telephone quality at the most. This is the best you can do with the sound:-

This is also in my book.

I think you are vastly underestimating what sort of processing you need for "professional" quality pitch shifting.

Here's an example of it being used in real time: youtube

Also, telephone quality would be entirely adequate for my purposes.

Yes I would consider that output as dirty because of the distortion it introduces.

Basically it is much the same as my code involving the use of a circulating buffer with an input and output pointer.
Figure 15-11 shows this for an octave shift.

The difference is that he is using a fraction increment of the buffer pointers to get a finer control over the amount of pitch shift which is why there is extra distortion.

On his web site Technoblogy - Audio Pitch Shifter he says:-

The first part of the audio processing consists of sampling the audio input, using a pair of differential inputs with a gain of x20

This is not shown on the diagrams and is an extra circuit, the sort of thing you want to avoid. You will see that the audio input is fed into PB4, that is once the op amp with the " pair of differential inputs with a gain of x20" has amplified the signal.

Providing amplified audio input is not a problem for… I just needed something to do a basic pitch shift, I have audio amps I can use already to adjust the signal to whatever level is needed.