Compressing the input signal

Does anyone know how I can rout the input signal through a plugin compressor the way a conventional insert does?

If I use a plugin compressor (or other insert effect) during tracking, and then remove the compressor, the recorded signal should still have the effect. But I can’t seem to figure out how.

anahata please could you go further ?

Thanks everyone. I think the suggestion to use an outboard analog box is probably the best advice. I guess I’ve just gotten so used to doing it that way that old habits die hard.

On a completely different note, I find it disconcerting that both Ardour user manuals are for version 2. There doesn’t seem to be any documentation for v3

Compressing during recording was popular in the days of analog tape because of tape noise. It let you record high average levels to tape for low noise, without overloading it on unexpected peaks. Closely related: if you were going to compress the channel anyway, better to do it first so the tape hiss wasn’t pumped up and down by the compressor.

With digital (especially with 24 bit which is why I mentioned it) you can safely record at well below FS to get lots of headroom without significant noise.

Ok, so then 'inserts' in Ardour aren't really inserts, since they're not between the input and the capture?

Inserts are literally just ‘inserting’ a process into the signal flow, does not need to be at a specific point(And in fact even analog consoles this is often adjustable via jumpers internally). Most people would argue it is best to capture the raw signal flow, so that is the way just about any DAW I have used to record works in general. If you want to compress the signal before this you would be best to use an analog compressor before the DA conversion stage anyways as clipping there is often very bad.


As far as i remember in sound techs when start to work in this area in late 80’s, compressing was always used in record process. Somebody here to develop & actualize for DAWs?

If the compressor is also available as a Jack application you might be able to patch it into the signal path using a Jack patcbay like Patchage or QJackconnect.
Disclaimer: I’m not sure (a) if that would work with Ardour, nor (b) if it’s actually any easier that what Paul is suggesting. It’s what I might have tried first if I was doing it.

Personally I don’t believe in compressing or processing anything while recording, especially when it’s coming in at 24 bits precision, but that’s a matter of preference and you may have good reasons for doing so.

You’d have to connect a track’s input to a bus with the compressor in the bus (and remember to disconnect the track from any other input(s)). The signal that goes to disk after hitting the input of a track is taken before any processing can be done. That’s true for the moment (Spring 2015), anyway.

Ok, so then ‘inserts’ in Ardour aren’t really inserts, since they’re not between the input and the capture?

There doesn't seem to be any documentation for v3
Let alone V4, due out any day soon... but it's an open source project, so anyone who feels like contributing...

@stratojaune - go further in which direction?
A bit more detail:
With analog tape your signal/noise ratio is 60-70dB with good 30ips multitrack recordings.
WIth digital recording at 24bits, your theoretical S/N ratio is 144dB.
Even if your 24 bit ADC is only trustworthy to 20 bits, that’s 120dB.
In practice, mic and preamp noise are likely to exceed ADC quantisation noise.

Another reason for not compressing while recording is that if you overdo it, it’s impossible or very hard to undo.

The dynamic range of tape is approx equivalent to 11 - 12 bits of digital resolution (sometimes worse) - which is interesting to consider in the context of artists who now extol the benefits of re-releasing their aging back catalogues on 192kHz 24Bit… Perhaps you can hear the tape noise / hiss from the original masters in just that bit more realistic detail… :slight_smile:

The dynamic range of tape is approx equivalent to 11 - 12 bits
Thanks - that's a good way of putting things in perspective!
If you go to Help > Manual...

That’s insane - so:

Help->manual brings up an outdated manual for a completely different application
Help->reference brings up a partially completed manual for the current (but soon to be outdated? ) version

There’s no way that can make any sense to anyone, surely?

@linuxdsp: the FLOSS manual is not that out of date even though it describes Ardour 2. As for the general issue with documentation … sure, its horrible. Do you have a solution that (a) still points people at what little written documentation we have and/or (b) gets more documentation written?

Do you have a solution that (a) still points people at what little written documentation we have and/or (b) gets more documentation written?
Yes. The Ardour3 application needs to point at Ardour3 documentation.
The FLOSS manual is not that out of date even though it describes Ardour 2.
I would contend that by definition, it is out of date, for precisely the reason that it does relate to Ardour2, (which is essentially obsolete) and all the more so when it is being pointed to from Ardour3 (or maybe 4). Ardour2 should point at Ardour2 documentation, Ardour3, at Ardour3 documentation, and Ardour4 and Ardour4 documentation? You just need to change the options in the help menu so they make a bit more sense, e.g. something other than "manual" and "reference" - so people don't waste time reading / learning about a feature that relates to an application they're not even using. (disclaimer: I will confess that I don't like any online application "help", and seldom use it personally. I find its often like "negative information" - in which you know less after you've read it than you did before, but, that said, if it is there, it maybe looks more professional if its discoverable, and vaguely relevant to the application the user is running? )


In this case I would disagree with you. It primarily comes down to, when your options are ‘something relevant’ and ‘nothing’, ‘something relevant’ becomes the lesser of two evils.

If there was documentation for a vast majority of A3 or A4 specifically, I would agree with you, but having been one of the people that was involved with writing a large amount of documentation for A2, I can completely understand why that doesn’t exist at this point sadly, and until we can get efforts directed to it (Either by paying someone with the large reserves of cash that don’t exist, or by community stepping up and doing it which is how a lot of the A2 documentation got written) I do believe it is better to at least help newcomers find something relevant.


@seablade: But can’t it just be called something sensible in the help menu?

back onto the original topic, it probably doesn’t make as much sense to put a software compressor in the record path, as it might do an outboard hardware version. You can use an external hardware compressor / limiter as a valuable method of preventing overloads on e.g. vocals or acoustic instruments from spoiling an otherwise perfect take, but once its in the digital domain - i.e. by the time the signal would be in a form which a software plugin could process (in ardour at least) its floating point, which you may as well consider has infinite dynamic range / headroom compared to the fixed point A / D and associated signal conditioning / mic pre’s etc. If you wanted to use compression as a deliberate effect, it would be better not to commit to that at the recording stage, rather to add it during the mix.

I’m using a digital mixer that can send each channel out pre or post compression to a computer. I would rather record the raw signal but I can’t predict how some musicians will behave during the show. I’m usually busy with the house mix and can only check recording levels occasionally.

In order to capture the jazz drummer in the last show I recorded I had to compress his tracks before they got to the computer. The dynamic range between quiet brushes and loud crashes made it too difficult to set a reliable level beforehand. I used a high threshold value and high compression ratio after the threshold to perform soft limiting.

@anahata: exactly the way you & LinuxDSP go further! Thanks for those details, and mashworth just above that strengthen the feeling I use tools the right way!!!

By the way, Ardour4 seems to work nice here, in Debian & AVLinux :slight_smile: