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:34 PM, Dave wrote:
>
> In plugins/Eq/EqEffect.cpp
> <https://github.com/LMMS/lmms/pull/1443#discussion-diff-22275373>:
>
> > +	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;
>
>       * Should the Q control for peak filters be inverted?
>
> Now that is a very good question, and one i put some research into
> while deigning the gui. If we are talking about the handles on the
> widgets, (right click and move) I total agree they are counter
> intuitive....
>
> The Resonance knobs caused me a big concern while designing. If it we
> up to me I would have implemented them as bandwidth, because that is
> what that knob is changing, and would be more intuitive. First i
> started by looking at the eq plugins im familiar with, all using
> resonance, with clockwise increasing, then I looked at few few others
> that are highly spoke of, they also implemented it the same way.
> I am thinking i would rather spend the time, and implement the
> controls as bandwidth as opposed to just reverse resonance knobs.
>

Well if you want a counter-example, look at Fons Adriansen's 4-band
parametric - it has freq, bandwidth and gain for each filter. The
bandwidth there works as smaller = narrower, larger = wider. That seems
the most intuitive approach to me.

After all, the resonance in the LP/HP filters doesn't really actually
have anything to do with the Q/bandwidth in the peak/shelf filters...
it's a completely different control, even though both are called "Q" or
"resonance" sometimes (properly, IMO, "resonance" should not be used to
mean Q except in properly "resonant" filters).

> @diizy <https://github.com/diizy> what's your thoughts on this.
>
>       * For the display widget: how about if you could control the
>         Q/bandwidth of each filter by using the scroll wheel while on
>         top of the number?
>
> atm this can be done with right mouse button. but the implementation
> needs to change. as on the graphic display pulling away from the
> widget should definitely increase the band width. I am planning of
> waiting a couple of weeks while changes are still being made, then i
> will write some documentation, and possibly a video.
>

Yes, it's good it can be done with right mouse button, I just think the
scroll wheel could also be used for it. Just an idea, not really that
important...

>       * Analyzing: how about if you could toggle the display to IN/OUT
>         (current), IN only, OUT only? It's sometimes a bit hard to see
>         the curve when they're always overlaid, modes to show only in
>         or out would help with this. The current IN/Out labels could
>         be used as toggle buttons.
>
> This is a great idea :)
>
>     Also, maybe there could be tooltips/textfloats when moving the number
>     widgets on the display - ones that show freq and gain both?
>
> Another good idea. I did try this with fixed labels in the gui, but
> they took up too much space, so i removed them. Why did i not think of
> using TextFloat. i was even experimenting with them while trying to
> overwrite the fader text. good call :)
>

:)