Instrumentalists often change instruments during course of a piece. We need a way to make transposition and playback instrument changeable mid-piece. Looks like the trunk is moving toward providing this for playback instrument selection, but we still need it for transposition.
Comments
Duplicate ? #15487: Instrument changes does not affect transposition (and crashes on reload)
Yes for the feature request part. The crash is separate, and at's the only reason I didn't close that as a duplicate of this during a previous round of issue-tracker-cleanup. But who knows if that crash is still valid, and it should be filed separately if so anyhow. So I closed that one.
I've decided to look at this.
At one point, I had considered seeing about making the everything about staff properties be something you could set by range. In principle it's fairly straightforward - a matter of establish a tick-indexed map for staff properties like we have for time signature etc. But in practice, it would be a pretty big change. Would require coming up with a UI, also probably a decent amount of code refactoring.
On the other hand, just getting transposition will be a lot easier I think. We already have the Instrument text for specifying the instrument change, and the function to return the Instrument for a given staff already takes an optional tick parameter. We just need to start using it every time we access Instrument::transpose(), and I guess use it when invoking staff properties dialog to be sure we set the properties on the correct instrument given where you right-clicked.
Should be possible to get the amateur/professional pitch ranges working the same way, also even drumset information, although I probably won't tackle that at this time.
BTW, I see there are some places where we *do* actualy use the tick in calculating transposition, and this leads to some interesting bugs - places where things actually almost work as one might hope because part of the code is doing the right thing, but then actually go very wrong because other parts of the code are not. For example:
1) new score for alto saxophone key of C (concert)
2) be sure Concert Pitch is *off*; ke the should display as A
3) add Instrument text to measure 3
4) right click the Instrument text, Change Instrument
5) select Bb Clarinet
6) Note Input, measure 1
7) start entering A's via keyboard shortcut
Result: you get a written "A" for alto saxophone for the first two measures, and it plays back as middle "C", which is correct. But as soon as the cursor enters bar 3 where the isntrument change is, the pitch will *appear* as "A" but actually play back a *G* - which is the correct pitch for clarinet. Unfortunately, the octave is off.
Which is to say, diuring note input, we actually *are* paying attention to the tick and using the appropriate transposition, or at least are trying to - we're just getting the details wrong because it isn't consistent. Try entering "A" via the Piano Keyboard toolbar and you get an even more interesting result: it displays as an "E", but plays as "G", which I guess is the correct transposition for alto saxophone. So it calculates the correct concert pitch for clarinet ("G") from what you press on the keyboard, but then displays the pitch based on the alto sax transposition.
Not sure how this has not been reported before - basically, note input is pretty broken for regions affected by Instrument change text!
Initial results are extremely encouraging. Simply plugging in the tick when retrieving the instrument everywhere we access the transposition info does the job very nicely, with only an extremely minimal amount refactoring needed (involving Score::transposeKeys(), possibly Staff::write() depending on what I do for copy/paste).
Main outstanding issue for me is how to deal with the Staff Properties dialog. I am thinking that it should probably show and affect the "current" instrument settings according to where you right clicked to display it. I think I will deal with amateur/professional range info while I'm at it.
What about staff names? It would be pretty simple, I expect, to similarly get the right staff name at the beginning of each system according to which instrument is in effect that that point. This assumes I actually do have Staff Properties allow you to set this info for each instrument within the staff.
Not ready to merge yet, but the following works well enough for people to who are feeling adventurous to try out:
https://github.com/musescore/MuseScore/pull/2228
After some more udpates & testing, I think it's ready any time now.
There is an outstanding issue with transposition of key signatures specifically that is a secondary effect of another bug I discovered while working on this: #78591: Undo of Change Instrument does not work. A fix for that should also take care of the key signature transposition issue.
BTW, I also filed an issue for the bug I described in #4: #81091: tpc corruption adding notes after transposing Instrument change
Way to go Marc.
Fixed in branch master, commit f144d7c978
fix #9352: instrument change transposition
Automatically closed -- issue fixed for 2 weeks with no activity.
see https://github.com/musescore/MuseScore/pull/3029
Fixed in branch 2.1, commit 564fad35b0
fix #9352: transpose by range (for 2.1)
Fixed in branch 2.1, commit 30238c6408
Merge pull request #3029 from MarcSabatella/9352-21-transpose-range
fix #9352: transpose by range (for 2.1)
The fix in 2.1 should be better than the one in master. Please help in testing this in 2.1!
Marc, I've quickly tried out your feature. One issue (which is not a fault with your code, but is rather something that might be considered for improvement in future) is to be aware about clef changes that transposed instruments usually take when transposing.
For instance, suppose we have a baritone sax part who needs to switch to flute and then back to baritone:
That is the view in concert pitch. Since the bari is usually viewed in *bass* clef while inside concert pitch score, that bari default clef is bass. But when I switch to flute, I've added a treble clef for readability. And then added a bass clef when switch back to bari for readbility in concert pitch.
But now when I go to transposed pitch view:
when it goes back to the bari, that bass clef I put is is used, but it is not nice for readability. So ideally I would like a way to tell musescore to revert to the default clef for that instrument.
Also I was trying to add key sig when change to flute and when go back, but I managed to produce a seg fault. I will have to look into this later tonigh...I'm at a gig now...
FWIW, clef changes are tracked by concert pitch status, so it should be possible to have one clef used for concert pitch ON and another for concert pitch OFF. Just drop the treble clef back on that measure with concert pitch off. But now you'll have two treble clefs - one going in to the passage and one going out. So you'll want to make them invisible. A bit awkward, but you *can* get the desired result, if I am understanding correctly.
His example is a extreme example of weird staff changes between concert and transposed pitches. My suggestion would be to allow independent changes in clef between concert and transposed views as is normally seen in the Bari Sax, Piccolo and Bass in MuseScore.
Of course the argument against this is that instruments like the viola, bassoon and horn switch between clefs often. However, when I write, I usually don't change the staff in concert pitch but almost always in transposed view.
I think my ideal solution would be to apply any clef change in current view only, unless the instrument is non transposing (like the piano and viola but not the piccolo).
No my example is not extreme writes staff changes. It is very common for sax players in big band to be exgepected to double on flute & clarinet.
I will try out the workaround Marc suggested, but ideally there would be a way to handle this cleanly and automatically. Maybe an "instrument default" clef element which displays the current instrument accordingly.
I didn't mean it's unheard of, I mean it's about the most extreme case of clef changes you get when you change instruments.
If the clef change only applied to concert pitch in your example, then there would be no need for hiding an extra treble clef.
As it is, a clef *change* does already only to the mode you make that change in. It's the clef *add* that affects both mode. So if you want to *add* a clef, if will show up in both modes, the same in each, but if you then *chanbge* that clef to another one, it affects the current mode only. *Most* of the time this is exactly as you'd like it, but it is true that it is not ideal in the special case of change of clef changes that accompany *instrument* changes as well. Probably would be good to have a way to add a clef without it affecting the other mode - maybe by holding Ctrl while adding it, kind of like how we do local key change or loca time signature changes.
Thanks marc, it took me a while to process your comments, but I figured out how to produce a desired clef:
1. Start with no added clefs.
2. Be in concert pitch.
3. Drop treble clef on the *measure* of the flute entrance.
4. Drop bass clef on the *measure* of the bari re-entrance.
5. Toggle concert pitch OFF.
6. Drop treble clef on the measure of the bari re-entrance.
Now when toggling concert pitch on and off, the clef at the re-entrance measure will "track" the state of concert pitch nicely.
Although one problem when concert pitch is OFF is that the bari part has unnecessary treble clef at the measure of the flute entrance and the bari re-entrance. Those treble clefs are unnecessary because are already in treble clef. Of course I can make those clef invisible in the part excerpt scores as a work around. As you said, one solution would be to:
I'm also wondering if it makes sense for the change instrument text to be "smart" by automatically *generating* the default clef of the instrument if different from the previous clef. In which case would only generate a clef if needed based on current status of concert pitch. Similarly maybe the change instrument text could automatically generate a key signature change when concert pitch is disabled if changing to an instrument in a different key. Of course that would be a feature request separate from the OP.
Regarding the crash I mentioned earlier, I can't seem to reproduce it...unfortunately I didn't have time to figure out the steps when I reported it. It had something to do with dropping key sigs and deleting key sigs at the flute and bari entrances.
Marc, I found a bug with your code...seems to have forgotten to handle dragging: #181616: dragging anchor of instrument change text needs to revert staff's transposition. I guess I will have to fix it cause you said you are away.
I did make two separate feature requests:
#181641: Change instrument text set instrument via inspector
#181646: Option to auto-generate default clef and new key sig for Staff Type element if needed for transposing instruments
Automatically closed -- issue fixed for 2 weeks with no activity.