Instrument change transposition ignored in scores imported from 2.x
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
So in the older version of Musescore that i used, 2.3.2, when the front ensemble instrument I used went from glock to chimes, the notes would be based off of chime's range, and the notes would be on the staff, but I opened a score that i was using in 2.3.2 in the alphaversion of 3, the note went below the staff, and is based off of the glock's range. but it still plays the chimes soundfont. How can i fix this and if i cant when will it be fixed
Comments
Can you explain how you are changing from a chimes to a glock? At first glance, the notes should be based upon the current instrument, so glock notes should be based upon the glock's range. Since the Glock transposes two octave, switching from Glock to chimes should always cause the notes to be below the staff. What is very confusing is why the sound doesn't change with the instrument.
In reply to Can you explain how you are… by mike320
In musescore 2.3.2, I used MDL Front Ensemble pictograms for instrument changes
for a better look heres the entire part
In reply to for a better look heres the… by Ronan Bodisch
Please attach the actual score for checking (images are not really useful here)
In reply to (No subject) by Ronan Bodisch
It starts at section E and there are some other places to look at also
Please attach the 2.3.2 version of that score too, so we can check where the import goes wrong
In reply to Please attach the 2.x… by Jojo-Schmitz
I don't recall, which is the nature of this element (highlighted) ? Its removal, with the 2.3.2, causes the jump you observe.
There is a lot of "Instrument change" here right? (and the "symbol" seems another one, not sure to fully understand right now)
The involved excerpt, openable with the 2.3.2 (and current 3.0) : Section E.mscz
heres the 2.3.2
The way you are doing this requires the MDL extension. I don't use it, that's why I stopped commenting.
Looks like the note is being displayed at concert pitch even though concert pitch is switched off. Seems the transposition info on the instrument change isn't coming through correctly. Or
You can reproduce this using ordinary instrument change elements, no need for MDL. See for example the attached, which should show "D" in the second measure (concert C as transposed for Bb trumpet) but instead shows C. And yet the key signature is handled correctly, not sure if that is a clue.
Instrument changes created in 3.0 seems to work fine, even across reload.
Will look at this today.
See https://github.com/musescore/MuseScore/pull/4339
In reply to See https://github.com… by Marc Sabatella
The PR was merged. The hook didn't work...
I don't think this fixed the issue.
Using OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4655, revision: 487db7f which was after this was marked as fixed, using instrument_change.mscz made in version 2.3.2 and importing it I get instrument_change_3.mscz which does not place the notes in the correct octave when changing from the bass clarinet to the Bb clarinet.
Problems are worse than that, we get wrong octave in other cases too, and then even worse issues when entering new notes, due to the transposition info for the instrument change itself not coming through properly. Eg, for a change from Bb Trumpet to F horn that already existed in a 2.x score, the notes for horn will display an octave too low in 3.0, and then if you try entering new notes into that passage, they will behave as if it is still trumpet transposition (thus, enter a written D, it sounds as C, and displays as C when you switch to concert pitch).
I believe this worked correctly before and something may have changed recently with how we read the instrument change element in read206 (because this still all works correctly for new scores in my testing).
https://github.com/musescore/MuseScore/pull/4465
I don't know, the cases that don't work now wouldn't have worked with my original fix either, sorry I somehow missed that.
BTW, I think a workaround would be to re-apply the instrument change, at least if you catch the problem before entering more notes.
Fixed in branch master, commit a2998b5b23
fix #277786: bad transposition of instrument change from 2.3.2
Fixed in branch master, commit 8df0ce514a
Merge pull request #4465 from MarcSabatella/refix-instrument-change
fix #277786: bad transposition of instrument change from 2.3.2
Fixed in branch 3.0rc, commit 4469b60e9e
Merge pull request #4465 from MarcSabatella/refix-instrument-change
fix #277786: bad transposition of instrument change from 2.3.2
Automatically closed -- issue fixed for 2 weeks with no activity.