Problem when horizontal shifting an interval in 2.0
If I want to move a note to the right and using the 1.3 way by
double clicking it and using the CTRL + [arrow key], 2.0 behaves like 1.3 but when I want to move an interval for instance a crotchet third, then after this action the note heads are moved but the stems are still at their original positions. Is there something changed in 2.0 or did I forgot something to do?
Comments
The better way to move things in 2.0 Beta 1 is via the Inspector, where you can control if the the entire chord (noteheads + stem + flag, etc) moves or just the notehead. But it *should* be the case that, as with 1.3, double clicking a notehead of a single note chord and then moving it with the arrow keys will appear to only move the notehead, but when you exit Edit mode, the stem should follow.
In reply to The better way to move things by Marc Sabatella
O.K. Doing it via the Inspector does the job.
No need for the 1.3 way to do it.
In reply to O.K. Doing it via the by JoeAlders
Agreed, no *need* for the double click & arrow method, but it is supposed to work, and does work for me. If you have a case where it doesn't, could you post the score and steps to reproduce?
In reply to Agreed, no *need* for, but it by Marc Sabatella
I don't understand the reference to horizontal intervals (e.g., a 'crotchet third'), but I have a comment about horizontal displacement generally.
MuseScore 2.0 handles voices better; that's what we've been led to expect, and it's certainly true as a general statement. There are times when one might want an overlap, though - a completely congruent overlap - as when a single note is shared by more than one voice. I am still trying to suss out what kind of behavior is predictable, and if there are differences between native 2.0 scores and ones imported from 1.3 - but, generally speaking, I am having more difficulty than before getting noteheads to overlap precisely than was previously the case.
Also, on a similar note - it would be helpful in 2.0 documentation to describe the functional differences between Note, Segment and Chord as they appear in the Inspector. Right now, I'm still finding out things by trial and error (which, just to be clear, is fun to me ... though others might not agree).
In reply to I don't understand the by [DELETED] 448831
Unisons are handled specially by MuseScore. This was true in 1.3 as well, but buggy. For 2.0, MuseScore follows standard conventions of music notation well, so there should not normally be need to override the defaults. The standard convention is, unisons should always show two separate noteheads *unless* the voices have opposite stem directions *and* they use the same type of notehead (quarter/eighth/sixteenth, or half, or whole) *and* they have the same number of dots.
I say these are standard conventions of music notation, and they are - *except* for guitar music, which uses a different set of conventions :-). But we made allowances for this. If have two unison notes that are not merging because they have different notehead types or different number of dots, you can force them to merge by simply setting one of them to have the same notehead type as the other (using the Inspector). So no manual shifting should be necessary if order to make unisons merge.
There should not be differences between new scores and ones imported from 1.3 - we actually strip away all manual position of notes from 1.3 so we can apply the new algorithm. The same trick of explicitly setting notehead types worked (mostly) in 2.0, so if you used that trick in a 1.3 score, it should look the same in 2.0. If on the other hand you used manual adjustment to force the notes to merge, that will be undone - since, as you've doubtless noticed, the default position is different (better, according to standard convention), so the old manual adjustment would not produce the correct results any more. So instead, you'll have to apply the notehead type trick.
In reply to I don't understand the by [DELETED] 448831
BTW, I'm sure the documentation will describe the Inspector, but here's the quick rundown.
Imagine a chord consisting of several notes on a guitar staff, in a score that also contains other instruments.
"Note" settings affect just one note within that chord. Basically, just the notehead itself plus any dots associated with that note, and playback parameters for that one note.
"Chord" settings affect the whole chord - this includes the stem.
"Segment" settings affect all staves - every note or rest on any staff on that same beat.
In reply to Agreed, no *need* for, but it by Marc Sabatella
Here a sample where I have used 2.0:
In the second measure the first third, I used the '1.3 way':
Selected the g and executed CTRL + [arrow key], then selected the
e and executed CTRL + [arrow key]. The stems did not move.
The second third I used via Inspector the 'segment' for the horizontal shift. The result was a shift of the stems too.
The third in the third measure I used the 'element' for the shift.
So selected the g and adjusting the offset, then selected the e and adjusted the offset. The stems did not move.
In reply to Here a sample where I have by JoeAlders
Ah, yes, the move-notehead-and-hope-the-stem-follows currently only works for single note chords, apparently.
If you want to move the entire chord (including stem, also flag, accidentals, etc), you should use the Inspector with either Chord (which moves just this chord) or Segment (which moves all chords that occur on this beat - including chords in other voices or staves). Note the Segment isn't a literal move necessarily - it adds leading or trailing space, which depending on what else is going on in the layout, may or may not actually have any apparent effect at first. For instance, if the space before a chord is already being padded by measure stretch, then you'll have to add more that amount before you see an effect.