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
Remove explicit time calculations from Song and TimeLineWidget #3701
Remove explicit time calculations from Song and TimeLineWidget #3701
Conversation
Good. Could you also fix two more places where |
Coding conventions looks inconsistent a little bit but isn't wrong. |
Add a method to convert a MidiTime instance to milliseconds. Also add a static method to MidiTime that computes the time in milliseconds for a given number of ticks and a tempo. Remove the method that sets the milliseconds explicitly from Song. Replace it by a method that takes a MidiTime instance and one method that takes an amount of ticks. Remove several explicit time calculations from the implementation of Song and TimeLineWidget. Instead use the new methods.
cce7db3
to
d398c12
Compare
@PhysSong Good catch! I had also checked the file for other occurrences (searching for "48" but somehow it did not occur to me that I can replace two more calls by using on of the methods that I had just added. I have removed two more calls and squashed the two commits into one. |
@michaelgregorius You don't need to squash commits manually. They can be squashed when PR is merged. |
@PhysSong The main reason for squashing the commits yourself, the way I see it, is to have control of the final commit message. If someone else does it for you, which is a risk at places like this, they may just press merge and all the commit messages will be automatically stacked one after the other. |
I'm going to fix #2112. When I finish my work, I'll make a pull request against stable-1.2 and my PR needs this fix. Is it okay to rebase to stable-1.2 and change the base branch? |
If this bug is not new to 1.2, it shouldn't be targeted at 1.2. We are trying to freeze the codebase. |
@tresf Seems like we posted at the same time. |
Though it isn't a new bug and changes the codebase, it doesn't make something unstable or change the codebase a lot. Moreover, it is a bug fix. |
I still don't see a compelling reason to merge this into stable. This code is called all over the place, I'd rather not change it at the RC4 state so close to release. |
Okay. Go to master. |
inline int getMilliseconds() const | ||
{ | ||
return m_elapsedMilliSeconds; | ||
} | ||
inline void setMilliSeconds( float ellapsedMilliSeconds ) |
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.
I prefer leaving setMilliSeconds()
to removing, but it's not bad. We can add this again when needed.
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.
@PhysSong Yes, we can always add it back if needed. However, for now it look like the milliseconds are rather an internal representation of the Song
class and that other client "think" in different times, e.g. MidiTime
.
Time display is not changing during playing anymore with this change. Time only changes when you click somewhere on timeline but not during playing. |
I see this too. I've compiled both with and without debug flags. |
I haven't tested yet, but I will fix it if I can reproduce. |
I can't answer for @michaelgregorius but why not leave him some time to respond? I'm pretty sure he knows what's up with this one already. |
@zonkmachine I think @michaelgregorius can fix it. However, I haven't seen this after my work for #2112. |
m_elapsedMilliSeconds += | ||
( ( framesToPlay / framesPerTick ) * 60 * 1000 / 48 ) | ||
/ getTempo(); | ||
m_elapsedMilliSeconds += MidiTime::ticksToMilliseconds( framesToPlay / framesPerTick, getTempo()); |
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.
I think this line caused bug. framesToPlay / framesPerTick
isn't an integer and smaller than 1.
Possible fix is: change
double MidiTime::ticksToMilliseconds(tick_t ticks, bpm_t beatsPerMinute)
to
double MidiTime::ticksToMilliseconds(double ticks, bpm_t beatsPerMinute)
.
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.
Or adding MidiTime::framesToMillisecond(frame_t ticks, const float framesPerTick, bpm_t beatsPerMiute)
?
Tested, fixed! The somewhat spooky thing is that I actually started a review and the action around the timeline was the only thing I got around to test and still I didn't spot it... :/ |
@zonkmachine Thanks for testing! Seems to have been quite some elusive bug then. I think I only tested whether the play head moves or not. |
Removes some explicit time calculations from
Song
andTimeLineWidget
as part of #3284. See this comment.