Vocoder on Bela

lokki the mam vf-11 vocoder, sounds good and seems to be a rather simple vocoder.

One thing you could do that would help "crack the code" on the VF-11 would be a frequency sweep and step response from one of the filter bands. Set it up for filterbank operation and zero all except the 330 Hz band since the spacing on the manual indicates these are all 1/2 octave spaced from 225 to 4700 Hz.

Here is one utility to make a frequency sweep easy (but use whatever tool you want if you know of others)
https://github.com/transmogrifox/Bela_Misc/tree/master/frequency_sweep

I would recommend testing one of the filter bands between 200 Hz and 500 Hz, set sweep range to 20 Hz to 2 kHz. Slow the sweep time to a couple minutes and set size to 1000 (this is the bin resolution). It is such a crude utility you will have to set the sweep parameters in the freq_resp_anal.h and re-compile (which is easy on Bela)

Step response: Drive the input with a square wave (low enough frequency that the filter response is settled before it changes again). If you have an oscilloscope, that is a great way to capture it, but if not you can output to a computer sound card and record with Audacity, or use Bela to log to a test file.

Post an image or text or wav/mp3 files full of the measured data.

If you do that much I will try to design a filter to match the VF-1 filter response characteristic.

lokki will do, it could be a couple of weeks before i get to it

No hurry. This is all for fun and education

lokki 100 (50-190), 225, 330, 470, 700, 1030, 1500, 2280, 3300, 4700, 9000(6800-12700)

In the current code these can be manually assigned as my prior instructions suggested. Q = fc/BW. The main interest in frequency sweep and/or step response data is to get an estimate of filter order used.

matt but when you do that make sure the pulsewidth is set as low as possible, essentially turning the square wave into a pulse train.

@lokki Please use the step response (long pulses)

@matt Here is why I advise against using short pulses: What you say is true in theory, but the impulse response will be coming into your measurement system on the order of microvolts (signal-noise ratio becomes a very big deal). If you jack up the impulse amplitude, then you drive the system nonlinear and then the assumption of an LTI system is no longer a valid approximation. If you amplify the output then you amplify the noise with it so both your system and post-amplification needs to have noise amplitude < a few microvolts. I tried this on a Crybaby circuit and convinced myself you just can't win this way without expensive test equipment. That is why the Vector Network Analyzer was invented -- it is a practical measurement method that is largely immune to noise . It is expensive test equipment. In the absence of a VNA, the next best thing is a step response.

A step response overcomes the the signal/noise challenge by injecting energy into the system over a longer period of time rather than impractically high amplitudes (e.g. 44.1 kV). The response has enough power to give you acceptable signal-to-noise ratio in the measurement system. With a step response you still get all the information you need about the system in a relatively tidy package, that is,

M(s) = U(s)*H(s) = (1/s)*H(s)

M(s) : Measured signal input
U(s) : Unit step response
H(s) : System being characterized

Hence,

H(s) = s*(1/s)*H(s)

where convolution with "s" is the time-domain derivative

The impulse response is therefore the time-domain derivative of the step response in an LTI system. The main advantage is you get (1/Tpulse) more signal power than what the approximated impulse dumps into the system. It is not difficult for post-processing because you can apply the bilinear transform of 1/s for a band-limited stable derivative function. Executing the derivative (or band-limited difference) in the time domain side-steps additional FFT windowing considerations for the step response (the bilinear transform becomes the windowing function, which has a good match to continuous time systems up to Fs/6).

I would still recommend doing a step response because you will get significantly better signal/noise ratio in the measurement than you will get from approximating the impulse response with narrow pulse width. It is true that after the derivative is applied, you end up with the same small amplitudes you would get from the impulse response (these are mathematical equivalents). The difference is you're starting with a signal that is lower SNR, and not adding significant noise in the derivative function (quantization & truncation error of a 32-bit FPU).

matt using the zero delay feedback method which may increase the efficiency of your vocoder

I haven't dug very deep into the zero-delay feedback method, much but I'm looking forward to when you upload the code. In the mean time would you post a short snippet of the filter difference equation that gets computed every cycle?

Right now I have a clear vision for how to get the current biquad implemention down to this:
4 MUL, 3 ADD

If a ZDF implementation can knock off another MUL, then score

However, I think my main efficiency drag is the whole program structure, in how functions are called and how coefficients are accessed from memory and less due to FPU cycles.

For example, CPU usage with 8 samples per block goes from 48% (all-on) down to about 33% when I disable ONLY the envelope detectors (all 32 biquads still running) -- I clearly have some work to do on the EVD section. CPU usage split is about 1/2 biquads, and 1/2 EVD right now.

@matt Thanks for the teaser . This stuff will be really useful for refactoring my envelope filter SVF. I 2x oversampled the naive chamberlin SVF to overcome the stability problem, but the ZDF approach will definitely reduce CPU usage on that one.

Based on Oliver's code, I see 7 MUL, 4 ADD, 3 SUB, which is going the opposite direction I need to go. This is efficient when you want to have arbitrary access to any or all of the 3 outputs of the biquad structure, but that isn't needed in a vocoder.

Here's a bonus for what I have come up with for the envelope detector to improve efficiency in the EVD section:

//
// Lazy RMS detector
//  Inputs:
//  sz = processing block size
//  x = input signal (typically AC waveform)
//  y = detector state variable (current RMS measurement)
//  k = integration time constant, typically (1/RC)*(1/Fs)
//
void
lazy_rms_detector_tick(int sz, float *x, float *y, float k)
{
    int i = 0;
    for(i=0; i < sz; i++)
    {
        y[i] += k*(x[i]*x[i] - y[i]*y[i]); // Forward Euler integration, resolves to sqrt((1/k)*integral(x*x))
    }
}

It gives me sqrt() function and averaging in a single shot with 3 MUL, 1 ADD, 1 SUB

The basic principle is that in an envelope detector you already want a slow/averaged response. Time required for this algorithm to resolve on sqrt(x) can be tuned with constant "k". I call it a "lazy" RMS detector because it lazily iterates the sqrt() solver at audio sample rate and "gets there when it gets there".

The time to resolve represent the desired averaging (attack/release times).


Below we see slow time constants for low signal amplitudes and fast time constants for large signal amplitudes (exaggerated here to demonstrate the effect). Would use longer time constants in a real application to reduce ripple. A second-stage smoothing filter might also be a good idea.

matt My envelope detectors use SVFs and a rectifier (absolute value)

I made an analog envelope filter about 12 years ago (has it really been that long?) that was using an SVF with a pot to control resonance and FC on the detector, and as you pointed out -- some interesting results in the control signal.

As a side-note the lazy RMS detector could be increased to a second-order response if you purposely wanted to add the oscillatory response to it. This would be just one more MAC (so 4 instead of 7 from SVF). I developed this detector structure using analog circuit design techniques, prototyping it in LTSpice. I digitized using both bilinear transform and forward Euler integration, and found forward and/or Euler worked well enough that the extra CPU cycles required to realize the BLT structure weren't justified (step responses look identical and you only see a difference as you approach the stability limits). As would be expected, the BLT version is much better behaved near instability, but instability happens at fast enough convergence times to be impractical for its intended function -- so the practical use of the circuit automatically dictates that it does not operate near instability.

On the topic of more "interesting" envelope detectors, this one was inspired by a design by Harry Bissel (link and information in comments in source code):
https://github.com/transmogrifox/Bela_Misc/blob/master/vocoder/envelope_detector.cpp

I assume you're still working on your own Vocoder -- I'm definitely interested in seeing that when you are done. These things are just a lot of fun