-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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 createTCO method on some classes #5699
Conversation
Classes that inherit from "Track", also inherit the createTCO method. That method takes a MidiTime position as an argument, but except on the class SampleTrack that argument was ignored. That lead to unnecessary calls to TCO->movePosition after creating a TCO in many parts of the codebase (making the argument completely redundant) and even to a bug on the BBEditor, caused by a call to createTCO that expected the position to be set on the constructor (see issue LMMS#5673). That PR adds code to move the TCO to the appropriate position inside the constructor of the classes that didn't have it, fixes the code style on the SampleTrack createTCO method and removes the now unneeded calls to movePosition from source files on src/ and plugins/. On Track::loadSettings there was a call to saveJournallingState(false) followed immediately by restoreJournallingState() which was deleted because it's redundant (probably a left over from copying the code from pasteSelection?).
🤖 Hey, I'm @LmmsBot from github.com/lmms/bot and I made downloads for this pull request, click me to make them magically appear! 🎩
Linux
Windows
macOS🤖{"platform_name_to_artifacts": {"Linux": [{"artifact": {"title": {"title": "(AppImage)", "platform_name": "Linux"}, "link": {"link": "https://10215-15778896-gh.circle-artifacts.com/0/lmms-1.2.3-763%2Bge8be73a-linux-x86_64.AppImage"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/10215?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}], "Windows": [{"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://10219-15778896-gh.circle-artifacts.com/0/lmms-1.2.3-763%2Bge8be73aea-mingw-win32.exe"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/10219?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}, {"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://10216-15778896-gh.circle-artifacts.com/0/lmms-1.2.3-763%2Bge8be73aea-mingw-win64.exe"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/10216?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}, {"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/p3bd8t271fmkw3e4/artifacts/build/lmms-1.3.0-alpha-msvc2017-win32.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/36182039"}, {"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/185itjdtjduvm908/artifacts/build/lmms-1.3.0-alpha-msvc2017-win64.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/36182039"}], "macOS": [{"artifact": {"title": {"title": "", "platform_name": "macOS"}, "link": {"link": "https://10217-15778896-gh.circle-artifacts.com/0/lmms-1.2.3-763%2Bge8be73aea-mac10.13.dmg"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/10217?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}]}, "commit_sha": "b9fe497a74c898c678f2cf7e6d9b8b7d1d098fcd"} |
This commit reorganizes the code a little bit to make it better suited for review. The code that checked whether a selection can be merged was extracted to a separate method called TrackContentObjectView::canMergeSelection(). Two conditionals inside that code were merged into a single one, since they both resulted in the same action. Also updated a comment next to a line of code that is probably going to be removed after the PR LMMS#5699 is merged (it's currently necessary because of a bug that is fixed on that PR).
Code LGTM, one minor formatting concern. Do you have any test cases in mind for testers? |
As for testing cases, I'd say all operations that involves creating TCOs, but more specifically the ones which causes calls to
|
Fixes code style issues on some files (except for ones where the current statements already had a different code style. In those the used code style was kept for consistency).
Fixes code style issue on the parameter name of createTCO, where _pos was supposed to be just pos. The existing code had the old style and I ended up replicating it on the other methods.
Resolves merge conflict introduced by latest master commit.
Fixes code style in the changed lines.
Fixed the merge conflict and the code style on the changed lines of the code. |
I'll run some tests later in the day. I'll edit this comment with the results. Testing ResultsI tested based on the guidelines you provided for testing here. Here's what I found:
I think these are just some quick fixes, and unless something else pops up, this PR will probably be done soon. |
Thanks for the detailed testing man! I'm not sure about that Shift+Enter crash you experienced, couldn't replicate it here. But I'd say it's very likely unrelated. This code only changes the As for the dragging selection behavior, this was present before this bugfix. I looked briefly at the code and I think it could be fixed by adding The |
The MSVC issue is unrelated to this PR, see #5683. |
@superpaik Thanks for testing! First issue is actually an intended behavior of the drag&drop operation, you can't drag&drop a TCO on itself, so it snaps it to the closest neighbor position. Dragging to any other position should work as intended though. Second issue (with LMB+Ctrl) is probably related to the SongEditor handling of mouse and keyboard events, would have to check the code to be sure. But it's unrelated to this PR. The third one, is a bit trickier to explain. Notes on the BBEditor are different from the notes we add at the piano roll. They have a "negative" length if I'm not mistaken. It's a way of LMMS knowing that it should play the sample until it ends (instead of cutting it when the note ends). So when you drag a track from the BBEditor back to the SongEditor, a grey clip shows up because the paint event of the clip probably doesn't handle those special notes. They are there, but you can't see them on the song editor (if you open the piano roll they will show as very tiny notes). I don't know if there are plans to moving towards another way of representing those special notes, but for now it can get a bit confusing to the user at first when we start mixing BBEditor notes with SongEditor ones. |
Here's what I meant by my BB finding: Please note, however:
|
@russiankumar I read the code a little further, and it seems to be purposeful behavior as seen on
The TCOs from a track are only kept if they all fit perfectly within the BBTrack layout of TCOs. That means that the number of TCOs has to match the number of BBTracks and they must be perfectly lined. When you have a second TCO, because you only have one BBTrack it considers the last TCO to be a deal breaker and just removes both. If you have two BBTracks on the other hand (and make sure you have both TCOs aligned in the position necessary for them to fit the BB layout) this drag and drop operation should keep them. |
Alright, since it is intended, I think we should leave it as is. Didn't even know this was a thing before xD. All that's left is to add the check that you mentioned you would add for the negative position bug, and this is good to go! |
Ok. I tend to use the MSVC version because of the size of the .exe (mingw exe is three times bigger than MSVC). I will take it into account for future tests. Thanks. |
There was a bug (already present before this PR) where dragging a selection before MidiTime 0 would result in some TCOs being placed on negative positions. This PR fixes this bug by applying the following changes: 1) TrackContentObject::movePosition now moves the TCO to positions equal or above 0 only. 2) Because of the previous change, I removed the line that calculated the max value between 0 and the new position on TrackContentObjectView::mouseMoveEvent when dragging a single TCO (and added a line updating the value to the real new position of the TCO so the label displays the position correctly). 3) Unrelated to this bug, but removed an unnecessary call to TrackContentWidget::changePosition on the left resize of sample TCOs because it will already be called when movePosition triggers the positionChanged signal. 4) Added some logic to the TrackContentWidget::pasteSelection method to find the left most TCO being pasted and make sure that the offset is corrected so it doesn't end up on a negative position (similar to the logic for the MoveSelection action). 5) Removed another line that calculated the max between 0 and the new position on Track::removeBar since it's now safe to call movePosition with negative 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.
Recent changes look good, except for one that I don't really understand what it's for. One if statement that can be a max() call instead.
Tested this because I was a bit concerned that it might block individual clips rather than the group (i.e. lose offsets if you move a selection left after it hits the start), but both pasting and dragging still seem to respect offsets. Left a new code review as well. |
As suggested by Spekular, we use std::max instead of a conditional statement to correct the value of offset if it positions a TCO on a negative position.
I realise that I'm already late 😅 but I've done a test, the functional part of it works. I've already approved the code. LGTM to me after you settle the review Spekular left. You can close #5768 when this is merged, or I can do it myself. |
After the bug fix from LMMS#5699, there's no need to call movePosition on a TCO that was created with a position on its constructor. The line that called movePosition was removed. Code style was also fixed.
* Fixes createTCO method on some classes Classes that inherit from "Track", also inherit the createTCO method. That method takes a MidiTime position as an argument, but except on the class SampleTrack that argument was ignored. That lead to unnecessary calls to TCO->movePosition after creating a TCO in many parts of the codebase (making the argument completely redundant) and even to a bug on the BBEditor, caused by a call to createTCO that expected the position to be set on the constructor (see issue LMMS#5673). That PR adds code to move the TCO to the appropriate position inside the constructor of the classes that didn't have it, fixes the code style on the SampleTrack createTCO method and removes the now unneeded calls to movePosition from source files on src/ and plugins/. On Track::loadSettings there was a call to saveJournallingState(false) followed immediately by restoreJournallingState() which was deleted because it's redundant (probably a left over from copying the code from pasteSelection?). * Fix code style issues Fixes code style issues on some files (except for ones where the current statements already had a different code style. In those the used code style was kept for consistency). * Fixes more code style issues * Fixes code style issues on the parameter name Fixes code style issue on the parameter name of createTCO, where _pos was supposed to be just pos. The existing code had the old style and I ended up replicating it on the other methods. * Code style fixes Fixes code style in the changed lines. * Fixes bug with dragging to negative positions There was a bug (already present before this PR) where dragging a selection before MidiTime 0 would result in some TCOs being placed on negative positions. This PR fixes this bug by applying the following changes: 1) TrackContentObject::movePosition now moves the TCO to positions equal or above 0 only. 2) Because of the previous change, I removed the line that calculated the max value between 0 and the new position on TrackContentObjectView::mouseMoveEvent when dragging a single TCO (and added a line updating the value to the real new position of the TCO so the label displays the position correctly). 3) Unrelated to this bug, but removed an unnecessary call to TrackContentWidget::changePosition on the left resize of sample TCOs because it will already be called when movePosition triggers the positionChanged signal. 4) Added some logic to the TrackContentWidget::pasteSelection method to find the left most TCO being pasted and make sure that the offset is corrected so it doesn't end up on a negative position (similar to the logic for the MoveSelection action). 5) Removed another line that calculated the max between 0 and the new position on Track::removeBar since it's now safe to call movePosition with negative values. * Uses std::max instead of a conditional statement As suggested by Spekular, we use std::max instead of a conditional statement to correct the value of offset if it positions a TCO on a negative position.
* Fixes createTCO method on some classes Classes that inherit from "Track", also inherit the createTCO method. That method takes a MidiTime position as an argument, but except on the class SampleTrack that argument was ignored. That lead to unnecessary calls to TCO->movePosition after creating a TCO in many parts of the codebase (making the argument completely redundant) and even to a bug on the BBEditor, caused by a call to createTCO that expected the position to be set on the constructor (see issue LMMS#5673). That PR adds code to move the TCO to the appropriate position inside the constructor of the classes that didn't have it, fixes the code style on the SampleTrack createTCO method and removes the now unneeded calls to movePosition from source files on src/ and plugins/. On Track::loadSettings there was a call to saveJournallingState(false) followed immediately by restoreJournallingState() which was deleted because it's redundant (probably a left over from copying the code from pasteSelection?). * Fix code style issues Fixes code style issues on some files (except for ones where the current statements already had a different code style. In those the used code style was kept for consistency). * Fixes more code style issues * Fixes code style issues on the parameter name Fixes code style issue on the parameter name of createTCO, where _pos was supposed to be just pos. The existing code had the old style and I ended up replicating it on the other methods. * Code style fixes Fixes code style in the changed lines. * Fixes bug with dragging to negative positions There was a bug (already present before this PR) where dragging a selection before MidiTime 0 would result in some TCOs being placed on negative positions. This PR fixes this bug by applying the following changes: 1) TrackContentObject::movePosition now moves the TCO to positions equal or above 0 only. 2) Because of the previous change, I removed the line that calculated the max value between 0 and the new position on TrackContentObjectView::mouseMoveEvent when dragging a single TCO (and added a line updating the value to the real new position of the TCO so the label displays the position correctly). 3) Unrelated to this bug, but removed an unnecessary call to TrackContentWidget::changePosition on the left resize of sample TCOs because it will already be called when movePosition triggers the positionChanged signal. 4) Added some logic to the TrackContentWidget::pasteSelection method to find the left most TCO being pasted and make sure that the offset is corrected so it doesn't end up on a negative position (similar to the logic for the MoveSelection action). 5) Removed another line that calculated the max between 0 and the new position on Track::removeBar since it's now safe to call movePosition with negative values. * Uses std::max instead of a conditional statement As suggested by Spekular, we use std::max instead of a conditional statement to correct the value of offset if it positions a TCO on a negative position.
Classes that inherit from
Track
, also inherit thecreateTCO
method. That method takes a MidiTime position as an argument, but except on the classSampleTrack
that argument was ignored. That lead to unnecessary calls toTCO->movePosition()
after creating a TCO in many parts of the code base (making the argument completely redundant) and even to a bug on the BBEditor, caused by a call tocreateTCO
that expected the position to be set on the constructor (see issue #5673 ).That PR adds code to move the TCO to the appropriate position inside the constructor of the classes that didn't have it, fixes the code style on the SampleTrack
createTCO
method and removes the now unneeded calls tomovePosition
from source files on src/ and plugins/. OnTrack::loadSettings
there was a call tosaveJournallingState(false)
followed immediately byrestoreJournallingState()
which was deleted because it's redundant (probably a left over from copying the code from thepasteSelection
method?).