Parts clef change sometimes fails, with workaround
As an "aside": The "Parts" feature will i hope get a big rework in MS4 as it works inconsistently and is poorly documented.
My issue is that i want to create a linked score ("part") and change the instruments that play on the part, with appropriate clefing... and this works (barely) but not on all scores.
By experimentation i found that i could create a new part, and then while viewing that part, in a staff (confusingly also referred to as a "part" in the Staff/Part Properties) force a clef change by changing the instrument (i also did transposing by octaves)... directly changing the clef would maddeningly change the original score and all other parts (i consider that a bug too!), but changing the instrument did the job.
This behavior was not documented, but seemed to work consistently...
but then i discovered some scores where it did not work as i wanted.
I've attached 3 files (created with MS3.6.0 but the same behavior appears with MS3.6.1 andMS3.5.2)
In tt2a.mscx i've already created a "Violin" part from the main score, but not modified it yet.
In tt2b.mscx i've modified the 3rd staff to be a violin instrument (previously cello), and named the staff to be Violin 3... the clef automatically changed to treble (i also did a transpose)... great!
In tt2c.mscx i've modified the 4th staff to also be a violin instrument (previously cello) and named the staff to be Violin 4 ... but the clef remains as bass clef!!! bad!!!
I've attached a 4th file named tt2c-fix.mscx where i went in with a text editor and changed two lines
from "F" to "G":
G
G
After this change the desired clef is displayed (of course i still need to apply a transposition, but this works well also).
I would love it if in 3.6.2 i would not have to go in with a text editor (and unzip) to work around this apparent bug.
And if in 4.0 the entire Parts scheme could be fixed so that playback works as one might expect for a part, clefs can be changed in a part without changing other parts, and i'm sure there are many more issues.
Thanks again for the great software!
-Ted Merrill
| Attachment | Size |
|---|---|
| tt2a.mscx | 203.09 KB |
| tt2b.mscx | 202.94 KB |
| tt2c.mscx | 209.51 KB |
| tt2c-fix.mscx | 209.51 KB |
Comments
Appears to be a bug / misguided feature in the forum submit code where the two lines did not make it through, perhaps because they look like html tags. Hmm... let's see if this will be bold: bold.
Anyway, i found the appropriate instances of concertClefType and transposingClefType .
I'm not sure what exactly these two do and whether i needed to change both of them.
There does not appear to be a guide on the musescore file format other than the source code... ???
Having the contents of parts and the main score in sync is the point of that whole design. So yes, transposing in a part (and thus change the notes) will propagate through to all instances of that note. That much is very much not a bug.
There is indeed no documentation to the internal mscx format and what you're currently doing with it might work for now, but has no guarantees to work in a future release and might lead to corrupting your score.
It's a known issue that changes to the assigned instrument after generating parts has limitations/bugs. So the standard advice is, don't do that, and if you find you need to, expect to remove and regenerate the part. If you really enjoy going in with text editors, that can also work, but we don't recommend it - we recommend simply regenerating the part if you need to change really basic things about it like which instruments it contains.
Beyond that, feel free to provide some suggestions for how you might imagine the facility being redesigned. We certainly want to provide more control over which properties get lined and link don't. But the system as is should be pretty consistent and logical. Also feel free to suggest - or just make, since the Handbook like the code is open source - any improvements you would like to see in the documentation.
A staff is not a part, not exactly. A "part" can contain multiple staves (think piano or organ). Think of it as really being more synonymous with "instrument". So, the "part" part of Staff/part properties refers to those properties that affect the whole instrument - both staves. This is, indeed, different from the idea of "part" as it relates to score and parts. Normally a "part" does indeed contain just one instrument - like the piano. So the name was meant to make this association clear. But it's possible to generate "parts" that actually contain multiple instruments. And in these cases, then the word "part" to describe what is in Staff/part properties starts to be less accurate.
Anyhow, see if this helps clarify things for you, and then if you still feel there is a problem somewhere with hoe things work, or have specific suggestions for improvement, please let us know!