[1.0] Key sig properties (w/ patch)

• Dec 21, 2010 - 23:42
Type
Functional
Severity
S5 - Suggestion
Status
closed
Project
MuseScore

Purpose: Allows to set the following properties for each key signature change: a) whether to generate a courtesy signature or not, b) whether to display naturals (if any) in the key or not.
Applications: Composite scores with movements/parts/pieces in different keys can be kept in the same score, formatted as they were independent scores, but ensuring all the other settings are consistent; pieces can even share a page. Global courtesy key setting can be kept on to show courtesy key changes inside pieces.
Notes: Properties are set in the key signature contextual menu and written/read to/from the .msc? file.

A patch is attached; most of the code comes from the trunk; extensively tested with branch.

Attachment Size
keysig_properties-branch_r3782.patch 9.95 KB

Comments

• Jan 2, 2011 - 10:24

As feature freezing for 1.0 approaches, I had to ask:

Has this patch explicitly refused or no decision has been made yet?

In proposing it, I saw this patch strictly related with this other patch which has been accepted. Even if they affect different parts of the program, they both serve for composite / complex / structured scores.

Thanks,

M.

Reply

• Jan 3, 2011 - 16:46

This patch is the more invasive so I let it for the end and I was not sure the impact was so important to bother. But still, I will include it.
I changed the QT_TRANSLATE_NOOP by tr(). I still didn't commit and I have one question : When you hide the naturals from a keysig, do you expect the courtesy keysig naturals to be hidden too? it's not the case for the moment, and you can't change this behavior with the current patch. What do you think ?

Reply

• Jan 3, 2011 - 22:49

Thanks for the reply. First your question about courtesy naturals:

I did not expect the "hide naturals" to hide the courtesy naturals too; in fact in a courtesy key, naturals (if applicable) are an integral part of it.

OTOH, in a 'normal' (non-courtesy) key indication, naturals may be needed or not according to the context (mainly, if the key is at the beginning of what is 'felt' as a new part / movement / piece or not, which includes some degree of subjective evaluation from the scorer's part), whence the relevance of such an option.

About the importance of the change:

Of course, importance is always relative and arguable. In the 0.9.6.x version(s), the lack of such an option is by far the major obstacle against combining several pieces in a single score, without strange side effects (unless they all happen to be in the same key). This may be the case for structured compositions (a sonata made of several movements) or for didactic works, like harmony exercises or similar. Given the number of forum requests about multiple pieces in a single MuseScore score, this seems a non-irrelevant field of application.

M.

Reply

• Jan 3, 2011 - 23:05

Thanks for your answer.

In trunk, there is the section break that should make it possible to reset all the necessary stuff to create a new piece in the same file : Time signature, Key signature, Clef and measure numbers.
In the current 0.9.6.3, there is a workaround to combine several pieces with different key sig and time sig if there is more than one staff by inserting a invisible measure and the right changes an the right place.

Attachment Size
TwoPieces.mscz 1.91 KB

Reply

• Jan 4, 2011 - 10:03

This work-around is clever but has a number of side effects: the most important is that justification of the last system before the change is volatile; in addition selecting the invisible measure(s) gives a wrong selection rectangle (in some cases I could not select them at all); finally, it is rather counter-intuitive and difficult to explain (user support).

Do you believe this patch to be so problematic that this work-around is preferable? I am using this modification on my local copy since ver. 0.9.6.1 for all my daily MuseScore work without any problem.

M.

Reply