question.
i'm mixing together a variable number of soundfiles (between 1 to 12 files), which makes my output volume swing considerably. so i would like to add some safety against digital clipping on my DAC.

what i'm doing now is i'm already scaling down the total sum by a fixed amount (/3), but i would like to add some compression/limiting for glueing the sound together as well as preventing artefacts.
i tried [zexy/limiter~] in compression mode, which works great as a compressor (at least when i put in the prescale divider), but it doesn't seem to catch the full spectrum - i still get some peaks going over -1/+1.
i guess i could add another [limiter~] in peak limiter mode, but that would increase both latency (minor issue, it adds about 3ms lookahead) and CPU, on which it is pretty heavy.

since i gather i can't be the first to need an end limiter.. anybody got any magic pointers?

and on that note, anybody succeeded in using [Vst~] on Bela?
there may be no need to reinvent the wheel.. 🙂

    Remork and on that note, anybody succeeded in using [Vst~] on Bela?

    IIRC that hosts vst2 plugins, so you'd need the vst2 SDK which has been discontinued and removed from public availability by Steinberg to force everyone to move to vst3 (see, the importance of free software?). Even having it, you'd then need to rebuild your vst plugin for ARM, which may be a problem, too...

    I have used FAUST's limiter before. It's easy to turn FAUST code into a Pd object with faust2puredata.
    For instance:
    - install FAUST on your computer
    - create a limiter.dsp file containing:

    declare name "limiter";
import("stdfaust.lib");
process = _ : co.limiter_1176_R4_mono : _;

    - execute on your computer:

    faust2puredata limiter.dsp

    This will create a pd external for you computer architecture in the current folder. Move it where Pd can see it and you can start using it on Pd on your computer.
    - execute on your computer:

    faust2puredata -tosource limiter.dsp

    This generates a source .cpp file that you can use to build it on Bela. It will output a line like this:

     faust.zt7cdV/limiter/limiter.cpp

    (where the first part will change every time).
    - copy that file to Bela:

    scp faust.zt7cdV/limiter/limiter.cpp root@bela.local:

    - get on Bela and build the file into a Pd external:

    clang++ -std=c++11 -O3 -mtune=cortex-a8 -mfloat-abi=hard  -ftree-vectorize -ffast-math  -I /usr/local/include/libpd/ -fPIC -shared -Dmydsp=limiter -o limiter~.pd_linux limiter.cpp

    - move the external to the pd-externals folder:

    mkdir -p /root/Bela/projects/pd-externals
mv limiter~.pd_linux /root/Bela/projects/pd-externals

    - now you can use the [limiter~] object on Bela

    FAUST-created objects will have one control inlet and one control outlet (the leftmost ones), all other inlets/outlets are input and output signals of the FAUST dsp.

    In this case, this line:

    process = _ : co.limiter_1176_R4_mono : _;

    means one input _ goes into co.limiter_1176_R4_mono, whose output goes to one output _.

    So the resulting external will have two inlets, two outlets. The signal inlet/outlet are the rightmost ones. Just connect your to-be-limited signal through those:

            [+~]
         |
[limiter~]
         |
     [dac~]

    BONUS STEP: add controls

    There are no parameters to be changed for this effect. Digging into FAUST's compressors.lib you'd see that limiter_1176_R4_mono is declared as:

    limiter_1176_R4_mono = compressor_mono(4,-6,0.0008,0.5);

    and compressor_mono's arguments are: compressor_mono(ratio, threshold, attack, release)

    So, the object you just built will be a monophonic compressor with ratio 4, threshold -6dB, very short attack time (0.8ms) and lengthy (0.5s) release time.

    If you want to adjust those parameters at runtime, you can edit your limiter.dsp to look like this:

    declare name "limiter";
import("stdfaust.lib");

ratio = hslider("ratio", 4, 1, 20, 0.1);
threshold = hslider("threshold", -6, -80, 0, 0.1);
attack = hslider("attack", 0.0008, 0.0001, 1, 0.0001);
release = hslider("release", 0.5, 0.0001, 1, 0.0001);
process = _ : co.compressor_mono(ratio, threshold, attack, release) : _;

    hslider is a FAUST GUI object. It doesn't actually mean you are going to see a GUI on the Pd object, but it's a convenience method to expose parameters. The numbers that follow the "label" are: initial value, minimum value, max value, step. As the default values are the same as for the the code above will by default generate a limiter with the same parameters as the limiter_1176_R4_mono, the above code will behave the same as the previous one out of the box. However, you can now change the default parameters.

    Repeat the procedure above to rebuild the object on your computer and on Bela (you have to restart Pd on your computer to force it to load the new limiter~ object).

    Now if you bang the leftmost inlet and connect a print on the leftmost outlet you will get something like this in the Pd console:

    print: hslider /limiter/attack 0.0008 0.0008 0.0001 1 0.0001
print: hslider /limiter/ratio 4 4 1 20 0.1
print: hslider /limiter/release 0.5 0.5 0.0001 1 0.0001
print: hslider /limiter/threshold -6 -6 -80 0 0.1

    that shows you the parameters available internally. Now, you can send a message to the leftmost inlet to change, e.g.: the attack time:

    [attack 0.5(
|
[limiter~]
|
[print]

    bang the first inlet again and the dump will have changed:

    print: hslider /limiter/attack 0.5 0.0008 0.0001 1 0.0001
print: hslider /limiter/ratio 4 4 1 20 0.1
print: hslider /limiter/release 0.5 0.5 0.0001 1 0.0001
print: hslider /limiter/threshold -6 -6 -80 0 0.1

    (note the first value after attack is now 0.5.

    Hope this helps.

      Remork wow, that's a bit more involved than i thought 🙂

      I can just share the pre-built external for Bela, and possibly one for your computer, too, if you are on MacOS or Linux (this is not strictly needed: you could just use a dummy pass-through abstraction with 2 ins and 2 outs while patching on you computer).

          @Remork I also amended the previous post to include some optimisations in the build of the external on Bela, to make it more CPU-efficient

          giuliomoro if you are on MacOS or Linux

          i'm on MacOS 10.12 here. pre-built external would be greatly appreciated!

            How important is the quality of the limiter? For example, would it be acceptable to follow up a compressor with soft clipping? A compressor with short attack time will overshoot its bounds momentarily, but depending on the source material sometimes it may not be as easy to discern its effect as the hard clipping that occurs from numerical saturation.

            Another way to help reduce peaks is with pre-emphasis and post-emphasis filtering. A certain amount of high-boost ahead of the compressor causes it to peak detect more frequently and then a post-emphasis low-pass filter further reduces the amplitude of the end signal. If you clip prior to the de-emphasis low-pass filter then clipping artifacts will be even less discernable.

            Just some ideas.

              thank you both!
              giuliomoro downloaded, will try!

              ryjobil ideally, i would like to keep my audio as clean as possible.
              soft clipping might be an option, if i can figure out a way to visually monitor when the clipping is happening so i can back off a little when needed. (is there a way to implement soft clipping in pd?)
              but in a perfect world, pushing volume beyond a certain limit would only cause more compression, not distortion. where a visual indicator like a flickering led might still be useful, come to think of it.

              hadn't thought of pre- and post-emphasis, definitely a route to check.

              i also came across this one:
              https://cdm.link/2013/12/free-open-source-compressor-built-pd-perfect-mobile/

              haven't tried it on Bela, but on laptop the results were very similar to the zexy one. might swap them to see which one eats most CPU.

                  5 days later

                  well. the faust limiter linked above does a more than decent job. it doesn't seem to introduce any delay at all, which is impressive. but since it obviously doesn't use any lookahead, it still allows for some clipping peaks.
                  in practice, the material i'm using is probably moving slow enough to use this one without too much clipping or artefacts. but it's not really 100% bulletproof, unless i really lower the volume going into the limiter. which is sort of against the point.

                  when scoped, the only one to actually catch each and every single peak turns out to be the [zexy/limiter~].
                  in Compression mode, you can set the usual threshold, ratio, hold and release times - and on top of that it has an absolute maximum limit it never exceeds, like a bonus brick wall limiter/ducker. (if you set that limit to anything over 100dB, everything goes haywire, even though it's specified that it should be possible. guess that's why i was still getting peaks exceeding +1/-1 before.)
                  now i have it set to 99dB and this thing never clips, no matter what i throw at it (tried up to +5/-5 peaks). obviously, if you drive it way too hard it will start pumping because of the ducking thing, but i prefer pumping to clipping for my worst case scenario.

                  right now i have it set to very modest compression, a very high threshold, a long release, to ease it into the limiting. that does glue everything together rather nicely.

                  it's a bit heavier on CPU than the Faust one, and it does introduce some latency (a 64 sample delay, which i can live with), but it still is the limiter of choice.