Small note or small chord settings
Marc, as you just wrote on Github: " One can set the chord to be small, the note to be small, or both (which results in something even smaller)."
I noticed that effect last night (small note and small chord checked), and wondered if these "extra-small notes" are a desired effect? You can also apply this to grace notes and get something even smaller (ultra-small notes, almost no head).
Also, when setting the chord to small, the stem shortens as well making the note look truly small, but checking small under note only makes the head small and not the stem. Is this difference in stems also desired or correct?
Comments
These are good questions, and I suspect the whole things is not completely thought through. That is, I'm sure there are places in the code where bad things will happen depending on whether you have the chord, note,or both set to small.
But I think the stem thing has to be deliberate. The whole reason for allowing "small" to be applied to notes and not just chords (the latter is the case in 1.3) is to allow chords of mixed notehead size. So the main reason to set notehead to small would be to get one small note within a larger chord. The idea being, setting a chord to small affects the entire chord and everything about it; setting a note to small affects only that note and marking attached to that note specifically as opposed to the whole chord. So for instance, an accidental on the specific note you set small is affected, but an articulation applies to the whole chord and thus is not affected by a change to the note. Stems are similar.
Not that any of this will be immediately apparent to users, so I'm sure some will set the note property when they should be setting the chord, and worse, might be mixing the two approaches and wondering why things seem inconsistent. Not sure there is a good way to prevent that, though. The capability of setting small for chord and note independently is important; I don't want to give that up.
As for what should happen if you set both, I say, whatever is easiest - it's not worth worrying about. But FWIW, no one is forcing anyone to apply "small" to both a note and a chord at the same time, so I can't see any reason to *not* allow this to make a *really* small note if the user goes out of his way to do this.
In reply to These are good questions, and by Marc Sabatella
I agree for the most part. I like the flexibility, but the side effects will cause problems down the road.
However, one thing seems inconsistent. If I have a normal theme, and an alternate theme notated in small notes in another voice, and I check small for the note (not chord), then the stem stays large. So it seems I should be checking small on chord even though it is a single note. If all notes in a chord are marked small under note, then the stem should go small as well, whether the chord is one or many.
Is this just a misunderstanding on my part about the usage of the terms "note" and "chord" in the Inspector? Maybe in the Inspector "note" should be called "note head" as it doesn't affect the stem. That way you know anything changed there will only affect the head.
In reply to I agree for the most part. I by schepers
Yes, you should indeed normally be only setting "small" for the chord, not for the note. A chord of one note is still a chord - that's fundamental to everything in MuseScore. Stems are properties of chords, not notes, which is why "stemless" shows up in the Chord section of the Inspector as opposed to the Note section. If you want a stem small, you need to apply "small" to the chord, not the note. Colloquially, we think of a "chord" as being of something with more than one note, but that's not how the term is used within MuseScore. It's the generic name for something that exists in time for a given voice and makes a sound, whether it happens to be made of one note or multiple notes.
Renaming the sections in the Inspector is not a bad idea, but I don't think notehead gets it quite. It isn't just the head - it's really everything about that note, including dots, accidentals, and any other markings that can possibly be applied to the note individually as opposed to the chord. I'd be more inclined to want to think of an alternate name for "chord", since this is the really misleading term (since we normally think of chords as having multiple notes).
The real problem, though, regardless of naming, is that it is by no means obvious to which things *are* attached to notes versus chords. It's something you learn as you go. It's actually quite logical *in hindsight", but that's not the same as being intuitive.
So I'm certainly open to suggestions, but I also suspect we're overthinking this. No one complained thus far. If people notice there are two different "small" settings, hopefully it will occur to them to try both out, and they'll figure out the difference soon enough. I do think it good that "chord" appears above "note" on the Inspector, so you're more likely to try the "chord" version first, which is at it shoild be for the simple case of one-note chords.
But munging things so that setting all notes in a chord to small magically unsets the small property on the notes and magically set it on the chord instead just seems wrong. Besides, how you would then return just one of the notes to normal size? You'd have to start over, unsetting small on the chord and setting it on the notes again. Very non-intuitive.
In reply to Yes, you should indeed by Marc Sabatella
"No one complained thus far."
Don't equate a lack of feedback with things being OK. V2.0 isn't even beta yet, and I suspect the number of people really testing v2 right now are limited. It will take quite the concerted effort for testers to hammer v2 when it does go beta.
Regarding intuitive vs how MS uses terms, this is one case that will cause problems. Musically, a chord does not exist with only one note, so the usage in this case is very non-intuitive. Definitely one for the manual!
"But munging things so..."
I was not suggesting changing any user-set options. Quite simply, if MS sees a single note with "small" set for note, then MS would display both the note and stem small. Adding another note to this would result in the small note/chord changing to a large stem, with a small and large note.
In reply to "No one complained thus far." by schepers
True, exposure to 2.0 has been limited. But the use of the terms "chord" and "note" in MuseScore is not new. It's just been of lower importance to understand the difference.
Anyhow, regarding munging, what I am observing is that what you are describing requires MuseScore doing *internal* handstands. Since a stem *is* a chord property and not a note property, implementing what you are suggesting would require doing as I said above: special-casing the situation where all notes within a chord happen to be set to small, then internally unsetting that property on each note in the chord and setting it on the chord instead, so all the code that handles chord layout (including the drawing of stems but much more besides) would treat it as if you had set the chord small. And then. And now, apparently, you are also suggesting keeping a record of this so we can "undo" it all (but not a true undo) if the user then changes a note to normal - that's even more strange implementation-wise.
I can't see anyone wanting to implement all this behind-the-scenes magic just so a user doesn't have to bother learning the difference between "small note" and "small chord". Especially since doing so actually *lsoes* functionality - what if you *want* a small notehead on a normal stem?
In reply to These are good questions, and by Marc Sabatella
not sure I agree, 'small' is a Boolean, but can result in 5 different sizes, normal notehead, small notehead, smaller notehead on a small chord and smallest noteehead on a grace note and even smaller on and small grace chord. This is confusing, and I don't believe it is really either.
Small note should mean small notehead on long stem (as it does already). Maybe even small chord, if there is only one notehead?
Small chord should mean short stem and all noteheads set to small
grace note should mean small chord
If we really want 4 different sizes, it should be an enum, not a bool
In reply to not sure I agree, 'small' is by Jojo-Schmitz
The thing it, it *is* a bool implemenation-wise. There are only two possible states for an object of type "chord": normal or small. That's it. The fact that object of type "note" can also possible be normal small is not relevant to pbjects of type "chord". If you have a chord of three notes, and the chord is set small, and one of the three notes in the chord is also set to type small, then the "chord" pbject is still just plain small - it neither knows nor cares if any of the notes in the chord are also set "small". And vice versa. There's no way an enum applied to "chord" could possibly capture this information.
So as far as I cam see, there is nothing wrong with the basic implementation.
In reply to The thing it, it *is* a bool by Marc Sabatella
A note could inherit a chord's smalness. If a chord is set to small, all it s notes should be small to, but not vice versa, a note could be small, without the chord being small
In reply to A note could inherit a by Jojo-Schmitz
In effect, this is how it is currently. If a chord is marked small, the notes don't actually get the small property set (that would result in them appearing double small, as noted), but they do appear small, so it's as if they have inherited the property. But since Note is not and should not be a subclass of Chord, it's not a true inheritance in the C++ sense.