MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

a NEW (?) vocoder concept
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page 1, 2  Next [all]
Author a NEW (?) vocoder concept
Grumble
Ok, here's the thing...
I'm in the process of designing a vocoder and I think I have a nice, new concept.
Some parts are already built, but I'd like to have comments from someone who knows about the ins and outs of vocoders and diy design.

It's going to be a 12 channel vocoder in the range of 300Hz - 3kHz (the human speech bandwidth).
First the modulator signal is going into an arduino (ofcourse! 8) ) where an FHT is calculated (FHT is a faster FFT methode), 12 bins are sent to a 12 channel 8 bit Trimdac AD8804, this way I have 12 analog signals representing the power of a certain frequency.
The Vref input of the trimdac is connected to the carrier signal, so I have 12 carrier signals with an amplitude analog to the power of the modulator signal in that particular bin.
These 12 signals are fed into 12 band-pass filters with a F0 the same as the bin they are connected to.
The output of these 12 BP filters go thru a potentiometer and are summed and this is the output signal.

Pro's (as I see them):
1 - only 12 filters for a 12 band vocoder
2 - NO vca's (although you can never have enough..)
3 - software patchable: easy to rearrange the signal from the bins to the filters



The Arduino FHT library is a fast implementation of a standard FHT algorithm which operates on only real data. READ MORE HERE

Any thoughts?
Grumble
This is what I have so far, software is working:


JP2 is the modulator input (Voice) and JP3 is the Carrier signal
And the filters I will use:

Grumble
About software patchable:

When using LIN_OUT8 the frequency bins are:
2 300 Hz
3 445 Hz
4 600 Hz
5 775 Hz
6 910 Hz
7 1060 Hz
8 1200 Hz
9 1360 Hz
10 1530 Hz
11 1650 Hz
12 1800 Hz
13 2000 Hz
14 2400 Hz
15 2500 Hz
16 2700 Hz
17 2800 Hz
18 3000 Hz
19 3150 Hz
20 3333 Hz
21 3440 Hz
22 3600 Hz
23 3700 Hz
24 3800 Hz
25 4000 Hz

And this code:
Code:

void spi_to_dac (void)
{
   uint8_t total_number = 12;
   uint8_t channel = 0;
   for (uint8_t byte_number = 0; byte_number <total_number;byte_number++)
   {
      PORTB &=  ~(1<<PB2);            // drive CS low
      SPDR = channel;                  // send which dac channel
      while ( !(SPSR & (1<<SPIF))) {};   // ready?
      SPDR = (fht_lin_out8[(byte_number+2)]);// send low Byte
      while ( !(SPSR & (1<<SPIF))) {};   // ready?
      PORTB |=  (1<<PB2);               // drive SS high again
      channel++;
   }
}

This code sends 12 bins to the trimdac in subsequent order. This can easily be rearranged bij putting the bin numbers in an array and have that sent to the DAC,
So now DAC1 gets the data for 300Hz, DAC2 445Hz etc. but it is easy to invert that order so DAC1 gets data for 2000Hz, DAC2 for 1800Hz etc.
SoundPool
I'm afraid I'm not much help with your design questions, just popping in to say that I do like the idea of a compact digital vocoder in hardware. Is the idea for it to be compact enough to be a single module? Or more a stand-alone unit? Any frontpanel controls?

Also is your frequency range decision to just have what you feel is the most useful range covered in the most bands? Just personal taste, but I find I never actually use a voice with a vocoder- for me things get interesting when using different signals.
Grumble
It is not a digital vocoder, it's a hybrid: The Arduino and the Trimdac are digital, the filters are analog.
I'm thinking about making it eurorack format, with 12 potentiometers for the density per frequency band, and an encoder with switch for software patching and maybe an oled display.
toneburst
Very intrigued!

I will be watching this thread with interest.

My (naive) concern would be that it would be quite low-resolution.

Would it be better to use a 32-bit MCU, rather than an ATMega?

Please post example recordings of audio output. Would love to hear how it sounds.

a|x
toneburst
I guess you'd need to implement smoothing / lowpass-filtering to smooth out the 8-bit jaggies.

a|x
Grumble
The envelope values are 8bits, so I think it will be okay.
We’ll see seriously, i just don't get it
The coming weekend I’ll make a one filter proof of concept It's peanut butter jelly time!
toneburst
What's the resolution of the ADC, though, and what sample-rate can you run them at, and still run the analysis?

Those might be the limiting factor, in terms of intelligibility.

Limited sample-rate means you'll loose top-end, and that's where vocoders tend to fall down.

Have you considered what to do about sibilance?

Two conventional approaches are:

1. Pass through high-pass-filtered modulation signal
2. Add filtered white noise enveloped by HF content of modulation signal

Either of these approaches can significants aid intelligibility for speech signals.

a|x
toneburst
Being able to mix up the bands is a great feature!

Also, some kind of slew/lag effect can be cool.

Oh, and the ability to freeze the current channel states, and maybe even save them for future recall.

smile

a|x
Grumble
The adc resolution is the standard Arduino adc, being 10 bits.
That is the voice signal, from which the FHT is calculated every 11mS (~90Hz), the result is (in this case) 12x 8bit numbers representing the envelope of the 12 frequency bands.
The full bandwidth of the carrier signal is multiplied by these 12 numbers, so I have 12 amplitude modulated full bandwidth carrier signals.
These 12 signals are filtered by 4th order bandpass filters with a center frequency as in the tabel above.
That is how I loose 12 filters and 12 vca’s applause
organon
Interesting approach. How's the latency on this? That aspect always made me shy away from doing any FFT in eurorack because latency is intrinsic with fourier transform since you have to analyze an entire bin before you resynthesize or spit out any data. At 300Hz lowest freq that's probably not much of a problem?
Grumble
I have no idea what the latency is, it looks like about 11mSec because that is how fast the FHT is, but I will know for sure if I am a bit further in building this.
What is the latency if one has to filter, make an envelope and controlling the vca for each channel in analog vocoders.
guest
this is super exciting. i like the idea of using MDACs to eliminate the VCA. it seems like you could put the filter before or after the MDAC, not sure which would be better. one of those single-IC, switched capacitor filters would make for a compact design.

why not use higher bit depth? the FHT returns 16b values, and an MCP4921 can do 12b for 1.5$. they also have duals for not much more as well.

also, check out the fht_mag_octave() function. its only 8b, but it could be rewritten for 16b, and gives a more musical response as the frequency bins cover octaves. its only 8 bins, but it could also be rewritten for more bins, although they wouldnt be evenly spaced at that point.

i think sample rate is the main concern. if you want up to 4kHz, youll need 8kHz sample rate, or a sample every ~100us. the 16 point FHT can almost do this, but its only 8 output bins. the 32 point FHT runs in about 200us, so 2.5kHz bandwidth (and will require a pretty stiff antialiasing filter). and these bins are linearly spread out, not logrithmically.

[EDIT] i may be screwing up my thinking on this, as its N*update rate for the sample rate to fill N bins, so maybe its fine, and its just the output amplitudes that are bandwidth limited. in which case the highest N (256) would be the thing to use at 5ms update rate.

[EDIT] make that 11ms like you said.
Grumble
I think that the modulator input (voice) will get some alising filtering, because that is the only signal getting sampled! And maybe a 2nd order filter going from 300 to 3000Hz.
The carrier signal is not sampled, only multiplied and filtered (both analog!)
Every 11mSec there are 256 samples processed.
Mind you! the dac is 12 channels, 8 bit depth, enough for an envelope.
The dac takes about 44uSec to fill.
guest
the aliasing shouldnt be that bad. if youre sampling at 38kHz, and only interested in 4kHz and below, thats a lot of leeway in the filter. if youre using the 256 bin FHT, then its approximately 24 bins from 150Hz to 3.6kHz, so youll have to add adjacent bins to get 12 output channels. these need to be added in quadrature (x^2+y^2), or you could go with the 128 bin FHT and just use single bins. the former will have less crosstalk between bins, but might take a lot of time to do, depending upon the implementation. if you find its too slow, let me know, and i can probably code up an assembly function for it and add it to the library.
Grumble
Thank you, I'm not into assembly anymore, so maybe I can use some help later on!
I was thinking about using the next frequencies:
1 300 Hz
2 445 Hz
3 600 Hz
4 775 Hz
5 910 Hz
6 1060 Hz
7 1200 Hz
8 1530 Hz
9 1800 Hz
10 2400 Hz
11 2700 Hz
12 3000 Hz
I am in the process of building the filters, so maybe soon I can test it.
screaming goo yo
guest
i see, so youll just throw out half of the bins. i think that should be fine to do a first test. im curious to hear how it sounds, as it will be linearly spaced, making it rather unique in vocoders.

one other thing to consider: the DAC is single sided. it probably doesnt work too well with Vref too close to Vcc or GND (internally it uses transmission gates on the resistor ladder, so its like a bunch of 4066s). this means youll get a lot of CV bleedthrough. you could try sending inverted signals biased to 2.5V to Vref,h an Vref,l. that way the average is always constant at 2.5V.
Synthiq
Shouldn't the VrefL pin be connected to a Vcc/2 voltage to get a 2-quadrant multiplier? Otherwise I think that not just the audio signal but also the dc shift of the input signal will change with the dac setting and cause some serious control signal feed-through.

Some digital volume control ICs have zero crossing detectors and only change gain when the signal is zero to prevent audible steps. Can that be an issue here as well or will the bandpass filters remove these steps?
Grumble
very frustrating made a huge mistake...

Quote:
this means youll get a lot of CV bleedthrough
Yes, because I have the Vref at 2.5 volts angry angry angry
Grumble
Synthiq wrote:
Shouldn't the VrefL pin be connected to a Vcc/2 voltage to get a 2-quadrant multiplier? Otherwise I think that not just the audio signal but also the dc shift of the input signal will change with the dac setting and cause some serious control signal feed-through.

Some digital volume control ICs have zero crossing detectors and only change gain when the signal is zero to prevent audible steps. Can that be an issue here as well or will the bandpass filters remove these steps?

THIS! d'oh!
Synthiq
Oops, I missed the comment from quest above. But there is no problem operating transmission gates close to the supply rails and the on-resistance is actually the lowest there since one of the transistors has the maximum gate voltage then.
Grumble
So here are my thoughts: If I make a top detector of the carrier signal which is a more or less repetitive signal, divide that in half and modulate this DC-ish signal with the carrier signal?
Would that eliminate the DC bleedthrough? What do you think? eek!
guest
you should be fine with either complimentary signals on the Vref pins, or with one of them fixed at 2.5V, as synthiq suggested. either should get rid of the bulk of the bleedthrough. definitely not a show stopper.
Grumble
Do you think VrefL may be higher (=more positive) than VrefH? seriously, i just don't get it

Edit:
the datasheet wrote:
VREFL can be smaller or larger in voltage than VREFH since the DAC design uses fully bidirectional switches

So, that's a YES applause Thank you both, just saved my day Mr. Green
I'll go ahead and connect VrefL to 2.5 volt thumbs up
MUFF WIGGLER Forum Index -> Music Tech DIY Goto page 1, 2  Next [all]
Page 1 of 2
Powered by phpBB © phpBB Group