Beat and bassline bug #5673
Comments
|
Looking at your screenshot I assume you are using the 1.2.2 Appimage.
Can you reliably reproduce the bug? If so, could you please detail the steps to reproduce it? You could also share a project file. |
|
I think this is mentioned somewhere else. A method to make empty Beat/Bassline tracks is to delete all beat bassline instances in the Song Editor. Existing tracks in the Beat/Bassline will then go blank. Sounds like you managed to do it in some other way. |
SecondFlight
added
the
response required
|
I've been trying to duplicate it but nothing has been showing.... |
no-response
bot
removed
the
response required
|
What I remembered what I did when this happened, I accidentally pressed the add sample track button. Then removed it and pressed the automation track and figured I'd mess with the pitch |
|
I have experienced something similar by doing the following steps (I described it on my PR because at first I thought it could be related to it but then realized it was not):
Could it be you did something similar, like dragging an instrument that already had TCOs to the BB Editor before cloning? I'm still not sure what causes this bug, but could anyone check if they can reproduce it by following those steps? |
|
Afaik, all BB Tracks share the same tracks, and what differs a BB pattern from another is the TCO being played/visualized. Something like this: Trying to do some debugging I found out that the Kicker track on the default project had 2 TCOs instead of 1, which I'd expect since the default project only has 1 BBTrack at first. I think that could be related to the bug, but that's as far as I went into investigating it. |
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?).
|
Could everyone that managed to experience this bug try to reproduce it on the build from PR #5699 ? I think I accidentally found the reason behind the bug and fixed it there. The method that creates TCOs expects a position as an argument but in many classes it didn't actually place the TCO on the position given. That went unnoticed everywhere else because every time a TCO was created there was an explicit call to That PR should fix it but it needs testing. |
|
I got the issue again, this time I recorded it! here's the project file I had to zip them because github don't allow mp4/blend files |
|
I reloaded the file and it automatically solved it? |
* 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 #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.
|
@Spekular I believe so, the only steps I had to reliably reproduce this bug now work properly with the |
* 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.
There's a bug where a instrument in beat and bassline has automation and the tracks above that instrument become hidden and un-editable.
I was making pitch adjustments when I noticed this
The text was updated successfully, but these errors were encountered: