Re: [question/testing] SoundFileView improvements

 > I think this is a rather severe performance penalty for a relatively
rare use case. What do you think?

You should do some testing to see where exactly the performance penalty is
coming from. I'm suspicious of the switch to QPointF.

But more than that, floating point arithmetic is slow (see this post
<https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa>),
and nobody has screens to display that level of precision. Think about it -
a short can represent about 65k values. Even with I think using floats in
the critical display loop is probably going to hurt you no matter what.
Even a larger integral type would probably be better.

Honestly, looking at this implementation, it's not exactly perfectly
designed in the first place. (At least, the true branch of the if at line
774). The critical loop makes two calls two setPen for each point. Each of
those calls will result in a nontrivial amount of instructions - from what
I can tell, at least a few branches, a couple assignments, and an atomic
ref count update on the Pen pimpl. Dynamically allocating on every redraw
probably hurts as well.

> 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

You could also try changing back to short, but change the normalization
instead, and give the user control over that (or better yet allow it to be
automatically calculated from the data).

-Brian

On Wed, Apr 4, 2018 at 5:51 PM, <[email protected]> wrote:

> 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
>
>