[question/testing] SoundFileView improvements

Hello Devs,

Currently SoundFileView does not display data outside of the -1 to 1 range.
This is generally OK in most cases (as we often use integer soundfile
formats), but there are cases where one might need to display data outside
of that range (floating point files, displaying non-audio data).

The current implementation processes data as "short" integers, clipping the
out-of-range values to prevent overflow. In attempt to achieve displaying
arbitrary ranges, I changed processing to floats and, unsurprisingly, the
performance got worse. I was a little surprised though how much worse it
got - 3.5x longer to display similar data :/

I think this is a rather severe performance penalty for a relatively rare
use case. What do you think?
I see the following solutions:
- leave SoundFileView as is, and note that it will only display data
between -1 and 1
- modify SoundFileView to process everything in floats, which makes it
noticeably slower for everyone
- create a companion class, maybe SoundFileViewF, that processes everything
in floats, and provides the option on the SC side to use that instead, when
larger range is needed

If anyone would like to give it a try, the floating-point soundfileview
version is here:
https://github.com/dyfer/supercollider/tree/topic/soundfileview-fixes

Here's some code that shows the problem with the current implementation, as
well as a simple benchmark.

(
r = 48000;
m = 1.5; //minmax value
w = Window.new.front;
w.view.layout=HLayout();
a = SoundFileView.new(w.view).alloc(r * 1, 1, r);
a.set(0, (r).asInteger.collect({|i| i.linlin(0, r, m.neg, m)}));
)
a.yZoom_(0.5); //rescale to check
a.yZoom_(1); //rescale

//benchmark
(
{
10.do({
a.set(0, (r).asInteger.collect({rrand(m.neg, m)}));
});
}.bench
)

I'd appreciate your input on this! Thanks,
Marcin