x42 / dpl.lv2

Digital Peak Limiter LV2 Plugin

dpl.lv2 - Digital Peak Limiter

dpl.lv2 is a look-ahead digital peak limiter intended but not limited to the final step of mastering or mixing.

It is available as LV2 plugin and standalone JACK-application.

Usage

The Plugin has three controls which can be operated by mouse-drag and the scroll-wheel. Holding the Ctrl key allows for fine-grained control when dragging or using the mouse-wheel on a knob.

Furthermore the UI offers

• Shift + click: reset to default
• Right-click on knob: toggle current value with default, 2nd click restore.

The rotary knobs from left to right allow to set

• Input gain. This sets the gain applied before peak detection or any other processing. Range is -10 to +30 dB in steps of 0.2 dB.

• Threshold. The maximum sample value at the output. -10 to 0 dB in steps of 0.1 dB. dpl.lv2 will not allow a single sample above this level.

• Release time. This can be set from 1 ms to 1 second. Note that dpl.lv2 allows short release times even on signals that contain high level low frequency signals. Any gain reduction caused by those will have an automatically extended hold time in order to avoid the limiter following the shape of the waveform and create excessive distortion. Short superimposed peaks will still have the release time as set by this control.

Install

Compiling dpl.lv2 requires the LV2 SDK, jack-headers, gnu-make, a c++-compiler, libpango, libcairo and openGL (sometimes called: glu, glx, mesa).

  git clone https://github.com/x42/dpl.lv2.git
  cd dpl.lv2
  make submodules
  make
  sudo make install PREFIX=/usr

Note to packagers: the Makefile honors PREFIX and DESTDIR variables as well as CXXFLAGS, LDFLAGS and OPTIMIZATIONS (additions to CXXFLAGS), also see the first 10 lines of the Makefile. You really want to package the superset of x42-plugins.

Screenshots

Credits

dpl.lv2 is based on zita-jacktools-1.0.0 by Fons Adriaensen.

dpl.lv2's Issues

Automating x42-dpl stalls Ardour's Transport

It seems than whenever x42-dpl encounters an automation change, Ardour's transport is stalled and can't move. The only solution I found is to manually grab and move the automation point back or forward - then sometimes Ardour will resume.
Sometimes this stalling also results in Ardour freezing and crashing with a segfault.

Removing the automation data for the x42-dpl instance removes the issue completely.

First I only automated the "Enable" parameter to bypass the effect.
Then I tried to imitate the same result automating Gain and Threshold controls to identical effect; Ardour playhead gets stuck on the first automation point that has anything to do with x42-dpl.

GR meter and inline display have a fixed release time

The inline display would be a lot more useful to me if it would show the actual GR, using the actual (automatically varied) release time.
Currently it seems to use a fixed, relatively long release.

Why not just use the value that is sent to the display in the plugin window; why calculate a separate release, reducing the usefulness and presumably increasing the DSP load a tiny bit?

Fails to load in Audacity

Tried this in Audacity ver 2.4.2 but wont load:

ASSERT INFO:
../src/common/wincmn.cpp(477): assert "GetEventHandler() == this" failed in ~wxWindowBase(): any pushed event handlers must have been removed

BACKTRACE:
[1] wxWindowBase::~wxWindowBase()
[2] EffectPanel::~EffectPanel()
[3] wxWindowBase::Destroy()
[4] EffectUIHost::Initialize()
[5] EffectUI::DialogFactory(wxWindow&, EffectHostInterface*, EffectUIClientInterface*)
[6] LV2Effect::ShowInterface(wxWindow&, std::function<wxDialog* (wxWindow&, EffectHostInterface*, EffectUIClientInterface*)> const&, bool)
[7] Effect::DoEffect(double, TrackList*, TrackFactory*, NotifyingSelectedRegion&, wxWindow*, std::function<wxDialog* (wxWindow&, EffectHostInterface*, EffectUIClientInterface*)> const&)
[8] EffectUI::DoEffect(wxString const&, CommandContext const&, unsigned int)
[9] CommandManager::HandleCommandEntry(AudacityProject&, CommandListEntry const*, std::bitset<64ul>, bool, wxEvent const*)
[10] CommandManager::HandleMenuID(AudacityProject&, int, std::bitset<64ul>, bool)
[11] ProjectWindow::OnMenu(wxCommandEvent&)
[12] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[13] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[14] wxEvtHandler::TryHereOnly(wxEvent&)
[15] wxEvtHandler::DoTryChain(wxEvent&)
[16] wxEvtHandler::ProcessEvent(wxEvent&)
[17] wxWindowBase::TryAfter(wxEvent&)
[18] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[19] wxMenuBase::SendEvent(int, int)
[20] g_closure_invoke
[21] g_signal_emit_valist
[22] g_signal_emit
[23] gtk_widget_activate
[24] gtk_menu_shell_activate_item
[25] g_signal_emit_valist
[26] g_signal_emit
[27] gtk_main_do_event
[28] g_main_context_dispatch
[29] g_main_loop_run
[30] gtk_main
[31] wxGUIEventLoop::DoRun()
[32] wxEventLoopBase::Run()
[33] wxAppConsoleBase::MainLoop()
[34] wxEntry(int&, wchar_t**)
[35] main
[36] __libc_start_main
[37] _start

Interpolate controls to eliminate zipper noise

I'm currently making a video about x42-dpl and I've found that one shouldn't automate the controls if there's signal coming though, or there'll be zipper noise (if you have loud bass, it'll be very noticeable).

Do you think it'd make sense to tackle that?

BTW, I think this is an excellent limiter - simple, sounds great and has a slick, clean UI.

I'm really thankfkul you've made this plug-in, @x42. I've only recently realized it's one of the very best FOSS limiter plug-ins out there. It saves user's time and provides excellent quality.