SmoothLimiter, simple and fast limiter VST

[camsr]

This is SmoothLimiter, a plugin designed to be low CPU footprint and somewhat colorful sounding. It is based on the same algorithms in the SmoothClipper
SmoothLimiter has an almost instantaneous attack, and a user adjustable release time. Most of the color and/or aliasing comes from the instant attack. There is an input and output gain, and a cheerful stereo link control. It's capable of a range of soft knee compression uses also, but it's main power is it will gladly limit to 0 dBFS with less distortion and aliasing than SmoothClipper. It's not suitable for everything, it has distinct color. I recommend it on peaky stuff like drums.
Best used at 96khz sampling rate. No oversampling included Stereo only. Presets Included, they can be flicked through forwards to easily apply gain drive.

Windows VST
Features: Parameter smoothing, 1 sample latency, hopefully no bugs this time.
SmoothLimiter x86 and x64

[camsr]

I should mention that this is a test build. Parameters and internal code subject to change.

[Tp3]

I recommend it on peaky stuff like drums.

I tried it on a pure sine.. it seems to be doing a good job...

[camsr]

I recommend it on peaky stuff like drums.

I tried it on a pure sine.. it seems to be doing a good job...

Yeah I enjoyed the tone of it on sines also.
On snares it is really capable of limiting the initial peak and letting the sustain through much louder.
So far, my conclusion is it does not sound great on sustained volume ride. It hits the peaks nicely, but the distortion while riding down the gain is not too pleasant.

[Tp3]

So far, my conclusion is it does not sound great on sustained volume ride. It hits the peaks nicely, but the distortion while riding down the gain is not too pleasant.

Since when WERE clippers supposed to "sound pleasant" over a sustained piece of audio ?

Clippers clip so they don't, by definition

If your barber will cut your hair (transients) along with your skull (sustained notes) - it won't be pleasant, too

I do see a trend, though... clippers like yours (and KClip and Hybris and SerpClip3\Limiter No6) are being able to "dive in" a lot further into the sustained portion of an audio clip without (relatively) obliterating it (ie. making it sound distorted in an unpleasant\inharmonic fashion)

[camsr]

Yeah I guess But the part I don't like about it is how it transitions from release to attack stage. That seems to generate some unpleasant character on a lot of things.

[Tp3]

Yeah I guess But the part I don't like about it is how it transitions from release to attack stage. That seems to generate some unpleasant character on a lot of things.

IMVHO, it depends on the material and how deep you are pushing it.

If you clip only small amount of transients (and to be fair - its not easy with your plug as there's no way to monitor what the gain reduction and/or the amount of clipped occurrences) then it does only good IMO.

[camsr]

Yeah I guess But the part I don't like about it is how it transitions from release to attack stage. That seems to generate some unpleasant character on a lot of things.

IMVHO, it depends on the material and how deep you are pushing it.

If you clip only small amount of transients (and to be fair - its not easy with your plug as there's no way to monitor what the gain reduction and/or the amount of clipped occurrences) then it does only good IMO.

A starting point I am using is, a 0dB input gets reduced to -3dB. The clipping gets tougher after that. I think it sounds good at that level too, so it kinda makes it simple! The input and output gains are 2^x, so if you set the input gain to 0, no gain is applied, and if set to 1 +6dB gain is applied, at 2 +12dB gain is applied. I did it like that because I think it's a little neater to double 1's instead of 6's. I may change this also.

A GR meter I do plan on, but it's not a high priority. It's not because I like not having it, it's because implementing one accurately is dependent on the algorithm in use. In the clipper plugins it would be trivial. I am having a hard time deciding what GUI code to implement. Then I would need to focus on that implementation for a while.

[camsr]

Maybe I should call it the OneShotLimiter?
It works at all sample rates, there is some aliasing protection, but the sound will change depending on sample rate.

[camsr]

I've reworked the plugin and a new version will come soon, including the x64 version. I'm also going to implement presets this time too, promise

[camsr]

New version posted in link. Needs testing, if it doesn't work as you expect, post details about the problem.

[camsr]

New upload. Fixed another bug in parameters, still so much to do though.

[camsr]

If there's no problems getting this version to run, then I can start on x64 version. Future versions are going to add new controls and sound, but it should most likely be able to retain what sound it has now.

[camsr]

New upload ..and... just made sure there was no denormals.

[camsr]

Just bumping in case you missed it, kvr.
SmoothLimiter works like a softclipper in the attack stage. It compresses peaks as they approach 0dB, it's not a brickwall limiter! It then transfers into the release stage from that new peak level. In many A/B comparison listenings, the sound of this limiter is much different from a lookahead brickwall limiter, as those tend to emphasize what hits the ceiling, this one seems to de-emphasize. It's not the best choice for bus effect, but I think it does at least a B+ on stems.
Interested to hear what anyone thinks about it.