Select>More... does not select notes on "Same beat" of short measures

• Sep 9, 2020 - 04:38
Reported version
3.5
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MuseScore

In the attached file, select the first four measures with notes in them.
*Right click a note (beat 1 or 2 to see the bug) in measure 1 or 4 (as reported in the status bar)
*Choose Select>More...
*Check Same Beat and In selection
*Click OK

Result The notes in only measures 1 & 4 are selected

Select the same measures and select a note in m 2 or 3.

Result only notes in m 2 & 3 are selected.

Repeat the above procedure on mm6-10 (choose beat 1 since m7 only has one beat)

Result The notes in mm6, 7, 9 & 10 are selected but not in m8

It seems that the presence of a time signature fixes the bug.

This only happens in short measures from my testing. When I put extra beats in the measures the bug is not seen.

Attachment Size
More same beat bug.mscz 6.4 KB

Comments

• Sep 9, 2020 - 09:28
Status active ⇒ PR created

Thanks much for this issue. After some testing, I've fixed the problem. Any further testing on your part is much appreciated but it should be fine:

https://github.com/musescore/MuseScore/pull/6547

I also learned something interesting about MuseScore in the process:

Let's say you have a 4/4 measure and you split it in the middle. I would've imagined the result would be 2/4, but no! What MS does is reduces the fraction and you get a 1/2 measure! This is where the problem was mainly. Internally, each beat gets a certain amount of ticks. If a beat were to consist of 100 ticks, in 4/4 there'd be 400 ticks. In my line of thinking, splitting in half the measure would result in 2/4 where two quarter notes would each be 100 ticks for a total of two beats, 200 ticks. But no. The measure becomes 1/2 and there's only one beat and one beat becomes equivalent to 200 ticks. This is what the problem was while checking between the size of beats based on ticks. Hopefully there's no further problems with the Similar Beat filter.

P.S. Mike320's measures here that have two quarter-notes look like the second note would be on beat 2 but it actually is beat 1.5 as shown in the status bar because of the 1/2 and not 2/4 implicit Actual Measure duration. That threw me off for a moment,... so you gotta be careful.

Reply

• Sep 9, 2020 - 13:58

It sounds like the bug is in the fraction code rather than the More... code. I'm not sure what you code fixes. When @theotherjthistle first got fraction code merged he asked if fraction reductions would cause problems anywhere and this is a case we never considered.

It sounds like the bug is actually in the split measure code that should give you a 2/4 measure rather than 1/2 measure. I realize this can be a complicated mess since the numerator is always a whole number. Splitting a 4/4 measure on the upbeat of 2 (beat 1.5) will cause the split to be 3/8 and 5/8 rather than 1.5/4 & 2.5/4. In my view, the code should simply not reduce the fractions since there is nothing we can really do about the 1.5 & 2.5 split.

Reply

• Sep 9, 2020 - 18:16

Hey Mike, have you tried building the issue and testing it out to see what happens? It seems to work fine over here. Previously I hadn't consider reduction of fractions in the first iteration of the code. Although the bug may be in the split measure code more generically, and I wouldn't dispute that since in a sense it's a separate issue which in turns affects this situation, but reducing the fraction helps a beat equivocation check since I'm not using floating point equivocation checks from division and there's not already a simple quick way to just get the beat in the form of a floating point like "1.5" from what I can tell.

For example, if the beat is 1.5 that we'd use for Select All Similar, and there are 480 ticks per beat, then we get something like this

([480*1]+240)/480 which is 720/480 for the fraction of ticks (240 = half a beat in ticks)

Now if we split the measure, assuming it was 4/4, MS jumps up the number of ticks per beat to 960. Why? (480 * 4 beats) is 1920 ticks. If it splits this not into 2/4 but 1/2, then it needs the same "amount of ticks" in two beats: 1920 in 2 beats means one beat ends up being 960, not 480. That's to say, in computation, we have ([960*1]+480/960) which is 1440/960.

Now in checking for similar "beat", we're checking 720/480 == 1440/960 which are not equivalent in literal terms of checking numerator and denominator as separate entities which is what I was doing in some sense before, because i never imagined that there'd be a change in ticks per beat in the process.

But if we reduce these into a more "abstract" fraction, then we'll get something that will equivocate on a test and it'll work as the user should expect. I hope that makes sense. Even if we fixed up the split measure code, i think the fraction reduction is a pretty decent safe guard "just in case" either way.

Reply

• Sep 9, 2020 - 18:39

The fact that a 2/4 measure reports the second of 2 quarter notes as being on beat 1.5 because the fraction got reduced is a problem. Selecting this should report you have selected beat 2. When a measure is split, the current time signature should be taken into account as to weather the resulting fractions is reduced if possible. If the time sig had been 2/2, then the result of 1/2 would be expected and all would have been fine. I think there is more to it than this though.

I first discovered the problem in a 5/4 measure that was split. The 2 beat part of the measure was reduced to 1/2 and only that one didn't select the proper beat. This case reinforces my assertion that there is a bug in reducing the time signature.

I don't build MuseScore. My programming skills are such that the entire development environment stresses me out too much so I only test pre-built versions. BTW, if you put an artifact on github and point me to it, I'm always happy to test your PRs. I trust you that the More... issue is fixed. Perhaps I should do another issue report for the split measure issue and cross reference it here to assure that fix doesn't break this fix. I personally can't think of any other situation where not reducing the fraction in a split measure might cause a problem.

Reply

• Sep 9, 2020 - 19:37

Yeah, I agree that a bug report should be filed for the measure split. It really shouldn't be reducing Actual Measure Duration to something like 1/2 instead of 2/4. My guess is that whoever implemented it thought it was a good idea to do a reduction of fractions for the "actual" duration of measures no matter what. At first glance that makes sense, but upon further reflection you end up with an issue like this.

For what it's worth though, this PR I made will get your test cases working for the most part, so long as it's not an actual beat discrepancy due to the reduction of time signatures/actual duration. Like, the first beat will select in all of the measures no matter what as compared with before. And until someone fixes the split measure reduction of "actual measure duration", this will do for that sort of thing. It won't, of course, fix the fact that what appears to be [beat 2] is actually [beat 1.5] in some instances like a measure with "Actual Duration" being 1/2 or whatever. But again, even after Split Measures is fixed up (hopefully soon), in my estimation the change in this PR shouldn't negatively affect anything. Either way, it's decent that we found an issue here having to do with Split Measures. If you ask me, there's always seemingly something funky going on with Split Measures changing something up in the past from my own personal experience. Lots of customizations lost etc.

In the meantime, if it really mattered, manually altering the "Actual Durations" of split measures sounds like the workaround for now when "beat" information is important.

Reply

Fix version
3.6.0