[Fluxus] compressor update

[Kassen]

Ok,

I figured out the reason why the compressor's controls weren't
working; turns out the actual call to compress the signal was
commented out. That certainly explains it :-)

For testing I enabled it, in stereo by creating a second instance.

This gave me compression, but with a fair amount of glitches when it
would kick in. I moved the mentioned "env" variable outside of the
scope of the function so it could persist which slightly improved
things, but there is a more fundamental issue.

The used design uses a lookahead plus RMS weighing, which are nice
features, but they cause issues for us. Because we can't lookahead
"over the edge" of the current block and values beyond that will
zero-ed out, the RMS will start to approach 0 as the pointer approaches
the end of the block. This will create a sort of modulation with a
rate of the block-size. The current design will be a decent idea to
process a whole recording in one swoop, but might not be so great for
block processing.

One solution might be to take a extra block of latency. That will
solve the lookahead issue in many cases. However, it's also slightly
naive. When the used blocksize gets below the size of the lookahead
time plus the window-size for the RMS then it's not enough; the amount
of extra buffers needed will depend on the size of those buffers.
While the wouldn't add extra latency per-se, because the length of the
buffers will go down, it would add considerable extra complexity to
the code.

Unless there is a genius idea lying around I'm inclined to simply take
out both the lookahead and the RMS. That will make the problem go away
with little effort and less cpu cost, though of course it does create 
the new issue that transients will get through and may clip.

Another question is whether we'd prefer a design linking the gain of
both channels or a dual mono system. The first option will be
preferable for the stereo image, the second is more versatile if we'd
like to keep the option of a multi-channel Fluxa open (for example for
a analogue mixdown or to send a clicktrack to somebody).

Currently I'm inclined to go with the most simple strategy that will
actually work and see whether that is a improvement over the old "no
compression" situation, then figure out where to go from there.

Thoughts & opinions welcome.
Kas.