K2 - Peak Compressor

[martinvicanek]

My question is if we can assume that: "For fast release (shorter than 50ms) one can not rely on first-order IIR. For abover 50ms, it is good enough".

It might look OK on screen, however there might still be ripples at some level like -30 dB. If you use that for side chaning, you will get cross modulation. Really the single pole is a lame duck, there is no excuse for using it for pro grade envelope detection.

[Rocko]

Martin

It might look OK on screen, however there might still be ripples at some level like -30 dB. If you use that for side chaning, you will get cross modulation. Really the single pole is a lame duck, there is no excuse for using it for pro grade envelope detection.

Thanks Martin, understood.
I'm really not that experienced with FIR's. What should I be looking into for a basic FIR design, I mean what are the recommended slopes, overshoot, ripples suggested here? How about the number of taps?

The goal is general purpose 'pro grade' stereo compressor, for learning.

nix:

I was referring to your images Rocko,
the first and third ones start with some amplitude already.

Yes, I'm running a looped burst signal and just 'paused' the image to upload to forum. So what you see is the tail of the last release.
Anyway - yes, I understand the benefits of FIR for faster release times.

Appreciated !

Rocko

[nix]

Oh OK, I see 8D

You wouldn't post that FIR Martin for us , would you?

Should we rectify or square to create the positive signal?

[Rocko]

Martin hi,

I also had noticed that in the three examples you had provided (IIR first order, IIR 4th and FIR) there is some latency.
I mean the envelope follower rises only after a single sine wave cycle.

On the example I had posted, the rise is immediate.

What is the cause for this latency? Is it Attack time setting? Can I ask what frequency are you using for that sine wave (how long does one cycle take)? Mine was done on 1KHz.

Thanks,
Rocko

[martinvicanek]

Okay here is my proposal for a pro grade envelope follower. The FIR filter is a cascaded moving average filter. It has some really nice properties:

- it never overshoots
- it has excellent bandwith-latency producct (close to theoretical minimum)
- it has a finite impulse response: no ringing, no endless creeping
- it is linear phase: all frequencies are delayed by the same amount (which happens to be the effective window size). Therefore, if you delay the signal-to-be-processed by that amount, it will be in perfect sync with the control signal (consistent look-ahead).
- it is flexible: window size may be adjusted on the fly
- it is light on CPU (actually super light for a FIR filter).
- CPU load is independent of window size.

I have included a test bead so you can play asound with it. There is also the option to add extra release (for whatever reason).

About latency: I find 10 ms latency OK for a live setup. (For studio latency is irrelevant because it can be compensated.) To put it into perspective: 10 ms is the time needed for sound to travel 3m in air. Now how far away is your amp typically?

[nix]

So much thanks!-
I see it works without ripples at 10 ms.
I'll let you know here how it performs in 2SYN- the MIDI converter.
The delay trick is interesting to get synchronicity-
I am actually discarding that information, as it is noise I'm pretty sure.

[martinvicanek]

I'll let you know here how it performs in 2SYN- the MIDI converter.
The delay trick is interesting to get synchronicity-

Yeah, you probably have a coparable latency in pitch detection, so that is only consistent.

I am actually discarding that information, as it is noise I'm pretty sure.

I didn't get that last part.

[nix]

mmm- I'll try to be clear(if I can, hehe)

If I delay my incoming guitar string, so that the transient is synchronized to the follower's attack,
I will end up processing the noise the string makes when u pluck it as my pitch read.
I trigger a MIDI note after the string has settled into an even cycle(about 50ms), as the pluck is a noisy,clicky thing with a pick-
and somehow smeared with fingers too.
The initial attack sound is discarded.

When tracking to pitch by turning the MIDI note on and off until it is the correct true one (-on integer change), which it finds more easily than a single trig, the first slightly mispitched note will play after 20 ms,-- 10 ms of RMS registering and 10 ms of mono to MIDI.

I think it will work great, or equally well.
The thing is that guitar strings sorta swell up and down over a trigger threshold setting(giving unwanted on/off fluttering),
so I realllly low pass the RMS read to smooth it too with the stock 1 pole smoother.

edit- my stereo PA is 2.5m away

[nix]

Heya!-
the FIR filter follower works real good-
I want to tweak smoothing and such,
but wanted to mention a couple of things-
It's thirsty for CPU. My schematic uses 17% cpu now,
where before the follower it was 10-11.
I notice it's not possible to pack it, as the 'square and pack' module stipulates a monoin.
I think I just need to pack it to get cpu down.
I have 6 strings, so I do 2 packs of 3 streams to save cpu.
Is it possible Martin pretty please that you could do a packed version?

Here is the RMS reader I was using before->

FastRMS.fsm

(1.26 KiB) Downloaded 1258 times

by Bootsy- thanks for it!

[martinvicanek]

Nix,

the follower that I posted is already packed and optimized, I am surprised that it causes a CPU hit on your system. Here, even six of them in one schematic hardly increase CPU at all.