Notehead positioning of three or more voices
1. Open attached score (produced in 1.3).
Expected result: Voice 1 is centred to the semibreve.
Actual result: Voice 1 is right-aligned to the semibreve.
Discussion: It seems that notehead positioning is fine with voices 1 and 2, but voice 3 could introduce problems. An example: Swapping Voices 2-3 and deleting the notes of voice 3 will centre the notehead of voice 1.
Using MuseScore 2.0 Nightly Build (601b10b) - Mac 10.7.5.
Comments
The way I figure it is, about half the time a third voice is used, it is cases like this where you want it offset, but the other half it is for other reasons where you specifically want the stems to align. And it's easier to force aligned stems out of alignment than the converse. So I elected to place the burden on those wanting the offset. It's one of the few areas (another concerns dot placement on offset chords) where I would agree legitimate arguments could be made either way, but in any case, I made the calls I did for what I believe to be valid reasons.
Hmm, on second thought, I think I misunderstood. First, I misunderstood which voice was which. I assumed the quarter note was voice 3 since the stem was up, but it isn't - the quarter note is actually voice 2 with the stem forced up. The whole note chord is voice 3, which *also* has stems up (even though, of course, you can't see the stem). So all three voices have up stems.
The "rule" MuseScore is following here is as I alluded to: voices with the same stem direction align at the stems (and this happens whether there are actual stems or not). If you want center alignment, have the stems in opposite directions.
Had this had the "normal" voice arrangement (stem up notes in voice 1 & 3, stem down in 2 & 4), this would have aligned as you expected. But as it is, you can force the alignment to be the way you want easily - just for the "stems" on the whole notes down by pressing X. Or exchange voices 2 and 3 - not sure what you mean about deleting noes, that shouldn't be necessary.
But you'd still need to explicitly un-align the two upstem notes - as I said, that was a deliberate choice that one could indeed question.
In reply to Hmm, on second thought, I by Marc Sabatella
I thought the stem of Voice 2 would be up by default, but I forced it to match the original.
Could you upload what you think the voice arrangement of the score should be?
Can the semibreve stem direction be ignored internally? It doesn't seem right to me that it should move. Do you disagree?
About your rule of voices with the same stem direction aligning, what about bar 11 of 'Aria' - 'Goldberg Variations'?:
In reply to I thought the stem of Voice 2 by chen lung
Defaults are always upstem for voices 1 & 3, down for 2 & 4.
The expected voice assignment in your original example is what you get if you exchange 2-3.
Note layout is an incredibly complicated topic - far more so than accidentals, which are complicated enough - and very interrelated. No, you can't just ignore stem position or direction for whole notes; lots of other factors come into play. It would be possible to come up with a set of specific exceptions and code in anticipation of those. But just as with accidentals, it's not possible to have one perfect algorithm that reads your mind about what you want. As I said, in some cases, it's correct that 1 & 3 should align by stem, in some cases it is correct that they be offset. No matter which decision you make, it's wrong half the time. You make your choice and know that there will always be cases where manual adjustment is necessary.
So yes, the above example is one that will currently require manual adjustments (assuming that, aside from the overlapping rest, the picture indicates the desired result. If I changed the defaults to perform that sort of offset automatically, it would just break the many cases where people rely on voices 1 & 3 aligning by stem. As I've mentioned, one reason I made the choice I did is that it is easier/safe 9with respect to future layout changes) to manually unalign notes that are aligned by default than to manually align notes that are unaligned by default. It's perhaps not the strongest reason, but it was the tie-breaker for me.
In reply to I thought the stem of Voice 2 by chen lung
BTW, this is one area where we *could* actually revisit post-2.0 with no loss of compatibility. We could add a "Voice 3/4 offset" parameter in Style / General / Notes, defaults to 0 for 2.0 scores at least, but we could either continue with that or change to something else if we decide it really is better to offset by default.
In reply to BTW, this is one area where by Marc Sabatella
I wouldn't be comfortable with manual adjustments, but I think I would be happy with some kind of setting.
I think it should be a local one, rather than global as I sense scores could feature a mixture.
In reply to I wouldn't be comfortable by chen lung
What's the difference between a "local setting" and a "manual adjustment"? There isn't one. Whether you do it by click and drag, arrow keys, or the Inspector, it's the exact same thing. There is absolutely no avoid the need for these sometimes.
In reply to What's the difference between by Marc Sabatella
Manual adjustments can only sometimes be good - either in the version or static medium (e.g. PDF) used.
The layout could be ruined if you were to make another alteration, use the file in a future version (different internals) or on another medium (e.g. app).
With a local setting, the layout will be more resilient against such possibilities.
In reply to Manual adjustments can only by chen lung
First, I still don't understand what you perceived to be the difference between a "local setting" and a "manual adjustment". Either way, the effect is to tell MuseScore "for the following chord only, I want voice 3 offset from voice 1 by 0.5sp". There is *no difference* that I can see. Or maybe I am misunderstanding what you mean by "local setting".
Anyhow, while I agree that in general one needs to worry about manual adjustments made based on mere accidents of how layout happened to work - like adjusting a hairpin by visually rather than by actually changing the end attachment point - this is not such a case. If an adjustment of 0.5sp is the right adjustment to make voice 3 offset from voice 1 today, it will remain so forever, regardless of what reformatting you might do, what devices you view the score on, etc. That in fact is *precisely* why it is better to align by default. Had it been the other way around - we offset by some program-determined amount by default - then the people who applied manual adjustments in an effort to align the stems may find that this manual adjust is incorrect in the future as the formatting of the score changes, program defaults changes, etc. That's exactly why I said the current implementation is "safer". Manual adjustments made to force notes *out* of alignment are perfectly safe forever. Manual adjustments made to force notes *into* alignment depends on the accidents of how much the default offset happened to be for that particular situation, which could indeed change as the formatting changes, from program version to program version, between the desktop program and a mobile app, etc.
Given that is is *absolutely impossible and never going to happen* that layout is always automatically exactly what we want (it isn't even this way in LilyPond, and MuseScore is not LilyPond), what we must strive for is *logical*, *consistent* and *predictable* layout, so that manual adjustments have a known starting place. Starting out aligned *is* that logical, consistent, and predictable layout. Starting out offset by some program-determined amount would be very unsafe.
But that is why I said that that a style setting would actually be a safe enhancement. Rather than let the program decide on the appropriate offset according to the situation, you could tell the program what offset you want applied by default. That way, any manual adjustments you need to do will have a known starting point and will be guaranteed to be the good forever (or at least, until *you* change the style setting.
And again, make no mistake - you absolutely positively will still need to do some of these manual adjustments. Obviously, you will if you want some chords aligned - and that is actually an extremely common thing to do. But also, consider, any fixed amount you dial in as the style default will be right for situations but not for others. Small notes, dotted notes, whole notes and other larger-than-normal notes, other markings that might be present - there are *tons* of reasons you might still need manual adjustment (or the synonym that means *exactly* the same thing, a "local setting" for that chord.
In reply to First, I still don't by Marc Sabatella
If both layouts are acceptable where appropriate, I accept that, as well as the efforts to attain a high quality default.
Manual adjustment = moving the notehead 0.5sp.
Local adjustment = a radio button (or whatever) somewhere to either leave the chord as is, or 'offset' using internally-set parameters (determined in the source code).
I realise it probably wasn't as clear - sorry. Hopefully it's a bit better now?
Wouldn't a Style setting be global though? There maybe some chords in the score you don't want this applied to. Maybe I'm wrong.
I would probably prefer an internally strong and adaptable system that provides automatically fulfilled and managed choice if there's different avenues (such as we see here) as opposed to setting things manually.
The manual adjustment you mention might indeed serve (I see your point about the hairpin example), but I still have reservations as to whether the environment (or a changing one) and the 'stray' object will cope (a concern not limited to the subject of this topic).
In reply to If both layouts are by chen lung
When I mentioned a style setting, I didn't nean a checkbox that turns on some sort of automatic optimum-offset-calculating mode. I meant literally what I said - a configurable but fixed offset you set to be the amount by which voice 3 is offset from voice 1. So you might for example set it to 0.5sp, which would cause all voice 3 chords to be offset from voice 1 by exactly 0.5sp. You the user would choose the amount by which voice 3 is offset - it would not be some sort of automatic calculation by the program. So it wod be up to you to choose an appropriate value.
So when you spoke of a local setting, I assumed you meant "setting" in the same way I did - a numeric value for the offset to apply to a specific chord. In other words, exactly what the Inspector already does.
The way I described it - not an automatic calculation at all but rather a fixed value you dial in (much as you might dial in a font size) - is essential to gain the benefits I described in terms of it providing a predictable starting point for further adjustment. At least, that's necessary if the setting is global. Yes indeed, that one value won't always be correct, but it be consistent and predictable - always the amount you asked for, not some random value computed by tbe program. So it will be safe to use that as your starting point for manual adjustments.
A local setting that wasn't a fixed value you chose yourself but was instead an on/off switch - calculate and apply optimum offset or not - would be different, and could indeed be workable. But for as complex as it would be to implement, I don't see what advantage it would convey. It's barely any more work to apply a manual adjustment than to turn on an automatic adjustment facility, and as I keep pointing out, this is the type of manual adjustment that is easy and safe compared to trying to manually align notes that were offset by some unknown program-calculated value.
As a feature request for some point down the road, I wouldn't mind seeing the optional capability for more automatic adjustments like this (including something like Sibelius' "magnetic layout" perhaps). But for now, usable but consistent/predictable defaults that produce good results in a majority of common settigs are more important.
In reply to When I mentioned a style by Marc Sabatella
There is possibly a bug here anyway, but have a look at this:
Original:
![Original.png]( "Original.png")
MuseScore:
![Before.png]()
I tried to manually move a notehead to match the original. However, the preceding acciaccatura collides with the time signature:
![After.png]()
I know you question whether it's any more work to manually move something than to change a setting, but I'm still not confidant that there won't be some sort of mess surrounding the notehead to clean if something changes (e.g. deletion, applying something).
I accept quality default settings are priority for the moment, but I'm concerned there is an under-appreciation of situations like this. I think these automatic options will probably need to come sooner, rather than later.
The score was produced using MuseScore 2.0 Nightly Build (a3b24dd) - Mac 10.7.5.
In reply to There is possibly a bug here by chen lung
I assume you are talking about that first chord only?
First, to be clear: the default layout of that note in MuseScore is correct, not a bug. Voice 1 is higher than voice 2, no overlap, a second between the voices: this is a classic textbook example of where stems should align. The editor of the book you are looking presumably at chose to deviate from this common/standard/accepted practice for some reason, and presumably needed to make a manual adjustment in whatever software he used in order to accomplish that. So you will have to do the same as well. No bug so far.
Now, *maybe* it's a bug that moving the first chord of a measure to the left does not magically add more space before it as well, but maybe it's not. Roughly half the time, you might want the automatic extra space added (to keep things from colliding), and roughly half the time you might *not* want this (eg, you are deliberately moving the note closer to the barline, maybe even to the point of moving it to the left of the barline). Tow possible implementations of what happens when you move a note, and no matter which behavior I made the default, half the world will complain (or the whole world will complain half the time). The program can't read your mind and know the reason you are making the change you are making or whether that reason is better served by automatically allocating space or not.
So, I made the call I did - to make it easy to move a note *without* having everything change around it. This allows you to simply move a note and have everything else stay exactly right where it was - an incredibly useful thing at times, and almost impossible to achieve had I made the default the other way around. That is, had the spacing automatically changed to compensate, you'd be forever fiddling with parameters trying to get it back how it was, if in fact that was your goal.
On the other hand, with the current behavior - moving a note does *not* change spacing but instead there is a separate parameter parameter for that - it's trivial to force it to add space. If you move a note 2.5sp to the left and want 2.5sp space added to account for it, simply increase the leading space for the segment by 2.5sp. Done, perfectly safe, will always work exactly the same way. That's one of the beautiful things about these parameters acting independently in the first place. You can change one without changing the other, or you can change them both in sync - your call.
Now, the one area where I can see a *slight* potential issue is that the specific amount by which you will need to move the note will depend on the specific notation font you are using. Some will have wider noteheads than others and will therefore require you to move things a little further in order to reverse the order. So if someday you change fonts, you might need to revist your previous adjustments. I find it extremely difficult to get worked up over that, but would agree that an option to override the normal left-to-right order for chords like this could be nice. A fine low priority feature request for some point in the future.. But for 99.99% of the world, they would be perfectly happy just moving the note themselves if they were so convinced they'd wanted to change the already-fine layout. It's easy, it's safe unless you change fonts, and it doesn't add more complexity to the program.
In reply to I assume you are talking by Marc Sabatella
Yes, I was just talking about the first chord.
Sorry I was a little vague - the possible "bug" I was referring to was about the lack of extra space being generated, but indeed, it may, or may not be wanted.
About the chord itself, I had wondered if the editor or programme moved the B♭ because the grace note will be closer and the glissando won't clash with the C. However, it could have been an improper rule present throughout the song, so I would accept that MuseScore is correct - in accordance with 'Behind Bars'. Despite this, the main purpose was to demonstrate that manual tweaking doesn't always work, or suit.
In reply to Yes, I was just talking about by chen lung
I'm not saying the editor was wrong the override the default. Music typesetting - like music itself - is an art, not a science. There is no :"correct" and "incorrect" for many of the decisions made. Just personal preference. The editor of that book made the choice he did, perhaps for the reason you guessed - in his personal opinion, it looked better in that particular case because of the other elements present to reverse the usual order. A different editor might make a different chocie.
Anyhow, my point is that manual adjustments *do* work, if you do them right. In this particular case, since you want to move the note *and* add extra leading space, you naturally need to adjust both parameters. Simple as that.