-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fixes newly added tracks in BB having wrong size #2883
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
Conversation
@@ -125,6 +125,55 @@ void Pattern::init() | |||
|
|||
changeLength( length() ); | |||
restoreJournallingState(); |
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.
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()
.
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(); |
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.
Try to limit line lengths to 80 characters (coding conventions).
Do not spend too much time with commit messages because you should squash commit history later. |
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. |
If I ignore bounds checking for "currentTCO", I get a "called Track::getTCO( 3 ), but TCO 3 doesn't exist" |
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 && |
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 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
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. |
I usually had used "set expandtab", "set tabstop=4" and "set shiftwidth=4" in my vim config. 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.) |
The fix is good. You can squash commits within the |
FYI, @jasp00 GitHub provides a "Squash and merge" button now. |
Tested this out, works beautifully. 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. |
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. |
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 |
Fixes newly added tracks in BB having wrong size
This PR is technically a continuation of #2880 , with better fixes made as suggested by @jasp00 .
This bug is mentioned in issue #2476 .