Show HN: An Open Source Equilizer Plugin | Hacker News Reader

Show HN: An Open Source Equilizer Plugin

github.com

20 pointsashafq6 comments

a5eq.lv2 is a versatile LV2 plugin featuring a high-performance 5-band equalizer, equipped with a Low Shelf, three Peaking Filters, and a High Shelf.

The goal of a5eq.lv2 is to deliver optimized performance on both AMD64 and ARM64 architectures. By leveraging SIMD instructions, the plugin ensures efficient and reliable operation.

As the author of a5eq.lv2, I welcome feature requests and ideas for improvement.

Open articleView on HN

looks like the DSP is using a TDF-2 biquad filter topology. This can have undesirable artifacts in the presence of modulation/automation. Normally that's fine (it's why the classic EQ cookbook formula and design has lasted so long) but in a music application it's inappropriate.

There are a lot of alternatives out there today, the most popular being either the Cytomic or Zavalishin's SVF implementation. You can also use those to deal with cramping near Nyquist without resorting to oversampling.

Also, why limit to five bands? It's 2024, give me an arbitrary number of bands. Otherwise it's not really more useful than the builtins in any DAW.

Thank you for your feedback. You’re absolutely right that TDF-2 can exhibit artifacts in the presence of modulation or automation. In this implementation, I’ve addressed this by crossfading between the old and new coefficient sets. I’m aware of the SVF topology and its advantages, especially in low-precision applications. However, I wanted to experiment with biquads due to their computational efficiency when filters remain steady.

I hadn’t fully realized the extent to which EQ cramping is a concern in the audio community, so I’ll definitely dive deeper into mitigation techniques to address it effectively.

Regarding your point about limiting to five bands, I completely agree: there’s no technical reason to impose this restriction, especially given the abundant memory available on modern desktop systems. I’ll explore a more dynamic architecture to allow for arbitrary numbers of bands.

Thanks again for sharing your insights. They’ve given me a lot to think about as I work on improving this project!

The SVF has the same computational complexity as a TDF2 biquad (as it is after all, a TDF2 biquad). There are more efficient structures than either (eg: state space canonical forms which play nice with common matrix/vector arithmetic). The direct forms are pretty terrible for all but trivial SIMD optimization like interleaving. Depending on a few factors just packing the SIMD lanes for optimized biquads is more expensive than not using SIMD at all on deinterleaved channels.

Direct form 2nd order filters are a dead end in terms of performance and quality for pro audio. I just wanted to point that out, since this space is very well studied and direct forms have pretty notable disadvantages (stability under modulation, overhead of coefficient computation, poor SIMD optimizations, etc).

If I recall correctly, SVFs typically compute lowpass, highpass, and bandpass outputs simultaneously, which are then combined to create peaking or shelving filters. In contrast, a traditional biquad filter requires only five multiply-accumulate instructions. Computationally, SVFs are generally 3 to 5 times more expensive than biquad filters.

When designing this plugin, my primary focus was optimizing steady-state operation. While there are many plugins tailored for handling modulation, this plugin is designed to reject high-frequency modulation, prioritizing efficiency for gradual state changes. This tradeoff allows it to excel in its intended use case without the added complexity or overhead of robust modulation handling.

Feel free to add a feature request in the Github project page. Thanks again for your feedback.

Hi, as a freelance sound engineer: this looks decent. Is a logarithmic plot of the resulting curves out of scope? I always found it quite useful especially in combination with a spectrum analyzer.

Other than that: I found it somewhat confusing that your UI groups parameters by type of control (e.g. all frequencies first) instead of grouping them by EQ:

  Low Shelve
    Frequency
    Gain
    Q
  Bell 1
    Frequency
    Gain
    Q
  Bell 2
    Frequency
    Gain
    Q
  Bell 3
    Frequency
    Gain
    Q
  High Shelve
    Frequency
    Gain
    Q

You appear to have a topmost UI group called "Effect Parameters" maybe it makes sense to utilze these instead to group the EQs — so one of those per band? You could then add an enable button per EQ band as a neat and probably simple to implement feature (especially useful for beginners who haven't developed their ears as they can toggle the band off and on and hear what it is doing).

Other than that I would just miss High and Lowpass filters. Especially HP filters are a thing that are extremely useful for cleaning up mic rumble and unwanted proximity effect, bonus points for variable steepness (6/12/18/24 db/Oct). In my dialog mixing time there wasn't a single channel without a HP on it (except those who already had it baked in of course).

Since you have a L/R stereo mode maybe an alternative Mid/Side mode could be considered as well.

Another question: do you prevent EQ cramping?

Thank you for taking the time to share such detailed feedback. It’s incredibly valuable! Let me address your points one by one:

1. Logarithmic plot and spectrum analyzer: This feature is definitely on my roadmap. I agree that having these visual cues is essential for live tuning and precise adjustments.

2. UI grouping: You’re absolutely right about grouping parameters by EQ band rather than by type of control. Your suggested layout makes a lot of sense, and I’ll admit I took a shortcut by organizing the UI the way it is now. I’ll reference this thread in the corresponding GitHub issue to ensure it’s tracked for improvement.

3. High-pass and low-pass filters: I completely agree these are essential additions. I might explore adding them as a separate mode for the EQ. As for slopes, implementation could be a bit trickier since biquads inherently support only 6 and 12 dB/Oct. I’ll add this as a feature request on GitHub so it can be properly tracked and discussed.

4. Mid/Side mode: This is an intriguing suggestion and could offer a lot of creative possibilities. While it’s a bit more complex to implement, I’ll look into how it could fit into the current architecture.

5. EQ cramping prevention: The current design inherently avoids EQ cramping due to the use of the TDF2 transposed structure for biquads. However, I’ll review other topologies to see if there’s room for further optimization.

Thanks again for such thoughtful feedback. It’s input like this that helps me refine and improve my plugins. Also, feel free to jot down any feature requests in Github.

Reply on news.ycombinator.com