Stem direction with multiple voices
This is m15 of Bartok's Microcosmos #144.
Attached is a one bar test.
In the lower staff, beat 4, the stem directions of voice 2 are set to down, but do not go 'down', when they are beamed together.
There are other issues in this bar, such as the misplacement, location, of the sixteenth on beat one, and the overlapping of the dot for the half notes, E and F, but I will post on these later. The spacing improves when I use "Disable Autoplace".
While editing this bar over the past 3 days, MuseScore has hung 3 times. I have had to Force Quit.
| Attachment | Size |
|---|---|
| voices___stems test.mscz | 6.48 KB |
Comments
Would conceal Voice 1
In reply to Would conceal Voice 1 … by Shoichi
What / who would 'conceal' [not in menu] conceal? The word 'conceal' does not appear in the Handbook.
I copy/pasted and transposed the previous beat, and it worked. The immediate problem is solved. Thank you.
I assume "conceal" in this context is meant as another word for "hide" or "make invisible", which is done by pressing "V" or using the Inspector.
For beamed notes, because different on the same beam can have different stem directions, it is the beam direction and manual adjustment that "wins", and that seems to have been forced into a custom position (one can see this in the Inspector). Normally, you wouldn't need to mess with any of those settings manually, - simply pressing "X" on any one beamed note sets the beam direction automatically, while leaving the stem direction at "auto" where it should be in these cases.
Really, though, there should have been no reason for any of the manual adjustments you made there - voice 2 is already set down by default. So even pressing "X" should be unnecessary - the defaults would have been correct.
There also seem to be other inappropriate manual adjustments that are adversely affecting the position and spacing of things - strange offsets on individual noteheads as well as stems, etc. Any idea how the score got into this state? Was it a MusicXMl import, or just kind of experimenting with different settings?
Really, just re-entering this bar from scratch is probably best. But it's still going to be the case that the unison and second together with conflicting noteheads on the first beat of the top staff will require some sort of intervention to make look good. Unless there is a really good reason to show the dotted half F, I wouldn't - it's creating more notation trouble than it's worth. But if you're trying to be faithful to a published edition, you'll need to force the dot above, and also offset the chord (not the note and stem separately) to the left for the sixteenth.
As for autoplace, this measure is taking as much space as it does only because it is alone on the measure and allowed to stretch. Add more notes and it looks better. Disabling autoplace in that case will not work, as it will allow things to literally collide (accidentals with the note before, etc). At most, consider disabling it only for the accidentals that are the most problematic, or using leading space adjustment here and there to close up some gaps.
In reply to I assume "conceal" in this… by Marc Sabatella
Thank you. I understand what you have written. Entering these particular measures have been a nightmare. There have been times when entering or correcting notes in voice 3 or 4 has not been possible because the interface / window, when use use the arrow key, jumps back to beat one in the measure, voice 1. I have discovered that in some of these cases, I had hidden notes in the voice, and could not access them in note entry.
My experience with MuseScore freezing three times, requiring Force Quit, in my experience, indicates to me that there is some kind of underlying fundamental problem in the note entry function. I have already entered over 4500 bars of these pieces without experiencing these issues.
I have lived through, and continue to live with the dreadful 'two accidentals before two noteheads' on the same stem. The accidentals are not always in the same order as the noteheads. This I find a minor annoyance compared to how the simultaneous presentations of clusters is handled.
I am moving on from this piece shortly, and will wait for fixes before trying to finish it. It really isn't that I don't understand this. I've been writing clusters for more than 55 years and using notation programs regularly since 1988. As I have said elsewhere, I am among the .03% of users who would run into these things.
If I could find the solutions in the documentation, I wouldn't bring them here. It is often, not that they are not there, but I can't find the correct 'museScore' word it, so search the documentation without success, until you, or some else translates what I am looking for into the terminology that musescore uses.
Thank you for your time and help.
In reply to Thank you. I understand what… by kevin.austin@v…
Entering notes has to be left to right. So it's normal and correct that getting a note into voice 3 starts at the beginning of the measure, same with 1 or 2. So just enter rests. If you don't want to see the rests, mark them invisible. Some people choose to actually delete them, but I don't recommend that because it leaves an uneditable "hole" in the measure, which may be what you mean. If you accidentally do that, just use voice exchange (with voice 1) twice to recover the measure.
No idea about the freeze, if you figure out how to reproduce that, be sure to post with steps to reproduce.
Accidental ordering should be correct according to standard principles of engraving in most cases - and that definitely is not supposed to always be "same order as noteheads" as I assume you realize. Accidental stacking works on entirely different rules than notes. The accidental stacking rules are rather more subjective than note stacking rules, but they are "reasonably" consistent between engravers. We implement an algorithm that produces results that might not be exactly the same as what any one given engraver would produce but should be one of the possible correct arrangements any engraver would approve of. That said, there are some known rare exceptions, mostly involving unisons. If you've studied accidental stacking rules and believe you've found a case where it's opposed to standard practice, please post separately about that as well and include the specific example so we can add it to the list if its not one we know about already.