KVR Audio

DuX · Post by **DuX** » Mon Apr 14, 2014 10:05 pm

X86 builds usually are faster.

But people think that the bigger number means faster execution... but it is far more complex than that and this is not the place to discuss it. That's one of the reasons I stick to x86, but I also don't need more RAM than 2GB for my projects. Actually 2GB is an overkill for me since I don't use sample libraries nor convolution, nor very GUI rich plugins at all, just soft synths and soft FX, preferably GUIless or at least not using much RAM. All I need is a fast CPU with as many cores I can afford and *some* RAM to run them. That's why I prefer GUless plugins, too. GUI just takes such a large chunk of RAM, in many cases for nothing. If a plugin has just a few parameters [up to around 10-ish?] there's absolutely no need to make a GUI for it. In my view it's almost ridiculous.

Anyway, I'm glad there will be a x86 version of V2, too!

Your limiter really is a bit special amongst all the slew of other limiters. I really love it for track limiting and it's got an interesting and different sound that I would call "dense" or "thick" but not in a bad sense, of course.

Great job camsr! I think you're onto something here. Thank you!

camsr · Post by **camsr** » Tue Apr 15, 2014 1:56 am

DuX wrote:That's why I prefer GUless plugins, too. GUI just takes such a large chunk of RAM, in many cases for nothing. If a plugin has just a few parameters [up to around 10-ish?] there's absolutely no need to make a GUI for it. In my view it's almost ridiculous.

I have to disagree, because a properly coded GUI does not interfere with the performance of the DSP in any significant way. Rendering GUIs can get slow, but that is going beyond what is actually required for usage. Peak meters can add slight overhead, and I do mean slight, but only because they need to "see" the audio the render useful information. A GUI that does not "see" the audio data is completely out of the way of the DSP, on a multi-core platform.

I am glad you like it, thanks for the comments.

camsr · Post by **camsr** » Sat Apr 26, 2014 9:16 am

Just showing up! Soft clipper is here, works good. Yes, this post is awesome.

camsr · Post by **camsr** » Mon May 12, 2014 12:11 am

A bump.

camsr · Post by **camsr** » Wed Jul 09, 2014 3:16 pm

I will be updating this plugin soon. Just gonna bump this so maybe the links don't expire

Turello · Post by **Turello** » Wed Jul 09, 2014 3:22 pm

Works very well on rock snare!

camsr · Post by **camsr** » Wed Jul 09, 2014 3:27 pm

Turello wrote:Works very well on rock snare!

Yeah, soft clippers do that. They cut peaks with a very uniform harmonic distribution, transparent until driven too much.

The new version will use the same algorithm as V2, so it will sound the same, I am just making some optimizations and may add a few features.

Tp3 · Post by **Tp3** » Wed Jul 09, 2014 5:35 pm

I don't know if that makes sense but it seems you need both (ie: insert them in serial) in order to maintain sub content a conjunction with transient heavy material (like some generated loops from Microtoniq - loops which comprise of heavy low-end and spiky hi freq transients)

camsr · Post by **camsr** » Thu Jul 10, 2014 9:14 am

That's interesting. Although any hard clipping usually aliases badly, especially with high frequencies. And oversampling a hard clipper usually defeats it's own purpose. That's why there is softclipper!

I have added parameter smoothing, so automation is now acceptable, it won't click at all. That did add some overhead... but hey, it's kind of a necessity

and it's still incredibly fast. Going to put final touches on it and upload in a day or so.

Tp3 · Post by **Tp3** » Thu Jul 10, 2014 12:35 pm

camsr wrote:That's interesting. Although any hard clipping usually aliases badly, especially with high frequencies. And oversampling a hard clipper usually defeats it's own purpose. That's why there is softclipper!

Well, y'know what they say : "There's no rules. if it sounds right, it MUST be right"

(although a lot of people won't understand that in order to disregard the rules, you have to know them to begin with !...)

I guess, technically, you are right. I was just experimenting and luckily, it sounded good

camsr · Post by **camsr** » Sat Jul 19, 2014 5:00 am

The newest version is available on the front post. (v3)
Parameter smoothing has been added, but it has one drawback.
The smoothing time WILL change with samplerate. I hardcoded it to run faster, pre-emptivly, and did not think it would matter. Please let me know if you like it. I am still making changes.

A fun thing I discovered while testing it! I used FL studio's Formula Controller to generate random numbers and automated the drive, and out came some magic.

Tp3 · Post by **Tp3** » Sat Jul 19, 2014 10:18 am

camsr wrote:Parameter smoothing has been added, but it has one drawback.
The smoothing time WILL change with samplerate.

Can you elaborate on that ? how does it effect the sound ?

camsr wrote:A fun thing I discovered while testing it! I used FL studio's Formula Controller to generate random numbers and automated the drive, and out came some magic.

Then this calls for a "Rnd" button !

(I LUV Random setting... they can produce out-of-this-world results)

In what way was that "magic" ?

Thnks !

camsr · Post by **camsr** » Sat Jul 19, 2014 4:57 pm

Tp3 wrote:
camsr wrote:Parameter smoothing has been added, but it has one drawback.
The smoothing time WILL change with samplerate.
Can you elaborate on that ? how does it effect the sound ?

The envelope controlling the drive gain will be slower at lower sampling rates. Since the filter is not aware of sampling rate, it is stuck as a proportion of the nyquist frequency. I set it to sound smooth.

camsr · Post by **camsr** » Thu Jul 24, 2014 8:50 am

Just a bump, if anyone has any thoughts on the plugin I am open to ideas.

Tp3 · Post by **Tp3** » Thu Jul 24, 2014 3:39 pm

Can you add some indication as to when (and how, if possible) it starts "shaving" off peaks ?
(how=how much, in dB)

Thanks

SoftClipper, and now SmoothClipper