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

Fixes newly added tracks in BB having wrong size #2883

Merged
merged 1 commit into from Jul 5, 2016

Conversation

Stephen-Seo
Copy link
Contributor

This PR is technically a continuation of #2880 , with better fixes made as suggested by @jasp00 .

This bug is mentioned in issue #2476 .

@@ -125,6 +125,55 @@ void Pattern::init()

changeLength( length() );
restoreJournallingState();
Copy link
Member

Choose a reason for hiding this comment

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

init() is also run for the copy constructor, which is correctly initialized. This code should only run for the other constructor and before ensureBeatNotes(), thus before init().

@Stephen-Seo
Copy link
Contributor Author

OK, I've taken the notices from jasp00 and made a fix that should be correct in execution and design. Hopefully this will be the last revision but I am still open to notices and flaws about the code. Many thanks, jasp00!


// Resize this track to be the same as existing tracks in the BB
// Only if there already exists at least another track in the BB
const TrackContainer::TrackList & tracks = m_instrumentTrack->trackContainer()->tracks();
Copy link
Member

Choose a reason for hiding this comment

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

Try to limit line lengths to 80 characters (coding conventions).

@jasp00
Copy link
Member

jasp00 commented Jul 2, 2016

Do not spend too much time with commit messages because you should squash commit history later.

@Stephen-Seo
Copy link
Contributor Author

The reason why I check if "currentTCO" is in bounds, is that when another BB is added, the TCO for that BB doesn't yet exist for the tracks during execution of Pattern's constructor. Since the newly added BB will always have the default length, it is better to check if the "currentTCO" is in bounds and not change "m_steps" if it isn't.

@Stephen-Seo
Copy link
Contributor Author

If I ignore bounds checking for "currentTCO", I get a "called Track::getTCO( 3 ), but TCO 3 doesn't exist"

@Stephen-Seo
Copy link
Contributor Author

If you are satisfied with the current changes, then I will sqash commit history, but until then I will keep on refactoring.

m_instrumentTrack->trackContainer()->tracks();
for(unsigned int trackID = 0; trackID < tracks.size(); ++trackID)
{
if(tracks.at(trackID)->type() == Track::InstrumentTrack &&
Copy link
Member

Choose a reason for hiding this comment

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

You should break on this condition. The reference track should be before the current track, not after. Then, you can remove the bounds check for currentTCO. It should look like:

if(type)
  if(not same track)
    update steps
  break

@tresf
Copy link
Member

tresf commented Jul 2, 2016

Let's please stop with the 80 character requirement. It just makes the code ugly. I realize the wiki offers it as a recommendation, but there's very little benefit in enforcing it anymore.

@Stephen-Seo
Copy link
Contributor Author

Stephen-Seo commented Jul 3, 2016

I usually had used "set expandtab", "set tabstop=4" and "set shiftwidth=4" in my vim config.
I knew to disable "set expandtab" to avoid mistabbing things but didn't realize that they count for 8 spaces. The fix should be good now?

Also, is it safe to squelch commits into one commit within the bb_bugfix branch or will I need to do it in a new branch and a new PR? (I won't be doing it until it's truely fixed.)

@jasp00
Copy link
Member

jasp00 commented Jul 3, 2016

The fix is good. You can squash commits within the bb_bugfix branch. Try git rebase -i HEAD~10 (10 commits).

@tresf
Copy link
Member

tresf commented Jul 3, 2016

The fix is good. You can squash commits within the bb_bugfix branch. Try git rebase -i HEAD~10 (10 commits).

FYI, @jasp00 GitHub provides a "Squash and merge" button now.

screen shot 2016-07-03 at 11 36 30 am

@Umcaruje
Copy link
Member

Umcaruje commented Jul 5, 2016

Tested this out, works beautifully.
The only thing is that the new track is always the same size as the first track. Now, you can edit out the first track's length using the context menu, and every new track would have that new length, despite all the other tracks having a different length.

But I don't see this is as an issue, and also making the new track adding system more "intelligent" probably isn't worth it, and in most cases this fix works like a charm. So this gets a 👍 from me for a merge.

@tresf tresf merged commit 652aa5e into LMMS:master Jul 5, 2016
@jasp00
Copy link
Member

jasp00 commented Jul 6, 2016

TBH @Umcaruje, I did not notice patterns could be changed individually. In this case, the default number of steps could be saved in BB tracks, as suggested by @Stephen-Seo.

@Spekular
Copy link
Contributor

Spekular commented Jul 6, 2016

I don't really think it's necessary to have different lengths for different samples, so maybe the context menu action should be removed or changed to affect all samples

sdasda7777 pushed a commit to sdasda7777/lmms that referenced this pull request Jun 28, 2022
Fixes newly added tracks in BB having wrong size
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants