Ottava not correctly processed from 1.3 score
1. Open attached score (produced in 1.3).
Result: Ottava aren't placed correctly in the second line.
2. 'Play'.
Result: Notes 2-4 aren't in the right octave in the second line.
Note: If there are no line breaks, the score will be fine.
Using MuseScore 2.0 Nightly Build (72efce5) - Mac 10.7.5.
Attachment | Size |
---|---|
Ottava not correctly processed from 1.3 score with line breaks.mscz | 1.96 KB |
Ottava not correctly processed from 1.3 score with line breaks.png | 115.86 KB |
Comments
Not sure if line breaks are relevant - they seemed to be at the time.
If you wish to start from scratch:
1. In 1.3, create 5-bar piano score.
2. Enable 'Note Entry'.
3. Enter all the notes.
4. Disable 'Note Entry'.
5. Drag each ottava to the first notehead of each bar.
6. 'Save'.
7. Open in 2.0.
8. 'Play'.
Result: Not all notes sound at the right octave.
Using MuseScore 2.0 Nightly Build (8be90b1) - Mac 10.7.5.
Sometimes I can reproduce this, sometimes I can't. Either way, I'll look at fixing.
https://github.com/musescore/MuseScore/pull/1197
Fixed in ad38f0bc37
Sorry, my fix was not good - broke other things. Need a different approach.
The problem is the initiial ottava had no initial "tick" tag and therefore the was defaulted to a tick of -1 whereas it is actually at tick 0. When the "tick2" came in, this was resulting in the length being calculated 1 too high, so the ottavas overlapped internally.
I thought the missing tick tag was an anomaly, but I guess it happens in other places for other reasons and there is code to calculate the actual tick based on where the spanner occurs in the file. It just isn't working, or isn't being hit, in this particular case. So that's what needs investigation.
But I think the bottom line is, this bug will only affect scores with an ottava starting on the very first note of the score that is immediately followed by a second ottava starting on the note right after where the first ends. And even then, only in cases where the tick of the first ottava didn't get written - I still don't know what triggers that.
So now that I understand a bit more, I'm rather less concerned.
Fixed in 339738f62e
Automatically closed -- issue fixed for 2 weeks with no activity.