Add DC-block filter?

[joslloand]

Do we want to add a DC-block (either 1st or 2nd order HP) for signal preconditioning when using proximity?

NOTE: atk-sc3 doesn't specifically have such a thing, but in the notes pre-conditioning with HPF.ar (2nd order) is advised.

[lossius]

I think this would be a very good idea. I would personally very much like to have this, so I suggest we decide that yes, this is an enhancement that we'd like to see.

[mtmccrea]

It should be possible to add this to FoaProximity.ar on the class side (as opposed to modifying the UGen), as a pseudo-ugen, by preconditioning the input before sending to the proximity ugen itself. If there is a case for not including the dc-block, we could add a flag at the end of the arg list as to whether the signal should be preconditioned (default to true), so it could be explicitly be turned off if desired.

[joslloand]

@lossius, great to hear you think this is a good idea. The thought is that we have novice users and want to help them from hurting themselves. I'm not advocating including the DC-block within the Proximity plug-in. Doing so would mean that Proximity followed by NFC wouldn't return the original signal. (The "look into the soundfield" processing chain requires Proximity and NFC being reciprocal operations. We should prepare an example illustrating this.)

Also, the correct DC-block high-pass frequency really depends on input content. Yes, so I'm advocating this as a separate convenience plug-in.

@mtmccrea, when it comes to atk-sc3, HPF.ar is easily available. In the documentation for FoaProximity we have a note:

WARNING: As FoaProximity includes a 1st-order integration, signals must be highpass filtered before application. HPF is usually a suitable choice to control low frequency boost.

[lossius]

@lossius, great to hear you think this is a good idea. The thought is that we have novice users and want to help them from hurting themselves. I'm not advocating including the DC-block within the Proximity plug-in. Doing so would mean that Proximity followed by NFC wouldn't return the original signal. (The "look into the soundfield" processing chain requires Proximity and NFC being reciprocal operations. We should prepare an example illustrating this.)

Also, the correct DC-block high-pass frequency really depends on input content. Yes, so I'm advocating this as a separate convenience plug-in.

In Reaper I guess that it then simply is a question of inserting a DC filter as a separate plugin before Proximity, right? This might be opaque to many Reaper users. I would like to suggest that I add a DC filter to the Reaper proximity plugin, but I also add a pop-up menu where this filter can be enabled or disabled. I'd like to have it enabled by default.

I believe this would serve as a "convention over configuration" - most uses would be happy with the DC filter in, and things won't explode, and if you know what you do, you can disable it.

On a side note, do you have an example for how to do the "look into the soundfield" processing chain? I would be very curious to test that out. Thanks!

[joslloand]

In thinking through this further last night, I'm feeling that the HP shouldn't be included in the Proximity plug-in, as that doesn't actually cover all use cases. Here are some of the thoughts...

• We will often need a HP / DC-block to ensure well behaved conditioning of input to Proximity, as DC in the input signal will cause the integrator to overflow. Bad!
• Similarly, we may often wish to tonally shape the result with post conditioning. E.g, roll off the bass some to "play nice" in the mix. Proximity can easily make the signal sound "muddy" or "too heavy"

Both of these functions require HP filtering — and a 1st or 2nd order HP is a good choice. (The post conditioning may even be better suited to a Low Shelf filter. But, a HP in this role will go a long way.)

So... in this simple case of Proximity on its own we really want to be able to do two things:

• pre-filtering signal conditioning
• post-filtering tonal shaping

Using Proximity in a "look into the soundfield" chain adds more complexity. (Argh!?!) Where in the chain pre-filtering should take place can vary significantly depending on the exact nature of the chain. For the example illustrated by @mtmccrea privately, the pre-filtering HP should happen either before the imager, or better yet, at the very beginning of the chain.

What about post-filtering in a "look into the soundfield" context? That also "depends", but with the @mtmccrea's example, the most sensible place would be the very end of the chain.

... Then there are some fancier tricks / networks that revolve around the idea of processing the soundfield's "spatial residual". As you might imagine, the ideal spot for pre / post filtering varies. (Argh, again!) Having pre-conditioning automatically in front of Proximity adds one more bit of complication to an already complicated chain, becoming another thing to get wrong.

So... I am feeling that the most useful thing would be to have a separate 1st and/or 2nd order Butterworth HP filter available, with a switch to select either of these. This also fits with the ATK idea that users are actually building their own panners / encoders / processors as need be.

What about the clueless? How do we make the ATK usable for them? I'm thinking Reaper Tool-Chain presets. I'd hope we'd be able to deliver this with the ATK as part of the installation. And/or documentation.

Does this seem to make sense?

[joslloand]

With the inclusion of JSFX - CookDSP resources, the addition of HP filters for pre and post signal conditioning should be easy.

I'm envisioning having the option to choose:

• HIP: First-order IIR highpass filter
• BUTHP: Second-order Butterworth highpass filter

And a freq argument.

[lossius]

Yes, and there is also the possibility of extending CookDSP with additional DC filters. We have some filter code in JamomaCore that would be easy to port across, including one that only filters frequencies below 20 Hz.

[lossius]

freq argument is a good idea.

[joslloand]

For pre/post proximity conditioning, 20Hz is a good default.

In practice, touching freq will often be required, particularly with field recordings! My pacific ocean recordings needed lots of care here to shape: wind noise, handling noise.

If we want to home brew the filters, that's not difficult... but use of JSFX - CookDSP will make things quicker to implement.

[lossius]

Out of curiosity because this is often an issue for me as well: When using it for with the pacific ocean recordings, was the freq tweaking needed due to proximity, or due to general low rumbling and wind noise in the recordings themselves?

[joslloand]

It was as a result of all of this. Handling noise in particular is a certain case of proximity!