Eq plugin

Initial pull request for the native EQ plugin, #1376 

![image](https://cloud.githubusercontent.com/assets/7412852/5425560/4ecbfbbc-8314-11e4-9a7e-334e7910f87e.png)

On 12/25/2014 10:47 PM, Dave wrote:
>
> In plugins/Eq/EqEffect.cpp
> <https://github.com/LMMS/lmms/pull/1443#discussion-diff-22275428>:
>
> > +	const float outGain = m_eqControls.m_outGainModel.value();
> > +	const int sampleRate = Engine::mixer()->processingSampleRate() * 2;
> > +	sampleFrame m_inPeak = { 0, 0 };
> > +
> > +	if(m_eqControls.m_analyzeModel.value() )
> > +	{
> > +		m_eqControls.m_inFftBands.analyze( buf, frames );
> > +	}
> > +	else
> > +	{
> > +		m_eqControls.m_inFftBands.clear();
> > +	}
> > +	upsample( buf, frames );
> > +	gain(m_upBuf , m_upBufFrames, m_eqControls.m_inGainModel.value(), &m_inPeak );
> > +	m_eqControls.m_inPeakL = m_eqControls.m_inPeakL < m_inPeak[0] ? m_inPeak[0] : m_eqControls.m_inPeakL;
> > +	m_eqControls.m_inPeakR = m_eqControls.m_inPeakR < m_inPeak[1] ? m_inPeak[0] : m_eqControls.m_inPeakR;
>
>     After some further testing... I think maybe we should reconsider using
>     the LR4 filter in the Eq. Or at least make it optional...
>
> The most tweaked parameter is the cutoff frequency, you could be
> right, or ....
> I know the implementation was not correct, but it sounded and worked
> much better 2 bug fixes ago(iirc a missing - ). The roll off to the
> -6db was much tighter, and i was able to stack 4 of them. IMHO this is
> when the eq sounded it's best.
>
> @diizy <https://github.com/diizy> I would welcome your thoughts on this.
>

Hm, I doubt there was actually any difference - the bugs were mainly on
the HP side, then I incorrectly tried to fix them on the LP side, then
had to revert that fix and fix the HP...

I just think probably using an anti-aliasing filter is unnecessary -
there shouldn't be any extra >nyquist noise introduced by any of the
filters, and anything introduced before the EQ has already aliased and
thus can't be fixed by the EQ anyway...

On that note, I wonder if also the oversampling should be switchable
(maybe even for each filter individually?) since in biquads, it's not
always necessarily a desirable feature... in some cases, oversampling on
biquads can actually be counterproductive (IIRC it can introduce more
noise on low cutoffs, or something).