Status bar

• Jun 4, 2020 - 21:03

I am arranging a violin/piano sonata for chamber orchestra that contains 2 transposing instruments, clarinet in A and horn in E.
When I enter notes for these instruments the status bar does not show the correct pitch but rather what the note would be in treble clef. The entries sound correct but the status bar is not.
Can I adjust the status bar to show the correct pitch?
Thanks for your help.
Keith Lawrence

Attachment Size
Faure Sonata Chamber Orchestra.mscz 28.05 KB


It seems to show the pitch you're viewing to me. For example the first note in the A clarinet part (m9 b2.5) shows D4 in the status bar, and that is also the note I'm seeing on the staff.
If I toggle on concert pitch, both the status bar and the notation change to reflect that and now correctly show B3 as the note

In reply to by Marc Sabatella

Are you saying, then, that the status bar always shows the written note not the sounding pitch?
If so, is there any way to adjust the status bar to make it show the sounding pitch for transposing instruments?
I just would like to have it that way to serve as a check to make sure that I am transposing correctly.
Thanks for your help and all the work you have done to create and keep this open source program going.

In reply to by Spire42

There are lots of different screen readers and different punctuation settings, so I wouldn't want to rely on what any one of them might happen to default to. To me, just looking at it, the arrow means nothing, I'd rather it just say "D4 (B3 concert)". Or else have a preference to control this: some blind users with perfect pitch have mentioned they would prefer only concert pitch to be displayed.

BTW, this is not the literal text read by the screen reader; we build that separately. So you'd want to address both.

In reply to by Marc Sabatella

“D4 (B3 concert)” is a little verbose for my liking, but I think I can live with it. Putting actual text in there does mean we're going to need it to be translated, but I guess that's fine. I think implementing a preference for it would be overkill, at least for a first pass.

BTW, this is not the literal text read by the screen reader; we build that separately. So you'd want to address both.

Happily, all of the accessibility-related functions already call the function I'm modifying (to build that part of the string), so I think that should all work.

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