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

make scaling of GLSL RGB and RGB L/R waveform amplitudes consistent with simple waveform #12205

Merged
merged 4 commits into from
Nov 25, 2023

Conversation

m0dB
Copy link
Contributor

@m0dB m0dB commented Oct 21, 2023

As pointed out by @ronso0 in #12115 , the amplitudes of the waveform rendering is inconsistent between waveform types. I discuss the cause there.

This PR fixes the scaling, so the waveform amplitudes are the same as the simple waveform (when gains are 0), while still maintaining the adaptation of the waveform amplitude to the low/mid/high gains, by scaling the amplitude as drawn with the ratio between the low+mid+high magnitude with gains applies and without gains applied.

(Note that the wrong scaling is still present in the legacy waveforms. I will not fix those)

See #12115 for some screenshots that show the issue before this fix. With this fix, compare Simple with RGB and RGB L/R.
simple
RGB
RGBLR

This is RGB and RGB L/R with some gain applied (high and low bands turned down)

RGBgained RGBLRgained

@m0dB
Copy link
Contributor Author

m0dB commented Nov 18, 2023

It would be good to have this merged for 2.4, but it could wait for a 2.4.1 (assuming that is on the road map).

@ywwg
Copy link
Member

ywwg commented Nov 22, 2023

yesssss thank you

Copy link
Member

@ywwg ywwg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for this! I have a couple small questions. Leaving these as comments because I have a bad habit of not following up

maxMid = math_max(maxMid, filteredMid);
maxHigh = math_max(maxHigh, filteredHigh);
// Cast to float
float maxLow = static_cast<float>(u8maxLow);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand why maxLow is a different type than u8maxLow. are we casting from uchar to float because of math max?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, this way we cast only once, rather than casting for every iteration in the for loop in line 148.

DEBUG_ASSERT(linesReserved == m_vertices.size());
DEBUG_ASSERT(colorsReserved == m_colors.size());
DEBUG_ASSERT(reserved == m_vertices.size());
DEBUG_ASSERT(reserved == m_colors.size());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so I guess m_colors and m_vertices are the same size? (do we need to check both these things? This seems like an odd place to enforce this restriction rather than when reserved is calculated)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, they are the same size. we could remove these asserts, it's just to make sure i didn't make a mistake when filling these vectors. but they don't enforce anything, they merly check. and checking doesn't hurt.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Wouldn't it be better to check them back up where reserved is created, then? If there's something wrong with that size, then we will encounter problems before we get to this check.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is being checked with this assert is that the amount of data that we push to the m_vertices / m_colors vectors is correct (in m_vertices.addRectangle and m_colors.addForRectangle), to make sure we reserve exactly the amount we are going to push.

@ywwg
Copy link
Member

ywwg commented Nov 22, 2023

With this change, the waveforms seem over-zoomed at 1.0:

image

Compare to 0.9 zoom:

image

And RGB (not marked legacy) is a lot smaller:

image

@ywwg
Copy link
Member

ywwg commented Nov 22, 2023

my best friend is still the softer / higher rez legacy glsl at 1.5:
image

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just two comments, not yet tested.

Comment on lines +176 to +177
// The maxAll value will be used to draw the amplitude. We scale them according to
// magnitude of the gained maxLow, maxMid and maxHigh values
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit more background info is useful here.
because ....

maxLow *= lowGain;
maxMid *= midGain;
maxHigh *= highGain;

// Calculate the magnitude of the gained maxLow, maxMid and maxHigh values
const float magnitudeGained = std::sqrt(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use only one std::sqrt() if you build the quotient (factor below) before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I understand what you mean here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can make use of the rule:
factor = Sqrt(A)/Sqrt(B) = Sqrt(A/B)
To get rid of one expensive Sqrt call.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, well spotted! i'll make the change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@m0dB
Copy link
Contributor Author

m0dB commented Nov 23, 2023

With this change, the waveforms seem over-zoomed at 1.0:

Yes, I noticed this too, but you will see that happens to the simple waveform as well, so I guess that's "correct"

@ronso0
Copy link
Member

ronso0 commented Nov 24, 2023

Are you sure this is not an issue with the pre-gain?
(didn't test this PR yet, will do asap)

m0dB added 2 commits November 24, 2023 19:16
…naming and use correct range (was double!). TODO: re-add comments and apply to other waveform renderers
Copy link
Member

@ywwg ywwg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This look great! and the /2 fix makes the new waveforms look SO much better. thank you!

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thank you.

@daschuer daschuer merged commit 367c2e4 into mixxxdj:2.4 Nov 25, 2023
12 checks passed
@daschuer daschuer added this to the 2.4.0 milestone Nov 25, 2023
@m0dB
Copy link
Contributor Author

m0dB commented Nov 26, 2023

Thanks for merging @daschuer . I also have fixed the drawing resolution for HSV, Filtered and Simple. I wanted to include that in this PR but I will create a new one.

@m0dB
Copy link
Contributor Author

m0dB commented Nov 26, 2023

#12356

@fwcd
Copy link
Member

fwcd commented Dec 18, 2023

Quick ping here since this seems to be the cause for #12448.

This PR fixes the scaling, so the waveform amplitudes are the same as the simple waveform [...] Note that the wrong scaling is still present in the legacy waveforms. I will not fix those

I think the new scaling makes the waveforms a bit harder to read, e.g. very bass heavy tracks are almost "rectangular" until I turn down the visual gain manually. The old visual gain struck a nice balance by providing some "breathing space" for the waveform IMO.

Perhaps we could do it the other way around and lower the simple waveforms instead?

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

Successfully merging this pull request may close these issues.

6 participants