-
-
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
Beat note bug at the end of bars #2964
Beat note bug at the end of bars #2964
Conversation
I mean more logical for notes in a BBTrack. Just an experiment... |
It's really a bit tricky this one with BBTrack vs. InstrumentTracks. Maybe, instead of checking the pattern type , it would be better to let the deciding factor of how the pattern is played back be the track type. If it's played from within a BBTrack it loops like this PR and if it's played from an instrument track the beat notes loops like the first commit while ordinary notes creates a wider space if they go over the the beat? |
👍 I really like this solution. Feels really natural and also fixes the original problem. I was fearing a note extending to the next bar that gets cut off at the end of a loop wouldn't ever get a noteoff, but this is not the case, the note plays out for its length and works perfectly, tested with zyn and VST's too. |
And I was fearing it would just add to the volume and get noisy... and weeellll it can do. I've mostly sorted the backward compatibility but will split this into two parts. The bug fix separate and then the change in behaviour which needs a discussion. |
a7e8aa1
to
edca72b
Compare
Here is the fix for #1105 |
I think the backwards support should be handled in Datafile::Upgrade, if possible |
I'll look into Datafile::Upgrade, and also I think I've found a way to make it not so ridiculously long... |
I will have a look at #2969, it should be fixed first for the upgrade. |
I suggest to postpone this PR to 1.3 . |
OK. I'll look into it again. |
Looking at it now. It seems like there is more than an upgrade function needed here. 🪲 |
Right. In #3037 setting "len" was dropped and this holds the length of the beat so I have to read in "len" and convert it to "steps" directly. |
@jasp00 ^Since we don't know for sure what the time signature will be, as this could either be changed manually or automated, I don't think I can do the upgrade in DataFile.cpp as I'm working on now. |
There is a design problem: it does not make sense to update patterns with time signatures on playback. If you change the signature, you break the pattern; each pattern should have its own signature. |
src/tracks/Pattern.cpp
Outdated
MidiTime oldLength = MidiTime( _this.attribute( "len" ).toInt() ); | ||
|
||
tick_t max_length = MidiTime::ticksPerTact(); | ||
int oldSteps = m_steps; |
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.
const int oldSteps = m_steps;
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.
Thanks, but if you follow the thread you will see that this is old code that's going to change completely. Also, I use the tag In progress
for stuff that isn't really ready for review.
edca72b
to
188cdac
Compare
@jasp00 I haven't given up on the DataFile.cpp upgrade path for this one. I'm just reverting to the original commit for now. |
Oh brother! |
188cdac
to
7a7587c
Compare
src/core/DataFile.cpp
Outdated
@@ -898,6 +899,25 @@ void DataFile::upgrade_1_1_91() | |||
el.setAttribute( "arpdir", "3" ); | |||
} | |||
} | |||
|
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.
This should be in it's own upgrade function, right?
void DataFile::upgrade_1_1_91()
What's the new upgrade function called _1_1_92()
? _1_2_0_rc3
?
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.
_1_2_0_rc3
Yes, 1.2.0-rc3
will be the next release assuming the fix is that specific. If it's only a regression since 1.1.x
, it's preferred to keep it in the existing 1.1.91
section.
a3d493b
to
62c8700
Compare
@tresf I think I'm done here. The bug in question, actually I think it's a feature that just didn't cut it, goes way back. Before 1.0 . |
Merge? |
src/core/DataFile.cpp
Outdated
QDomElement el = list.item( i ).toElement(); | ||
for( int i = 0; !list.item( i ).isNull(); ++i ) | ||
{ | ||
patternLength = el.attribute( "len" ).toInt(); |
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.
Do all "pattern"
attributes contain an integer value (never blank?). We just need to make sure we sanitize our input. I think this change is fine, but any time we assume a String is an integer we need to make sure we don't segfault on something simple.
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.
Nice catch. I'll test it some more with:
if( el.attribute( "len" ) != "" )
{
patternLength = el.attribute( "len" ).toInt();
steps = patternLength / 12;
el.setAttribute( "steps", steps );
}
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.
Pushed a fix. With or without this the projects open up just like before. If I create some len="" in a .mmp the results are a bit buggy so I think that indicates there probably are no blank "len".
But that doesn't compare to testing real project files and they come out just fine. I don't know how to devise a good test case for this.
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.
If I create some len="" in a .mmp the results are a bit buggy so I think that indicates there probably are no blank "len".
That was my suspicion as well but I wanted to mention it as I'm not sure how they're stored for all use-cases.
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.
OK. I have no more tests do do here but as it changes the behaviour of a central tool maybe leave it up for a while before merge. Is it too optimistic to think that someone is going to bother to take it for a spin? We have quite a list of pull requests to go through. :)
f410d05
to
70250a2
Compare
I'm going to wait with merging this for the outcome of the discussion on upgrade methods here. |
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.
Please don't wait. The comments in that bug report have to do with automating the versioning. Your logic is solid regardless of the outcome of that discussion.
src/core/DataFile.cpp
Outdated
@@ -901,6 +901,32 @@ void DataFile::upgrade_1_1_91() | |||
} | |||
|
|||
|
|||
void DataFile::upgrade_1_2_0_rc3() | |||
{ | |||
// Upgrad from earlier bbtrack beat note behaviour of adding |
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.
typo, Upgrade
70250a2
to
9fe2dd7
Compare
OK. Merge... |
Fixes #1105
I had a go at fixing the problem with beat notes on position near the end of the beat forcing the insert of an extra bar.
I also tweaked the Piano Roll notes to not do the same depending on where they end but on the start position. To me that's more logical behaviour.Edit2: This is now a pure fix for #1105 and the rest is edited out and will be a separate PR.