The display of the tempo palette is wrong after creating a new workspace

• Jul 1, 2015 - 21:31
S4 - Minor

Nightly 36f776e / Windows7

1) Load a score, or use "My First Score"
2) Open the Tempo palette. If you are in Advanced and Basic workspaces, you see this, as expected:

3) Create a new workspace (to allow the editing of the palettes) → Ok
4) Reopen the Tempo palette.
Result : inexpected : the display is the same before the fix of this issue on last May: #28366: Tempo texts are aligned incorrectly, ie with the notes too low.
tempo workspace.jpg

Switch again in « Advanced » or « Basic » : correct

Major priority because, in function of the workspace status (Customized or Basic/Advanced), you may get two sorts of tempo display in your score. Very inexpected, right?


I don't see this on my system - the palette always looks the same. I just did a factory reset since I hadn't done one for a while. Maybe you need to do the same?

I maybe forget a step (after #4). After opening a nightly with a factory reset, and creating new workspace, you must switch to "Advanced" or "Basic" (-> open Tempo Palette), then switch a second time to your customized workspace (-> open again Tempo Palette) and so on, to see the two different displays of this palette.

Sorry, I still don't see any difference on my system. Can you attach your palette file? I believe you're on Windows, and I'm not sure where these are stored, but it should have the extension ".workspace".

Also, is it possible you have an older version of Bravura installed on your system that is causing a conflict?

So, complete and precise steps:

1) To be sure, open a recent nightly eg e8a0d90 via "RevertToFactorySettings"
2) You are in "My First Score"
3) Add eg with "+"' a new workspace -> Ok
4) Open tempo palette: result: correct
5) Switch to "Advanced" -> Open tempo palette: result: correct
6) Switch again to your customized workspace -> Open tempo palette: result: incorrect ("former display with notes too low")

Yes, those are the steps I followed. Still no success reproducing. Again, can you check to see if you have an older/incompatible version of Bravura installed on your system? Remove it if so. If that doesn't solve the problem, please try to find your palette file and attach it.

"can you check to see if you have an older/incompatible version of Bravura installed on your system?"
How I do that?
"try to find your palette file"
"Palette file"? Sorry, don't understand. Ditto, how I do that?

On Windows 7, I believe you can find your installed fonts by going to the Control Panel and finding the window for Fonts. Or maybe just open a word processor and see if Bravura is listed.

As for the palette file, I am guessing that is somewhere in your AppData folder, but I don't know the specifics. You are looking for a file like "My new workspace.workspace", or whatever you called it when you created it.

Well, I try, but there is nothing obvious (on Windows7 indeed). If you think it is only on my system, let's not waste our time with this.
I'll try to dig the issue in the coming days. Until then, you can close this issue, and if I find new elements, I can reopen.
I'm just surprised that through a factory reset this kind of behavior is possible, even on a single system (well, two, because I can reproduce with my laptop under Win 8.1)

Hmm, interesting, with the nightly build I indeed can reproduce, no factory reset needed

It does create the correct tempo texts in the score though, so it just a display issue in the palette
Edit, no it does not, not always. Behaves unpredictable

The .workspace file this created (unpacked with 7zip and looking at the workspace.xml inside), contains the unicode* variantes rather the met* ones.

Seems to be due to the nightlies (and 2.0.2 would too) to replace those met* glyps with their unicode* counterparts on writing (and not only on write of score, but also if writing of a workspace or a palette etc.), to maintain backward compatibility with 2.0 and 2.0.1, where the builtin fonts (Bravura/BravuraText) just don't have the met* ones.

A fix might be to replace (back) on read.

Aha! Yes, that would probably explain it. Good job figuring that out!

Doing the conversion on read is something I had been suggesting anyhow, as I rather doubt there are existing texts that really prefer the old glyphs. But actually, I think I'd rather see the palettes written correctly in the first place. I wonder if there would be a convenient way to determine if you are in a palette write at the point where the replacement currently takes place - maybe check parent(), or check if score() == gscore()?

If we change the writing for palettes, MuseScore 2.0 and 2.0.1 will not read the palette (at least they will not display the met* symbols). So I wouldn't do that.
So let's change the read. It also means we can't get rid of the unicode symbols a bit everywhere. Any drawback?