Grace note engraved out-of-order relative to note in another voice
Hi there,
Brand new user here, first post. Happy new year everyone, and thanks for such a great software!
I'd like to hear opinions whether this is a bug, or a false expectation on my side. I'm just a hobby wanna-be-musician, not professionally trained or expert or anything like that.
With MuseScore 4's reworked engraved engine, I've faced the following situation. If a bar is quite squeezed, it's possible that a grace (flam) note (on the snare drum, voice 1) is engraved more to the left than a note of the kick drum (voice 2), even though chronologically the kick drum gets hit earlier:
As a non-professional, I find this confusing and counterintuitive, I'd expect the notes to be laid out from left to right in chronological order. Is such engraving buggy per se? Or is it okay for musicians, while probably being frowned upon, bad practice? Or is this absolutely okay and accepted among trained musicians?
I've found a couple of bugreports about wrong playback of grace notes, but not about wrong rendering. Sorry if I missed a duplicate.
I've experienced this with 4.0.0 and Nightly-230010309-master-3969d79 (AppImages downloaded). Didn't have this problem with 3.2.3 (Ubuntu Kinetic package).
Thanks in advance!
| Attachment | Size |
|---|---|
| grace-out-of-order.mscz | 15.31 KB |
Comments
Such layout issues are quite common where multiple voices are concerned, including when voices cross staves. This is as true in 4.0.0 as it was in 3.6. You'll need to play with Leading Space and Offsets to correct this.
https://musescore.org/en/handbook/4/positioning-elements
In reply to Such layout issues are quite… by memeweaver
Although not explicit to me from your answer, it feels to me from your wording that these are issues (bugs) specific to MuseScore, and not a common thing in the music notation world elsewhere. Am I on the right page?
Moreover, it feels to me from your wording that they are probably known by the developers, and have been known since the 3.x era, so me reporting a bug would be pointless?
According to https://youtu.be/Qct6LKbneKQ?t=2020 [Tantacrul's video about MS4] @ 33:40, "The primary focus of engraving is to achieve two things: the highest possible legibility and the highest possible beauty." For me as a non-professional, out-of-order notes is anything but easily legible.
Putting on my software engineer hat:
I see that 4.0 brought many improvements in horizontal spacing addressing some reeeeally hard problems, resulting in a different layout than in 3.x, meaning that users might have to manually adjust the earlier manual adjustments (i.e. incompatible change, requiring considerable amount of user action).
Yet, a seemingly much easier to fix bug (i.e. chronological ordering) fell through the cracks (or was deliberately left out?), and if / whenever the devs decide to fix it, it will again result in an incompatible rendering, requiring user action again.
This does not sound too wise of a choice for me, ideally they all should've been addressed at once, so that user action is required only once.
Do you happen to have any insight into this?
The music typesetter me can easily fix the layout with the help of the link you gave. The software engineer me believes that this (chronological order) should be the default behavior, without requiring user interaction.
What am I missing, where did I incorrectly assume something or draw an incorrect conclusion?
Do you think that a patch that makes chronological ordering the default, or maybe even enforces such rendering no matter what, would be appreciated by the developers and users? Depending on time and motivation and feedback and such, i might give it a try as a fun exercise (no promise).
Thanks!
In reply to Although not explicit to me… by egmontkob
V4 has brought many changes but its poor stability. sluggish performance and the temporary(?) withdrawal of many v3.x features indicates it is late alpha quality code at best.
The example you provided has the measure so crushed up that the grace notes simply cannot fit in chrono order, so you're getting a compromise between your desire for minimal horizontal extent and showing all the stuff you've crammed in there. It's possible that other notation software suffers the same "problem" or attempt to fail gracefully.
Stretching the measure to a reasonable size allows the appropriate rendering. (If you want to see horrific rendering open the mobile app on a phone screen! ) Enforcing a chronological rendering in a tiny display area will mean adjustments to all the score elements: staves, noteheads, steam and beam thicknesses. There are dozens of horizontal spacing parameters in a bar : look at the Style options dialog.
In reply to V4 has brought many changes… by memeweaver
Well, I did not ask the software to crush the bar this much :-). I simply entered the score, bar by bar. (I did so with an actual score, but simplified it for the sake of this forum post.)
My expectation would be for the software to not squeeze the bar this much, rather, in this particular example, break like after maybe 7-8 bars instead of 10, so that it has enough room to render the first (well, any) bar in chronological order.
Does this make sense?
> It's possible that other notation software suffers the same "problem" or attempt to fail gracefully.
I'm hardly familiar with MS (started using it about a month ago) and not at all with any other music typesetter software. So let me rather ask this: Would a printed score, by a well respected publisher, ever contain such out of order situation? What do real musicians think of such rendering, how acceptable is it?
In reply to Well, I did not ask the… by egmontkob
MS clearly doesn't get all the spacing issues right, particularly in this prematurely-released v4.
Grace notes have a lot of issues: https://musescore.org/en/node/310776
I have raised another issue where barlines inserted between triplets are not "in chronological order" with respect to other voices. https://musescore.org/en/node/19887 (*)
The MS long-timers will most likely recommend usage of work-arounds with manual spacing tools - and short of code enhancements - that is what you are left with when it comes to producing properly rendered output. I will note that the manual spacing tools aren't always up to the task, or produce undesirable effects later on the page, especially if multiple occurrences of a work-around situation are required.
(*) In the case of the tuplet/barline issue the claimed workaround only works for a single voice - the triager rejected evidence without giving a reason - which left me with having to work with quite fragile work-arounds.