Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why do waveform types have different visual gains? #12115

Closed
ronso0 opened this issue Oct 15, 2023 · 8 comments
Closed

Why do waveform types have different visual gains? #12115

ronso0 opened this issue Oct 15, 2023 · 8 comments

Comments

@ronso0
Copy link
Member

ronso0 commented Oct 15, 2023

image
image
image
image

Is this to be expected?
Anyhow, if I want to test waveforms I'd also need to adjust the visual gain to make the comparable.

@daschuer
Copy link
Member

I think we can consider this a bug.

@m0dB
Copy link
Contributor

m0dB commented Oct 21, 2023

I agree. The cause must be in how the amplitude is calculated by combining the high/mid/low values vs the real amplitude. So there might be an inherent and unavoidable difference but it shouldn't be this big. I will have a look when I have a moment.

@m0dB
Copy link
Contributor

m0dB commented Oct 21, 2023

First of all, note that when I implemented this for the new waveform types, I just based it on the existing implementations, so I am not 100% sure what the original thought behind all this is.

The waveform data contains values for low, mid, high, and all . The RGB waveform renderer combines the low , mid and high values to calculate the total amplitude: combined = sqrt(low^2+mid^2+high^2), apparently based on the assumption that this value will be close to the all value. This is unfortunately not the case. I plotted all (x axis) against combined values (y axis):

Screenshot 2023-10-21 at 22 00 08

In the best case, they are equal, but generally the combined value is lower. I don't know how the low, mid and high values are calculated but clearly not in a way that makes the above assumption hold.

So the obvious question is: why don't we use the all value for the amplitude that we draw, and the low, mid and high only to calculate the color? Because with the current implementation, the amplitude adapts to the low, mid and high gains, which is really nice.

Now, I think I have a way to improve this, I will try something and let you know.

@ronso0
Copy link
Member Author

ronso0 commented Oct 21, 2023

Thanks for looking into this!

@m0dB
Copy link
Contributor

m0dB commented Oct 21, 2023

[removed a comment, i want to double check something]

@m0dB
Copy link
Contributor

m0dB commented Oct 21, 2023

I have generated another plot, based on more data.

Screenshot 2023-10-22 at 00 31 35

Furthermore, I see that the amplitude as drawn is scaled at 0.575 times the scaling of the simple waveform (again, this comes from the legacy code). Correcting that should already bring the amplitudes much, much closer.

But I also see the reason for this factor. The range of the low, mid, high and all is 0..255. So, in the simple waveform, the drawing scale is halfBreadth / 255. (halfBreadth = half the widget height).

In the case of combining low mid and high with combined = sqrt(low^2+mid^2+high^2) , the maximum value of combined is sqrt(255^2+255^2+255^2) =~ 440, and that is what we are scaling with, halfBreadth / 440.

Now, I have to say, I personally like to have a bit of headroom in the drawing. But the way that occurs now doesn't seem to be intentional. In fact, it all seems a bit flawed, conceptually.

@m0dB
Copy link
Contributor

m0dB commented Oct 22, 2023

I came up with a simple solution, without having to change the code much.

#12205

@m0dB
Copy link
Contributor

m0dB commented Oct 22, 2023

And with that I discovered the "visual gain" spinbox in the preferences, something I never needed before 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants