New Zynthian lv2-plugin: AutoLeveler

Software
1

EDIT on 27/08/2025:

Here is my first zynthian plugin:

AutoLeveler (lv2 headless, v0.1.2beta)

It is an automatic downleveller sitting on a chain or the master chain. You set the peak and RMS threshold in dBfs, if the output exceeds that threshold it smoothly downlevels the output.

AutoLeveller_GUI
AutoLeveller_GUI755Ă—483 56.9 KB

Why:

It can have two purposes: It may work as a security downleveller if anything before the chain pushes the volume in unhealthy manners (eg. on the master chain). The main purpose is to put it on every chain in your snapshot for equaling the outputs of very silent marimba soundfonts and very loud square wave synth leads alike. It processes peak and rms measurements.

How to use:

It features four controls:

  • Pre Gain (dBfs)
    Adjust the pre amplification in case you deal with quieter sources (like soundfonts) you want to boost before getting into the automatic levelling.
  • Theshold Peak (dBfs)
    Set your maximum peak levels you want to have. Setting the threshold will reset your former gain reduction so it can listen from the start again. When “Listen” is on, it will only turn the volume downwards. Recommended values are between 0 and -4 dBfs.
  • Theshold RMS (dBfs)
    Set your maximum RMS levels you want to have. Setting the threshold will reset your former gain reduction so it can listen from the start again. When “Listen” is on, it will only turn the volume downwards. The detector is estimating RMS values of a 300ms window by a using a lowpass filter. Recommended values are between -14 and -18 dBfs.
  • Listen (bool)
    When engaged (by default) it will perform detection and level matching. When disengaged it will keep the current gain, but will not further listen. If engaged again, the gain reduction will be reset.

You can think of it as your angry sound engineer in a live situation, both during soundcheck and during the gig. Initially it will turn your output volume down to a reasonable level. It will also do that if anything unforseen happens in the chain (you add another plugin which features an integer gain multiplier and is set to gain=20). When set the right values (try the preset “Tuned”) it should level any source to a loudness level somewhere into yellow meter territory.

It also features two programs:

  • Init: All set to zero. It will not perform anything unless your level is above 0 dBfs, which is always bad.
  • Tuned: Set the parameters to reasonable values: Pre Gain will boost the signal by +6 dB to compensate quiet engines like soundfonts, peak threshold is set to -4 dBfs and RMS to -18 dBFS to keep more or less transient heavy signals somewhere in yellow area of your mixer.

How is it working / Signal chain

Signal chain is like this: Pregain → Detector → Apply AutoGain → Calculate overshoots and set post gain processor.

During calculation it will chose the lower value of Peak/RMS detector and will only apply it in case the volume gets turned down. The Pre Gain features a parameter smoothing of 1000 samples (typically about 20 ms), the autogain processor uses 10000 samples (about 200 ms).

Why does it reduce the volume when I play expressive notes? Will it mess with my dynamics when performing live?

Zynthian is technically a DSP plugin host. In the digital domain you should keep peaks always below 0 dBfs, because digital clipping is very nasty sounding. You should anyhow keep the peak threshold near 0dBfs to not produce too quiet signals. The goal is to keep chain output level somewhere in the yellow meter territory for all the chains.

It will not mess with your dynamics. After automatically turning down the volume it will not do anything to your signal. If you’re scared it will interfere with your live situation, you have several options:

  • After inserting it you just bang the loudest note already
  • If you worry about aprupt peak levels just only use the RMS detector
  • If you’re still scared, turn the listening parameter off, so it will keep the current level.

Why not using a Limiter/Compressor?

The limiter/compressor is intended to keep or raise perseived loudness by reducing the peak levels. It will therefore mess with your dynamics. This plugin is actually an automatic gain plugin. After detecting and altering the gain it should do nothing but keeping a reasonable post gain value. A safety limiter at the end of the master chain is a good idea anyway.

What about xruns, popping noises when plugin in my guitar cable, loud transients of other heritage lowering my volume?

These kind of noises should be prevented anyway in the first place when performing live or in rehearsals. Xruns shouldn’t trigger loud traisients anyway because the nasty noise is high frequent spike produced by a a non zero signal immediatly going to zero.

I have a mixing guy/gal. Does it replace him/her?

No, it’s not intended to do that. He or she is a fundamental aspect of leveling your band. The plugin is only intended to send reasonable output to FOH/In ear monitoring/your home studio speakers for further processing. Ready made electric pianos / synths / keyboard extenders might or at least should try to level match their presets. In an open source project like Zynthian is with its variety of open source engines you cannot guarantee that.

Why doesn’t it recover the level in case you have quieter signals?

Automatic upward gain compensation can be risky. It needs to constantly listen and apply upward leveling in smart ways even if you just don’t play at the moment. The plugin choses safety over convenience in that regard. If you want to recover loudness, just turn any threshold parameter or turn the listen parameter from off to on.

I don’t trust that thing because I don’t know what it does

Check the source code linked below. It just does what is written in the main code and the two member functions you’ll find in the #include statements.

What’s next?

The plugin might stay in the current state because for me at least it succeeds in providing the functionality for the intended use case. If worries about one sample peaks remain in practical use the peak detector might get a short detector window instead of looking at every sample.

Binaries and source

When using self coded plugins of dumbasses like me always use with care, turn down volume, use your regular safety routines or check the source code if screwed up in the first place.

Download here (v0.1.2 from 27/08/2025)

  • Extract to /usr/lib/lv2
  • update plugin and preset database from webconf
  • reboot

or

  • use version from zynthian repostory

Finally

I’ll not convince anybody to use it. But for me it is useful and I had some fun getting into coding again. So in cases…

  • you like it
  • you like it but have ideas to improve it
  • you don’t like it because you have ideas to improve it
  • you don’t like it but want to encourage changes to improve it anyway

… I’m open for any suggestions.

7 Likes
Correct ouput level in snapshots
LV2 components I'd like to see
2

I added the listening parameter and leave this by now. You can turn the listening param off if you don’t currently want the plugin to listen and downlevel the volume, turning it on again resets the level and restarts the listening process.

(Deleted link because newest version is in first post)

1 Like
3

Hi @hannesmenzel !!

I would like to include your plugin in the zynthian collection.
Having a separated repository with binary releases in zip format will help with maintainance,

Thanks!

1 Like
4

Great!

How would you think maintance would be working? Will you just include the binaries in a zynthian repo? Source code is also online, but unfortunately I have all the plugin stuff in one repository because some time ago I opted out having the dsp code as submodules.

Things to consider would be to settle the choice of parameters before including it so that it doesn’t screw up peoples snapshots. I thought about deleting the pan parameter because it doesn’t make so much sense in thst kind of plugin. Benefit would be also to have 4 parameters fitting one page. Otherwise it would be possible to have user defined RMS window and gain smoothing time.

Also I have a current version with 2 programs (“Init” with thesholds at 0 dBfs and “Tuned” with some pregain and some recommended theesholds)

What do you think?

5

For the moment, i can keep a copy of your zip file with the binaries in the pre-built plugins repo.
for the future, the easier for us would be you release zip files with the binaries in your git repo, so we can download from there directly. Not in a hurry.

BTW, the autoleveler is in vangelis :wink:

Thanks … and congrats for your plugin! It works fine!

1 Like
6

This is not easy to implement. The only way would be having a set of “presets” you can choose when inserting the plugin.

  • 1 to remove pan parameter. Less is more. Having a single parameter screen is a point.

I’m not sure this could be very useful, but you could put these 2 parameters in the second screen, moving the pregain to the first one.

Regards,

2 Likes
7

I only meant compiling the final state with 4 params, then publishing.

8

Hi @hannesmenzel,

Does AutoLeveler have any practical use besides being an exercise in creating an LV2 plugin?

I mean, what is the advantage above using a limiter?

I tried AutoLeveler. If I accidentally hit a key too hard, the volume is permanently turned down, so that the softer notes are not audible later. A limiter only suppresses the louder tone.

With all due respect, I don’t really see a practical application but maybe I’m not experienced enough.

Kind regards,

Hans.

9

Hello @HansR,

the practical use for people may vary. For me it is dealing with surprises introduced by engines and presets with very differing output volumes. You have synthesizers which always aim at 0 dBfs, you have soundfonts which peak to -25dBfs, and you have many effect plugins with linear gain multipliers as integer values (gain =* 0, 1, 2 … 20).

Zynthian is the coolest electronic musical instrument I can imagine, but due to its variety of engines it’s also a bit dangerous toy. When you rehearse or even gig with in ear monitoring, other people in the room can get very mad at you when switching from a quiet to a loud engine. And after everybody turned you down in their in ear mixes you get back to your marimba samples and nobody’s hearing you.

What’s the advantage over a limiter/compressor: these kind of plugins aim to preserve the perceived loudness and lower the peaks only. If you have a way to loud signal, you afterwards have a way to loud signal with its peaks cut off. They therefore also alter the signal. The downleveling for louder tones without the release is the intended funcionality. It is intended that chains level match at a certain peak&rms loudness.

Practical example: add two chains: one synth saw lead, one marimba sample. Put the AutoLeveler behind both and put the same reasonable values (pre +6, peak -4, rms -18). They should come out level matched (also in perceived loudness).

Btw.: using one of the thresh knobs or the listen knob resets the down leveling.

3 Likes
10

Hi @hannesmenzel

Thanks for the explanation, that is indeed a useful practical application.

Kind regards,

Hans

1 Like
11

When I use different chains, I always normalize the volume before saving the snapshot, it feels like a good practise,

Best
Pau

12

Reasonable question raised anyway. That kind of plugin was missing at least for me. In rehearsals I had always chains with Pianoteq, sfizz and a TAL UNO loaded with ridiculous mixing levels turned down up to max/ down to almost bottom line. And even then changing feom a pad to a lead sound… But it’s also a coding exercise.

I think it is good practise. I just had some finetuning issues when my mixing levels were +6; -6; -18 dB only for initial level matching and no room to get on. It’s now one of the other 893 engines.

1 Like
13

My main problem with an autoleveller is that when we are performing live it would definitely affect the performance “levelling” all the dynamics. Probably fine for other uses :slight_smile:

14

Interesting point. Not messing with the dynamics in a live performance was the main reason I did that plugin. When volume is settled it aims to have the chain at a reasonable level without touching the dynamics. And I mean, we are talking about some dBFS (means full scale). So otherwise the expressive notes you may have in mind will just digitally clip.

So the idea is that any chain settles in a user defined area, for me: sowhere into yellow meter territory. I try to figure out your issues with it. Maybe the purpose is that the plugin performs the gigs soundcheck (“play the loudest you would” “1, 2, 1, 2”) and is the angry mixing guy leveling you down when you secretly turn up your amp.

Furthermore: There is a listen parameter. When turned off, it will keep the adjusted volume and doesn’t listen for peaks anymore. It’s like firing the angry mixing guy.

Maybe we should rename the plugin to AngryMixingEngeneer.lv2

By the way, I’m open for suggestions.

1 Like
15

It looks like the plugin reacts to single samples that are over the threshold. This may result in false results, reacting to transient, inaudible peaks. You may wish to consider some averaging so that only persistent and audible peaks are detected. Without that, you can end up with instruments that sound very quiet because they happened to trigger the limiter for one sample. Xruns may also trigger such transients.

Regarding naming…I interpret this as a hard limiter without reset / release. In the words of Engelbert Humperdinck, “Please release me, let me go…”. But something more descriptive may be, “Single-shot hard limiter”. All rather wordy though!

I suspect this plugin may trigger when not desired and I am likely to not use it, instead auditioning and leveling sounds before usage. Keyboardists are not the only ones to make loud unexpected sounds in rehearsals. I am looking at you lead guitarist and drummer with your impromptu jamming whilst the rest of us are trying to work on a song or plugging guitar into an amp when it is at full volume… buzz, crack, bloody hell!

16

The peak threshold detector does, yes. The RMS threshold reacts to an envelope mimicing a rms detection of 300 ms. The idea is to set the peak detector only a few db below full scale so it levels down if peaks are near 0 dBfs. It may be suitable to have a very small detector window for these as well (10 samples or so).

I assume xruns don’t produce transient overshoots normally. They sound nasty though because non zero signal gets zero immediately, hence the high frequency clicks. I don’t know if xruns are a factor, they should be avoided in live use in the first place anyway. When you rehease with inear monitoring like I do, you really try to avoid xruns and loud clicks and pops of other heritage at all costs.

I read thorugh all the remarks and try to get things helpful for continuing that plugin. I don’t think it should make signals very quiet if used like I had it in mind. Zynthian is technically a host for dsp processing. In DSP you should keep an eye on peaks exceeding 0dBfs anyway, because at least after the last stage they’ll produce digital clipping. I intend to not let this plugin pass peaks above -3 dBFS, that is what it was made for. I tried it with varying sources (transient heavy vs “tail” heavy, synths, drums, strings, pianos, of course marimbas) and it pretty much worked to get consistant preceived loudness across all of them, which is achieved by setting reasonable peak and rms values (try -4, -18) and give every instrument a reasonable amount of pre gain.

Thats fair. I had some fun coding it and will probably use it.

I think I try to get a better description in the first post.

2 Likes
17

How about EarSaver.lv2?

18

Again in my case, we have a mixing guy :slight_smile: He’s the one that needs all the chains properly levelled to avoid different volumes in different chains. I see the point of your work but I don’t think I’d dare to use it in a live performance, we already have compressors, gates and all the tools of a mixing station.

But this is my particular case, I do appreciate your work and see the use in other cases :slight_smile:

Thanks for your contribution, it’s really appreciated!

Pau

19

Hi, I just compiled another version:

  • Updated the description in the first post of the thread to make things clearer.
  • Deleted pan parameter (not that important in that kind of plugin and also reduces parameter count four, one single page)
  • @jofemodo: There is a new binary which may mark the final state linked to the release page in the first post. Let me know if it would better suited just inside the repositories tree.
  • Last remark: I do enjoy the discussions with all of you. I’m open for any suggestions.
1 Like
20

Updated!

1 Like