Implemented a new Compressor effect

[ketsebaoteth]

Hello there nexyon !

This PR adds a new, from-scratch audio compressor.

Core Features:

• RMS Detection: Measures average signal power for a smoother, more musical response
• Soft Knee: Gradually introduces compression around the threshold for a less aggressive and more transparent effect.
• Lookahead: Delays the audio path, allowing the detector to anticipate and control transients without artifacts.

---

Waveform Export From Blender Comparison in FLStudio

exported from blender a new compressor modifier.

the one on the top shows the compressed export from blenders VSE in which you can see places where it was higher being tamed down and the lower ones get increased a bit.

Another Waveform more obvious preview

Bottom one is compressed on this one

Note: I'm still new to audio programming, so I'm very open to feedback if anything about the results looks wrong or could be improved. 😊

[neXyon]

Hi! I had a first rough look at the code. From a pure coding stand point it looks good, you know your C++! From the audio side: I assume you got the math and everything from some source, do you mind citing it, potentially as comments in the code?

Generally, I saw a few points to be addressed:

• License/Copyright headers (just copy from other files and update with your name and this year).
• Format with clang format please.
• CMakeLists.txt changes are missing.
• Units should be the same as in the other classes for consistency: seconds instead of milliseconds and possibly also gains not in dB but just as ratio (i.e. 0 dB = 1), though for the latter I think dB are fine too if it simplifies the math inside the methods.
• It would be awesome if you could add C and Python API for this effect.

[ketsebaoteth]

From the audio side: I assume you got the math and everything from some source, do you mind citing it, potentially as comments in the code?

the math came from multiple places , some sources where easier to understand about a certain concept than others for me, and i have added as many as i can as comments 😊👍

[ketsebaoteth]

@neXyon

I’ve ran into a small but important issue with how the modifiers recreator handles audio effects like AUD_Sound_Compress and AUD_Sound_Equalize. Right now, every time a value changes when you call the API's AUD_Sound_Compress or equalize the API creates a new AUD_Sound instance that wraps the effect. and returns a referance to that This means that while dragging a knob, it is rapidly destroying and recreating effect instances, which causes glitchy, unstable audio output.

The current workaround in sound_equalizer is to defer updates until the drag is released. But that’s not ideal — in audio workflows, real-time feedback is crucial. People expect to hear the effect evolve as they tweak parameters, not just after they let go.

if you tweak values in the equalizer as well here is how it sounds like:

2025-08-28.10-02-07.mp4

i am not a 100% sure but i think this is the cause of the zipper glitch problem, and i dont know if its a 100% deal breaker from a usage standpoint.

[neXyon]

I’ve ran into a small but important issue with how the modifiers recreator handles audio effects like AUD_Sound_Compress and AUD_Sound_Equalize. Right now, every time a value changes when you call the API's AUD_Sound_Compress or equalize the API creates a new AUD_Sound instance that wraps the effect. and returns a referance to that This means that while dragging a knob, it is rapidly destroying and recreating effect instances, which causes glitchy, unstable audio output.

This has to do with the fact that Audaspace was not designed with this kind of real-time audio editing in mind. Quite contrary, it was designed to build a full signal graph and then let it play. The reason for this is, how sequencing and the animation system in Blender works. You can put a whole scene into another scene, even multiple times and you can play back multiple scenes at the same time. So if you look at a scene as one signal graph, you can have that same graph play multiple times at the same time but with different time offsets. That lead to the aud::ISound and aud::IReader architecture, where the Sound is the blueprint for the signal graph and the reader is the instantiation of it that actually plays back. Animation is done through an animation cache (aud::AnimateableProperty). If you would have to update values from the outside during playback, you would have to be able to access the instantiations (Readers) separately which means that the whole signal graph needs to be duplicated in Blender as well every time playback of a scene starts in one way.

With that background information in mind, I think it's still possible to easily create something interactive with audaspace. Keep in mind though that such an interactive architecture will run into the issues I mentioned in the paragraph above. The idea is simple: you can use a separate object (like aud::AnimateableProperty) as an std::shared_ptr which is handed to the ISound and IReader classes and can be updated during playback. Of course it's important to make access to that separate object thread safe if necessary (either within the object itself, or with locking the playback device while you change something). This can be used to either update parameters of sounds (like the compressor parameters, or EQ parameters) or it can also be used for getting data from audaspace during playback (like the metering you are implementing). If you want an example of this, the AnimatedTimeStretchPitchScale that has recently been added does exactly that with an AnimateableProperty.

Quite a bit of rambling. I hope this make sense. Let me know if something is unclear or you have questions.

[neXyon]

Thanks for the updates! I think if you change all other dB parameters to ratios, you should have the knee as ratio as well. Some of the documentation and parameter names still mention the old units, please update those.

I tried it briefly and got some noise before the playback actually started, there might be a bug with the lookahead?

It would also be nice to document sensible value ranges for the parameters! Which values are you testing with usually?

Do you want to change the API to work with a shared object for the parameters?

[neXyon]

This doesn't work/compile. It uses the C API, though it should use the C++ API and you should include Compressor.h. You can see how the other methods are doing it.

[ketsebaoteth]

Thanks a lot for the feedback and for walking me through the animatable properties—really helpful. I’ll make sure to correct the units during the final cleanup phase; it’s on my radar, no worries.
Lately, I’ve been more focused on resolving the issue I mentioned earlier, since it’s been a major blocker and almost renders things unusable.
Regarding the main problem:
I’ve noticed the initial noise too, and I’ll definitely be addressing that.
As for the API change—I think, it’s a must. I might need a bit of time to fully understand what you explained 😅, but I think I can cook up a something. Recreating effects on every parameter change isn’t ideal, so i think its a must

[AGoldenDragon]

Hey, anything new? I'd really like to add this as a modifier to the base Blender repo when ready 😁

[aras-p]

Yeah it would be really good to know how to move forward with this. If @ketsebaoteth can't finish this up for whatever reason, could someone else "take over" the PR?

[ketsebaoteth]

Hey, sorry for leaving this hanging. I’m a uni student and classes got pretty busy, so I had to step away for a bit. Things have calmed down now and I’d like to pick this back up.

[ketsebaoteth]

UPDATE

In the second screenshot, the compressor misses the very first part of the song.
This happens because the compressor is not fast enough to detect the initial transient.

By enabling lookahead, this issue is resolved.
You can see the corrected results in the last screenshot below:

[neXyon]

Thanks for the update! It's very nice to have a python API to test this.

Unfortunately, since I'm not really a DAW user, I hardly know what would be good values to test the effect with. Could you suggest some?

When I tried it with the python API, I still got some noise when starting playback, even with this new version. When I set the lookahead much higher, I got no noise, but significant delay. I think it would be nice if the lookahead parameter was not necessary and the effect would automatically do it with the correct length. Would that be possible?

Some points I mentioned previously that haven't been fully addressed:

• Format with clang format please. (CompressorReader.cpp especially)
• Units in dB are mostly ratios, but the knee is still in dB and the python API uses dB too. For consistency and because Python and C bindings use the same documentation, please make everything into ratios! Maybe some computation in the effect can also be changed so that you don't need to keep switching between ratios and dB? I see that at least at the end smoothedGainReduction is turning env back from dB to a ratio.

[neXyon]

Compressor.h is not included so this gives an error.

[neXyon]

Docs here still say dB, should be a ratio now?

[AGoldenDragon]

Hey, sorry to bother you again, but are there any updates? It looks like this PR is in the final stage with only a few minor tweaks left, and it would be a shame if it didn’t get merged.

If @ketsebaoteth isn’t able to finish it for some reason, I’d be happy to take it over🙃

[neXyon]

If you're familiar with compressor effects, I'd appreciate the help. As I wrote, I don't even know good values to test this.

[AGoldenDragon]

If you're familiar with compressor effects, I'd appreciate the help. As I wrote, I don't even know good values to test this.

Well, I guess if @ketsebaoteth won't answer in a few days I'll take over🙃