Another great one, thanks for sharing!
Are you stacking your collection of effects in series?
Dynamic Range Compressor
- Edited
giuliomoro Are you stacking your collection of effects in series?
Yes. I am working on a much more complex system in which I have multiple guitar effects in series under a single project. I occasionally break out these individuals because I think of them as being potentially useful for more than only guitar players.
This also highlights a pretty broad scope of "how-to" for using Bela -- working code is always helpful to me, so maybe this stuff can be helpful to somebody else. Main highlights:
Filtering inputs from pots
A way to detect changes in the pot position so you aren't perpetually updating parameters, and for multi-funciton use of a single analog input.
A method for de-interleaving audio inputs for block processing.
Not least of all, one way to do dynamic range compression.
- Edited
[UPDATE]
Deleted text here and updated original post to include improvements.
- Edited
math-neon wins the prize! It looks like this implementation of expf() only takes about 1.5x CPU time as a single floating point multiply.
I was originally hesitant to use this thinking expf() was going to be computationally expensive and figured it wouldn't make an audible difference, but I was wrong on both counts. It's computationally cheap and makes a very significant difference in the sound.
Once I implemented this I started hearing a sound that really brought to mind the sound of a Dynacomp, only on Bela you don't have to mess around with that bias trimmer.
Of course, my discovery that e-x with math-neon is little more than a multiply, it makes implementation of a traditional feed-forward compressor trivial...although my feedback compressor performs well enough I'm not seeing a need for yet another compressor.
Now this compressor has added features:
Linear feedback gain mode (the original design)
Exponential feedback gain mode ( approximately log-linear transfer function)
Parallel compression (wet/dry mix)
Check it out if you like compressors like I do. I'm a compressor nerd (in case it isn't self-evident).
These can sound really cool on drums and percussion instruments. I have added enough parameterized control it's not only a guitar effect any more.
Yeah from the measurements I made back then expf_neon
was 5.5 times faster than expf
and still remarkably precise, so good news that it has been put to good use!
giuliomoro I was able to reproduce a similar result with my test program. I did the comparison between the two expf() functions just to sanity check my own benchmark so I could believe the results of comparison to a multiply.
It might be a good addition to the math-neon benchmark wiki page to add a benchmark section for floating point multiplication, addition and subtraction as some reference points for comparison.
ryjobil It might be a good addition to the math-neon benchmark wiki page to add a benchmark section for floating point multiplication, addition and subtraction as some reference points for comparison.
Also division could help, I guess, as that is probably very very slow (no hardware division on this NEON unit).
- Edited
giuliomoro no hardware division on this NEON unit
//Perform division
// a/b
a*expf(-logf(b));
Or probably even faster:
den = invsqrtf_neon(b);
den *= den;
ans = a*den;
It would make me laugh if the neon FPU w/ fast math lib can do those faster than
a/b
Bump. I added some more plots to the original post to capture the exponential feedback mode.
Updated the block diagram to more completely capture the functions that have been implemented.
Wow, thanks for the contribution, really!
I don't have a bela board yet, which means I can't test it or tell how much load on the chip a stereo instance would cause. Anyone?
chrion Wow, thanks for the contribution, really!
It's always encouraging to see somebody interested. Makes the sharing more fun
One instance uses about 2% CPU time. Not a big deal to add several instances. Below is how I come up with 2% CPU usage.
Comparing the CPU with (mono) compressor active, then bypassed, I get the following at 8 audio frames per block:
active: 25.4 % CPU, realtime
bypass: 23.3 % CPU, realtime
Compressor CPU Usage: 2.1% per channel
It takes about 23% CPU just for Bela to process the ADC inputs and perform basic pass-through, so the compressor benchmark is based upon additional CPU needed when the compressor is active.
My interest in making CPU usage minimum is because I want this basic block to be easily implemented when a lot of instances are used, such as multi-channel and/or multi-band compression. There was never any concern that a few instances of the compressor would be a problem on Bela.
Those numbers sound fantastic to me. But man! 23% gone at the get go? My goal is to make a MPC2000XL type of sampler, I hope the BBB holds up. If only the BBB had the power of a Rpi4...the possibilities would almost be endless. Especially really nice looking GUIs
chrion 23% gone at the get
That may be an old figure and also a bit excessive. I think a more accurate and recent one is 12% with a block size of 16 and 6% with a blocksize of 128 (with --high-performance-mode
enabled)
- Edited
giuliomoro That may be an old figure and also a bit excessive.
Yes, I have not updated software on my BBB for 2 years. Any improvements made since then would not be reflected in that figure. Also the sketch was scanning and filtering the ADC inputs looking for control set-point changes. That may have been worth a few percent, so this figure does exaggerate the performance hit.
giuliomoro 12% with a block size of 16
16% with block size of 8 on my PocketBeagle (Bela Mini) which has more recent software, running the audio and analog pass-through example. No measurable change when analog channel pass-through is commented out.
I do believe the 2% figure for the compressor remains valid.