Staff properties play transposition does not work

• Jun 1, 2012 - 21:31

The reason for this is the request of Marc Sabatella supposing me to do things not correctly:

I am using the latest stable version of musescore (Version 1.2, Revision 5470) on Win XP and Ubuntu 12-04.
After downloading the attached tune (Ave Maria) from I noticed the bass clarinet playing the wrong octave.
I checked the staff properties of Bass Clarinet and found (see Attachment 2). As this seemed to be right I looked at concert pitch. The notes displayed are now in D rather than in C but Bass Clarinet was an octave up rather than down. So I opened staff properties again and changed the octave to up. And Comcert pitch display changed to the other attachment.
But playing produced exactly the same sound!
Now, what I am doing wrong ?


i think the fault lies in the arrangement of the piece.

The pitch of the bass clarinet is correct with the original version of this piece, but the arranger obviously didn't realise this would result in notes out of the Bass clarinet's range. Disabling concert pitch results in displaying the score as it would appear to the bass clarinettist, which, if I recall corrrectly is a Bb instrument which sounds an octave lower than written. Consequently to play a middle C the bass clarinet would have to have the D on the 5th line of the treble clef written. This is exactly the case in this piece.

The fault, therefore, lies with the arranger and not MuseScore.

In reply to by ManfredHerr

That's because currently they both use the same sound in the default soundfont :)

There is no bass clarinet defined in the GM system.

So until multiple soundfont use comes along in 2.0 we're probably stuck with the GM soundset, particularly if you are going to upload to

It isn't clear to me to what extent you already understand how instrument transposition works - the fact that bass clarinet is *supposed* to sound an octave and a step lower than written, because that is how the instrument was designed. Always; not just for this piece. It's something that is simply true about bass clarinets in general. I'm going to assume you do understand that, and are just confused about how MuseScore handles this.

Normally, you wouldn't ever change the Play Transposition for a staff. It is set automatically by MuseScore when you first add the staff (via the new score wizard, or via create->instrument), or change instruments (via staff properties. It is set to be the correct transposition for that instrument so that you can enter notes at concert pitch when Concert Pitch is enabled, and have them transposed and displayed properly for the instrument when you turn Concert Pitch off. Or, you can enter notes at written itch with Concert Pitch turned off, and turning on Concert Pitch will show you how those notes will actually sound. But whether Concert Pitch is on or off, playback will be at concert pitch.

Now, if you for some reason should choose to change Play Transposition - again, not something you'd normally ever want to do - MuseScore does not change the playback pitch. It assumes you entered the notes correctly for whatever instrument you had selected originally. So if you change the Play Transposition setting, it assumes you are basically changing the instrument you are writing for. Normally, you'd actually use the Change Instrument button for that, since that will change the sound sample used as well as the transposition. But you do have the ability to control those separate for those rare cases when that might be necessary. Again, changing the Play Transposition does *not* alter the sound, nor should it - it only changes MuseScore's understanding of what type of instrument you are writing for. Bass Clarinet always sounds an octave an step lower than written, so music needs to be written an octave and a step higher than you want it to sound. And that is precisely what MuseScore does when you turn Concert Pitch off. If you change Play Transposition, the playback pitch (what displays with Concert Pitch on) doesn't change, but what gets displayed for the the instrument in question to play when you turn Concert Pitch *off* changes. The value you specify tells MuseScore how much lower than written that instrument sounds. But you'd never change this for bass clarinet - bass clarinets *always* sound an octave and a whole step below where they are written. it is how the instrument was designed, and you can't change that. By telling MuseScore that a bass clarinet sounds an octave and a step *below* where it is written, that gives MuseScore the information it needs to know to display the part properly when you turn concert pitch *off* - it will transpose the display of the part *up* by that amount. But the sound, and what is displayed with Concert Pitch *on*, necessarily stays the same. Anything else would be wrong.

if the whole idea of instruments needing to be written with transposition is new to you, this is indeed incredibly confusion, but that's not anything of MuseScore's doing. it is simply providing th facility to allow you to write music correctly for those instruments - to handle the transposition for you. And it's the same basic system used by every other notation program.

If your goal is is to actually transpose the notes so they *sound* down an octave, then you don't use the Play Transposition feature, but rather, the regular Transpose feature (under the Notes menu). Or, just select the region and hit Ctrl-DownArrow to transpose down an octave.

When you told MuseScore the Play Transposition of a bass clarinet is *up* an octave and a step, you are saying that bass clarinets sounds an octave and a step *higher* than written. This is not true at all, but it's what you told MuseScore. So it is dutifully transposing the display of the part *down* by that amount, so that when this mythical bass clarinet that sounds an octave and a step up goes to play it, it will sound right where was supposed to all along - starting on middle C.

In reply to by Marc Sabatella

First of all, I want to thank you for your attempts to help me getting rid of my confusion!
The basic error was, not to recognize that the concert pitch toggle button was pressed when loading the score. So, when pressing it again, I expected to see concert pitch now, but toggled to instrument pitch (i.e. not concert pitch). The transposition I saw was in the wrong direction for changing to concert pitch, but correct for the change in the other direction (which I did). So, it is also clear why pressing a g in the clarinet voice and the same g in the bass clarinet voice gives the same tone: because initially the score is in concert pitch. The assumption of Church organist doesn´t hold.
The second error was the assumption to be able to hold the notes and change transposition by means of staff properties.

"But the sound, and what is displayed with Concert Pitch *on*, necessarily stays the same. Anything else would be wrong."
If you have the time to make experiments you can explore "hidden features" of musescore. For example, ensure that concert pitch is off. Then change the instrument in the staff properties dialog from bass clarinat to flute. You get notes too low for a flute in C. So you press undo and get the bass clarinet back but an octave higher and not in D but in E. If you now change instrument to flute again you see playable notes (in D now). But noted an octave higher than they sound. Take the first note and switch octaves down and up again. Compare the sound now to the same first note in measure 2.

In reply to by ManfredHerr

Ah, now *that* does seem to be a bug. I have no idea why changing instrument moved it down an octave - that goes against what I said should happen (I expect sounding pitch to remain the same). I guess I had never tried changing instrument after entering notes and with concert pitch turned off before. That seems to be the combination of steps necessary to trigger the bug. Wouldn't be *that* bad if all it did was make things off by an octave, but then, indeed, Undo makes it worse.

In 2.0, things work differently, and I don't quite understand how it is *supposed* to work. It appears that if you have concert pitch turned off while changing instruments, it keeps the same written pitch - which isn't what I'd expect, but does at least seem like a sensible second choice. And Undo works fine. As does changing instrument with Concert Pitch turned on.

So assuming it is deliberate that changing instrument with Concert Pitch off should preserve written as opposed to sounding pitches, it seems 2.0 is functioning correctly, meaning it's probably not worth submitting the issue with 1.2. But I think it's worth discussing how changing instrument *should* work - *should* it really behave differently according to whether Concert Pitch is turned on? I say no - sounding oiutch should remain the same regardless of the state of Concert Pitch. But someone else might say it is consistent in that the *displayed* pitch is always kept constant. And I guess the current method has the advantage of giving two different methods of altering transposition. Changing instrument with Concert Pitch turned off would give you an "out" if you accidentally entered the pitches at the wrong pitch in the first place. I'd say you should just use regular Transpose to correct that error, though.

In reply to by Marc Sabatella

My misinterpretation came from using CAKEWALK, a sequencer for MIDI on Windows, before. They did it the other way around: You enter the notes for the instrumentalist and with "global transpose" you tell what the instrument in question would do with this, i.e. how to reach "concert pitch". It is not as convenient as MuseScore. Because, if you enter the tracks with a midi keyboard all in C-temperament and make orchestration afterwards, you first have to transpose the notes of the track to the instrument's notation and use the inverse transposition in the global field.

I agree that things the way you described it makes sense. And it is up to the developer to decide which way the dialog is functionnig, as long as it *makes* sense. However, it would be nice to have a hint (short description) available somewhere to get an idea how things are supposed to work. I agree that an online help system is a lot of work and makes sense only then when things are settled and do not change as quick as they do now. I know, it is a task software developers hate. And it hinders quick program changes. If I am a free developer of free sofware I want to produce code, not documentation. The user is about to try things and soon he will know. Or find someone, like you, in the forums who knows. I understand that, but the maturing process of software cannot neglect to guide the dumb user.

In reply to by ManfredHerr

Indeed, good points. I suspect more people will be familiar with how things are done in other notation programs like Finale or Sibelius than how they were done in Cakewalk, and as I mentioned, MuseScore is very similar other notation programs in this respect. it allows note entry in either concert pitch or transposed, according to the state of the button. But this is not explained anywhere the way it could be. And realistically, the number of people who don't even realize that some instruments need to transpose is probably higher than the number of people who are familiar with how Finale and Sibelius handle it, so explanation for the *complete* newcomer to transposing instruments would be especially useful.

Seems like this could be the subject of a short tutorial. Maybe at some point you'd like to take that on?

In reply to by Marc Sabatella

My intention was not that MuseScore needs documentation describing the musical background of transposing instruments. And I don´t know whether "other notation programs" do this, because I never used such. My point is sitting in front of the staff properties dialoge I have no clue what I am going to change. There are multiple possibilities of "transpose" but only this word is given. Transpose from what to what with which influence?

Triggered by your answer I built an actual Version 2 of MuseScore on Ubuntu. Then I played my games with the staff properties dialoge and found that your description is not followed at all. No fix concert pitch like elsewhere. The concert pitch button, not located in the dialoge but in the global menue, has crucial influence on what´s going on. If this button is pressed, i.e. concert pitch is on, then the notes are kept in concert pitch and you change the transposition of the instrument, i.e. instruments´ notation. But if concert pitch is off you change concert pitch keeping instruments notation.

And moreover, there are fields in this dialoge that seem to have no effect: For example check mark ´invisible´. And others, like ´no stems´ have an effect only if the notes have no beam. Having said this, and that english is not my mother tongue,
you understand that I am not eager to write tutorials that are wrong or obsolete as soon as they appear.

In reply to by ManfredHerr

Right, I did observe above that in 2.0, the status of Concert Pitch *does* affect the results of changing staff transposition. And used about whether that was appropriate or not. I still think not, but I *can* see advantages to how it does work. I would like to see more discussion on this point.

As for other items that appear to have no effect, keep in mind 2.0 is still under development. Not all features work yet. But do note that an invisible staff in 1.2 only makes the staff lines themselves invisible - and like all invisible objects, they display on screen as greyed out. I personally wish there a way to make the entire instrument invisible -staff lines, notes, and all. And furthermore to make it take no space on the page - a staff for playback only. j believe there are already feature requests on that front.

Anyhow, yes, anything that can be done to improve the staff properties dialog itself be nice, so suggestions would be welcome by the developers, I'm sure. But do note that, as I observed previously, most users would *never* need to touch the play transposition settings. They are set automatically when you create or change instruments. So most users would never have reason to become confused by them - they would leave them alone. One thought would be to remove them from the main dialog, have a button labeled "Instrument Transposition" that pops up a second dialog where you set the interval, and have that dialog include display of the notes: "Written - ; Sounds -

In reply to by Marc Sabatella

Do you want to discuss with me only ? I think you are able to reach more and more skilled people in other places. Nevertheless I can tell my opinion, as a B clarinetist comming from MIDI sequencing.
You´re right with your assumption that a lot of MuseScore users won´t need transposition at all. I see as well that most music published on is C-tempered. And to a very big amount stemming from piano players. This is not different than in old MIDI days. But also, you can find on the net such artists like Gary Wachtel (GaryW0001) who produced MIDI files for traditional Jazz Bigbands with outstanding quality but not correct notation. The easy way to create a Bigband Midi is to enter all music in C and change the patch only. The sound is ok without any transposition. This transposition is only then of interest when it comes to producing notation for real bands. Some sequencers, including CAKEWALK, claimed to support printing. See above how they supported transposition.
When you start a new score from within MuseScore you don´t need to touch transposition settings, I agree. But if you open a MIDI file of a simple clarinet tune accompanied by a piano you often end up with a clarinet part in C. MuseScore doesn´t know anything about the instrument and the key signature. It only retains the patches and the track headings. You need to change instruments and keys from nothing to the one in question. It´s assumption, that all is in in concert pitch, is often ok, but not allways. Here´s where transposition is needed.
The same problem arises, I think, when starting with music-xml.

In reply to by ManfredHerr

I think continuing discussion here in the forum is good, as others may have opinions (even if so far no one has expressed one!).

Anyhow, I didn't mean to say that most musicians don't need to deal with transposition at all; just that they don't normally need to achieve it through use of the low level controls in the staff properties dialog. Most transposition needs are handled automatically when you create or change instruments (including use of the new score wizard).

But you are correct that people creating scores by importing MIDI files will need to deal with the low level controls. I think MusicXML actually has a facility for handling transposition, although it only works if you export it with that information intact.

So, the basic question is this: how do you think the controls could be made clearer for the sake of those people who do need to use them? What do you think of my idea of moving them to a separate dialog that you'd access via a button from the main staff properties dialog? One advantage as I see it would be most users would never even see the controls, thus reducing the likelihood of their creating trouble for themselves unnecessarily. Another would be that now there would be more room to do things like add more explanation, samples pitches, etc, as I described above. And perhaps most importantly, it provides a place to put a checkbox to control whether any change made in that dialog works by preserving sounding pitch or by preserving written pitch. Such a control *could* be added to the mains staff properties dialog - no need for a separate dialog just to get that - but I'd rather only see that checkbox if I am actually changing transposition.

By the way, what consortium is taking the decision what is done how?
Who decided to not change key signature anymore in V2's transposition function?
Why are new contributors invited to code without providing a description of their contribution?

In reply to by ManfredHerr

I wouldn't assume anyone "decided" to have key signatures not transpose in 2.0; I think that's just an accident of this feature not yet being fully re-implemented.

Not sure what you mean about people being invited to code without providing a description. As far as I know - I have yet to do any actual coding on this project - no one is allowed to check in changes directly. You have to do it by submitting patches for approval. And I would assume that a good description is something that would be required if you want your patch approved.

In reply to by Marc Sabatella

Sorry, I can't find the post with the invitation to start coding. But, in my days of sofware development the desciption was first and coding afterwards rather than producing something and then hand it over for somebody to accept / throw away. The idea came into my mind that this approving authority would laugh on our discussion here - if already aware of it.
Also, this discussion will gain less attention in a support and bug forum than e.g. in the developer mailing list.
Back to transposition and the staff properties dialog: The much I support your idea of invisible staff lines without influencing the layout the less I conform to hiding the transposition settings in a lower leaf of the dialog tree. It is hard enough to find. Room is not so much a concern in the staff properties. For hints there are other means available: The oldest one is to include a "?" button that pops up a description. Next are dynamic subtitles in the dialog title/label, e.g. TRANSPOSITION / with fix sounding pitch ( cf. button "concert pitch") or TRANSPOSITION / with fix notated pitch ( cf. button "concert pitch"). Another technique is to change the cursor into a question mark and pop up explanations when over a label or tool tips or ... :-) The more convenience the more work. I must admit that I prefer functionality over convenience.

Do you still have an unanswered question? Please log in first to post your question.