-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Conversation
…ith and without gains
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). |
yesssss thank you |
There was a problem hiding this 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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
// The maxAll value will be used to draw the amplitude. We scale them according to | ||
// magnitude of the gained maxLow, maxMid and maxHigh values |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Yes, I noticed this too, but you will see that happens to the simple waveform as well, so I guess that's "correct" |
Are you sure this is not an issue with the pre-gain? |
…naming and use correct range (was double!). TODO: re-add comments and apply to other waveform renderers
There was a problem hiding this 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!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Thank you.
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. |
Quick ping here since this seems to be the cause for #12448.
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? |
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.
This is RGB and RGB L/R with some gain applied (high and low bands turned down)