Fix misaligned v.2 note?
Hey guys,
Thanks for replying to my various threads here. As it happens, my family and I moved shortly after I posted them, and the chaos is only just now subsiding... I'll follow up on everything as soon as I can!
Meanwhile, can something be done about this?:
I tried selecting the D and using the Inspector to change its X (horizontal) offset, but only the notehead itself moves, not its stem or beams. (How can that ever be useful, BTW?) Thanks!
Comments
In the Inspector, look under where it says 'Chord' to change the x offset of the note, the stem et al.
In reply to In the Inspector, look under… by Jm6stringer
That worked! (A bit unintuitive, though... Why would "Chord" imply that it included the stem and beam?)
Also, as I increased the D's "x" offset, rather than moving it to the right, I was surprised to see that it moved the E-natural to the left instead:
Was this because the E-natural was actually the misplaced one? (That's how it looks, anyway!)
Speaking of second voices, is this MS's default behaviour?:
(Bass clef) I entered both D's, then returned to the first one and typed + ("tie") – that's correct, isn't it? (It seems like it'd save many keypresses if we could just create tied-to notes in one operation, BTW.) I realize I can fix it by moving the tie's left end, then moving the timing dot slightly to the left, then moving the end of the tie back... But this seems a bit laborious. Is it a general formatting oversight, or does it happen only in this kind of situation?
In reply to That worked! (A bit… by Andy Fielding
Regarding the disticntion between note and chord - think about a multi-note chord - C E G all on one stem. The stem is what is shared between all notes of the chord, the noteheads are the only things that differ. That's why MuseScore and other music notations tend to make that same distinction.
Ties most certainly can be entered in one step, as described in the Handbook - after entering the first note, select the duration for the second, and press the tie button. That enters the second notes and the tie together.
In most cases, ties are smart enough to avoid other markings, but there are a few cases where this doesn't happen. This is being worked on and should be improved in MuseScore 4.
In your case here, if your goal is to move the dot, no need to move the tie first - just select the dot directly and move it right away. Either by selecting the note then the dot button in the Inspector, or by zooming in to click it directly, or if that proves difficult, Ctrl+click repeatedly to cycle through overlapping elements. Although I'd actually probably leave the dot alone and simply adjust the tie a little.
As for what is going on more specifically with which note moves in which direction when a given setting is changed, the answer is "it's complicated". We'd need a really specific example - not just a picture, but a specific score and precise steps to follow, in order to explain what might be happening in that particular instance.
One note - the original issue here is that this isn't a voice 2 note most likely, but a voice 1 note from the other staff. Collisions are automatically avoided between voices on a single staff. Only these cross-staff cases are note. So a practical way of solving this would be to enter that middle voice onto the top staff instead, and move the first note down, instead of entering it on the bottom staff with the rest of the notes moved up.
In reply to One note - the original… by Marc Sabatella
Sure—but it should really space itself correctly, shouldn't it, without having to resort to such workarounds?
If there's going to be a cross-staff beaming feature, it should work properly or not be there, wouldn't you say?
In reply to Sure—but it should really… by Andy Fielding
There's more than just one issue with cross staff notation, see #285233: [EPIC] Cross-staff notation issues
In reply to Sure—but it should really… by Andy Fielding
> "If there's going to be a cross-staff beaming feature, it should work properly or not be there"
Someday we'll release spaceship grade code; until that day we'll work with what we have and improve what we can.
In reply to > "If there's going to be a… by jeetee
The proposition that any feature that doesn't work "properly" should be removed seems to be throwing out the baby with the bath water. Cross staff beaming works in as much as creates cross beamed notes. It doesn't yet automatically avoid clashes. However, manual adjustment can be applied to rectify clashes. I would much prefer that situation than not having any possibility of cross beamed notation until auto-avoidance can be sorted out.
In reply to Sure—but it should really… by Andy Fielding
In general, most of the time you want the collision avoidance, so someday hopefully someone will volunteer to implement this.
Meanwhile, though, no reason to throw out an entire very useful feature just because occasionally you need to spend a few extra seconds fixing things. You're welcome to not use it if you want to restrict yourself to only using perfect things. But we're not going to remove something that thousands of other use successfully every day.