Tan by Acustica-Audio (Free Compressor)

[Uncle E]

Isn't it usually the other way around? Why would anyone want to use a higher latency version at all if this was the case?

My understanding was the Zero Latency version is supposed to use less CPU (I interpreted it to mean it uses fewer impulses), which makes it possible to use it at a lower latency. Anyway, I just tested both versions of Tan and found that they use about the same amount of CPU, so there goes that theory.

[Uncle E]

I'm a very happy MJUC owner and on it the very nice sounding tone control can be used to add sparkle or warmth.

I only tested the MK3 against Tan. With that version, even the highest setting of the tone control is darker than Tan and the clean signal.

[Funkybot's Evil Twin]

At first glance I thought the ratio knob didn't seem to work correctly.
I got more compressed sound at 2:1 than at 4 or 8:1...but according to the developer it is just the normal behavior under certain conditions. See the discussion below.
http://www.acustica-audio.com/phpBB3/vi ... an#p104671

I've never had a compressor plugin that behaves like this one anyway..

Sounds like the knee is softer at lower ratios which means more compression. The SSL Buss Comp behaves the same way. Like you already pointed out, it's completely normal.

[Fantasie]

Sounds like the knee is softer at lower ratios which means more compression. The SSL Buss Comp behaves the same way. Like you already pointed out, it's completely normal.

Thanks, I didn't know that at all. I already have Slate VBC and will check it later.

As of Tan, whenever the gain reduction is smaller than 15dB, you get more compressed sound at lower ratio, according to the developer's description.
This means,at least for me, that 90% of the time I'll get the opposite result than I expected form the ratio itself, for I rarely push it that hard.
I don't know how SSL behaves, but I felt confused a bit..

[Uncle E]

As of Tan, whenever the gain reduction is smaller than 15dB, you get more compressed sound at lower ratio, according to the developer's description.
This means,at least for me, that 90% of the time I'll get the opposite result than I expected form the ratio itself, for I rarely push it that hard.

Only with heavy gain reduction. At lighter gain reduction, the ratio will still be low. A dedicated soft knee compressor like the DBX 160 VU doesn't have any ratio control at all because you basically control the ratio by how hard you hit it.

[Funkybot's Evil Twin]

Thanks, I didn't know that at all. I already have Slate VBC and will check it later.

As of Tan, whenever the gain reduction is smaller than 15dB, you get more compressed sound at lower ratio, according to the developer's description.
This means,at least for me, that 90% of the time I'll get the opposite result than I expected form the ratio itself, for I rarely push it that hard.
I don't know how SSL behaves, but I felt confused a bit..

The Slate FG-Grey in VBC is based on an SSL Buss Comp and uses the same type of approach. I think the idea is to set the ratio first, then adjust the threshold to achieve the right amount of compression. So if you want to use a 4:1 compression ratio, maybe the threshold is a little deeper to get 2-3db's of reduction compared to getting a roughly similar level of reduction using the 2:1 ratio. The two will sound different even at 2-3 db's of reduction because of the knee shape. It's a versatile, musical approach, but perhaps not the most intuitive thing in the world.

[Fantasie]

Only with heavy gain reduction. At lighter gain reduction, the ratio will still be low. A dedicated soft knee compressor like the DBX 160 VU doesn't have any ratio control at all because you basically control the ratio by how hard you hit it.

Ah..got it, thanks! So, the ratio 2:1 or 4:1 is not fixed but actually variable, and the value only denotes its maximum as far as the soft knee is concerned. I missed that point. I feel like I have to learn about basics of compressors

The Slate FG-Grey in VBC is based on an SSL Buss Comp and uses the same type of approach. I think the idea is to set the ratio first, then adjust the threshold to achieve the right amount of compression. So if you want to use a 4:1 compression ratio, maybe the threshold is a little deeper to get 2-3db's of reduction compared to getting a roughly similar level of reduction using the 2:1 ratio. The two will sound different even at 2-3 db's of reduction because of the knee shape. It's a versatile, musical approach, but perhaps not the most intuitive thing in the world.

Nice tips. I just tried it and prefer 4:1 to 2:1 with the same gain reduction. 4:1 has more openness to my ears. I'll definitely try the same approach on Tan later. Thanks!

[logburner]

SSL style buss compressor has variable knee against compression ratio.

The lower the ratio the softer the knee, which means compression kicks in at lower signal level than the set threshold, hence more compression effect overall, but doesn't equate to the amount of gain reduction. Soft-knee compressor (like 2:1) starts compressing below threshold with lighter ratio and the ratio gradually gets steeper as the incoming signal is louder than the threshold.

At higher ratio (10:1 as an example), it works as a hard knee compressor which is more straight-forward compression as it just squashes the sound above the set threshold at constant gain reduction ratio.

[realmarco]

Zero Latency

i hate it when people say their plugin have Zero latency.

its impossible !
Sound goes in plugin does its thing thru program language and Math and then
comes out affected as PCM data

it always delays the track a little bit. Ultra low latency yes zero latency is a lie

what people think is zero latency is that their host's delays every-track to how much a plugin(several on other track) takes to do its thing and lines them up

doing that is called PDC (plugin delay compensation)

[Zaphod (giancarlo)]

ZL in our products means we are using a zero latency convolution engine. This engine gives exactly a single sample of delay if we avoid
- Lookahead - but in zl version we disable it
- Predelay offset/pre ringing (most of sampled hardware is not zero latency, so when we reproduce it we are forced to play the same offset). It's possible we'll release truncated versions (we did it in the past, we name them "live")

[ObsoleteAcc99]

hmm nice to be able to finally try a nebula freebie in aax. And in any case, thanks for the freebie, with an uncomplicated download (finally), and no tricky plugin registration required (again, thanks).

The first issue here is that it hangs pro tools on exit.

All i did was make a new project, insert a stereo wave loop, and put 3 tan (high latency) in series, to test cpu usage and latency. Then i removed them all and inserted one low latency version. Then i decided to quit PT, and it simply hangs. You can not leave without forcing it to shut down. Thought I would report that.

OSX 10.11.6 PT 12.5.2

Yes bmanic is spot on about the metering, in fact i think it would be better to have a version without it at all, as it's SO off the mark, it actually throws your concentration and gets in the way. Even with attack and release at minimum, the needle just doesn't move back from GR state. Also, it seems it comes in way too late. To use this plugin effectively, you have to be very experienced with compression with your ears. I do not recommend this plugin for people new to compression.

I have plenty of algorithmic plugins that sound better for the style of music i do IMO ( i tested it on an edm sub mix and did not like it much), with 1/20th (literally) the cpu hit, so I'll uninstall it, but i'm happy to keep it installed for a while if you need testing to help with the hangs.

(PS even when using the high latency PT playback engine, ie hybrid buffering, one instance is using like 10% of a core. Way to much for a compressor. At 512 samples in "live" track mode, it uses 25% of a core! At 128 samples almost the entire core for one instance!).

[Zaphod (giancarlo)]

- about crashes in pt, if you are interested in solving them just open a ticket. At the moment we have really few reports on this matter, we'll try to fix them as soon as we are able to replicate the matter

- about the cpu load: it is directly linked to the particular emulation we are doing. If you are not interested in that emulation the cpu load could be too much. If you are directly comparing with the unit you can find it more acceptable

- yes meters are slow, but we preferred that way, because the meter needle is not very visible in this skin. Indipendently from the product, as bmanic said we need to improve in this area, and I agree with him

- about preferences/usage: I understand that a compressor (especially an hardware emulation, in general less flexible than software) is not good for every possible task, and you can find better tools for a fraction of cpu. Anyway this compressor is special for other qualities, not immediatly visible at first glance. For example this particular emulation "doesn't break", you can compress a lot without artifacts (like in a real hardware compressor) and it "acts" like an hardware compressor (just look the stereo field and the weight). These qualities are not immediatly visible when you try quickly comparing with other tools and they are the reason for some mixed feelings about it. A couple of days ago I tried the same exact audio provided by an other developer on his presentation video and compared directly with tan (after normalization since makeup gain is a bit limited) and I had even a bigger compression, less artifacts, less spikes, better audio image for the same exact task he was showing. I'm not saying this compressor is better for all possible tasks, but on this particular task it was shining.
Compressors are strange tools, highly dependent on the material you try: ie a chandler on edm maybe doesn't work, while you need an api or spl. In general software compressors are easily more flexible, because it is easier to make them program dependent just starting from few simple tricks and rules, but here the goal is the "emulation", and for example in this particular case the target compressor is not pd.

[ObsoleteAcc99]

well ok Zaphod, i will give it a fair test against other plugins at heavy compression. I don't understand nor agree with "yes meters are slow, but we preferred that way, because the meter needle is not very visible in this skin.". That actually doesn't make sense to me. There's no point in having a completely inaccurate meter, and it IS visible IMO. All i was suggesting was that it might be ideal to offer a skin for this with NO meter, as it confuses the user cause it's so badly calibrated! I am pretty certain i am stating fact about the metering here. Look, as little as my opinion counts here, I am sure since bmanic at least said it also, that people will tend to agree.
I sent the crash to apple with the automatic pop up, and didn't copy it, but will find the log and email it to your support.

PS i have no idea what compressor this is modelling. could you let me know, so i could head to head it with other plugins simulating similar models? Thanks!

[Zaphod (giancarlo)]

I'll rephrase it ok: normally our meters are slow. It is linked with the refresh rate we use in our gui engine, and maybe other reasons - we'll focus and improve them
Bmanic said that sooo many times, he is a broken record - and he is right to be honest.

On this compressor we made them even slower than usually since the skin has a little needle and it was not visible when flickering

Maybe it is not clear what this compressor represents: we had an annual workshop and we sampled several units. For one of them we prepared a quick skin and in less that a day we generated a plugin emulation. Tan is a showcase of the workshop. Everything you see was generated without "writing code". Since the product is not bad we decided to release it for free. Normally we work more in order to make the compressor maybe better, more flexible...

For example pink required a lot of work, as direct consequence is not free. It's interesting tan is derived from direct sampling without further adjustments and fixes.

[Lesha]

PS i have no idea what compressor this is modelling. could you let me know, so i could head to head it with other plugins simulating similar models? Thanks!

http://www.igsaudio.com/multicore