Fingering Issues in 2.0
I was having trouble with the fingering palette in v1.2 and discovered that double-clicking vs. drag-and-dropping on the note gave different behavior vis-a-vis respecting the Text Style settings. I was encouraged (http://musescore.org/en/node/18723#comment-74697) to try the nightly build (cce7968) to see if this is still a problem in v2.0. That particular issue isn't there, but there were several others related to fingering placement/font. I thought these were sufficiently closely related to go into one post, but if these should be split into multiple posts, someone please let me know. Otherwise, here goes:
I started from the default Promenade file and duplicated the 1st two measures so that each test I did would be using a consistent set of notes. See attached for the final result.
Measures #1/2, started w/ the default text settings. Drag/drop or double-click produced the same results. There is overlap with other score elements, but at least it was consistent. Chords are apparently designed to be handled differently than single notes (which makes sense), in that chord fingerings are placed to the side of the note rather than above/below. However, this only applies within a given voice.
Issue# 1: If multiple voices combine to make a chord, any single note within a given voice will be placed above/below instead of to the side. See the 4th chord of measure #2 as an example.
I then changed offset to X = 5.00, Y = -5.00 (mm), font size 12, bold. This applied the font setting to all the existing fingering marks, which is a good thing from my perspective, but I assume most users would want to have it be an option.
Issue# 2: When editing text properties of an individual fingering in v1.2, there was an "apply to all elements of this style" check box in the lower left hand corner to provide this option. This box is missing in 2.0 apparently. I would suggest restoring it, and placing it on the "Edit Text Styles" version of the box as well.
Measures #3/4, the offset of X/Y for newly entered fingerings was no different, despite the change of the settings as detailed above.
Issue# 3: Text Style settings for offsets are ignored when entering fingerings. This behavior is the same regardless of drag-and-drop vs. double-click method of adding the fingering.
After this I happened to click on something or another that caused a crash (measure# 2 had a note that was deleted inadvertently, not sure what exactly caused the crash when I tried to re-enter it). When I re-opened the file, the fingerings were moved around -- but only for single notes, not the chords.
Issue# 4: It appears that what is happening is that the offset is only applied when the file is opened. The net impact is that the fingerings move farther and farther away from the notes each time the file is opened (presuming it was saved after the previous open). In the attached file the distance of the fingering from each note is dependent on when the fingering was entered vs. the number of times the file was saved and re-opened.
Issue# 5: Also, it does not appear to be possible to move the fingerings manually at all. They don't respond to the mouse the way they do in v1.2 currently. It would be ideal to be able to use both mouse and keyboard (since keyboard allows for more precision and consistency).
I tested and none of the issues above are present in v1.2... in the case of Issue# 1, this is because chords and individual notes appear to be treated identically to begin with.
This is my first issue/bug post... is there anything else I can/should do to be helpful on this? Thanks!
| Attachment | Size |
|---|---|
| Promenade_Example_fingering_testing.mscz | 7.19 KB |
Comments
Thanks for doing this. I try to always include my operating system as well, although that may be obvious to most.
Regards,
Sorry... I forgot about that. I'm using Vista SP2, Home Premium.
The issue of string numbers (fingering panel, numbers enclosed in circles), failing to retain the position they had when the file was saved appears to still be an issue as of nightly build MuseScoreNightly-2014-06-30-2332-505c48b. The fingering numbers that are not enclosed in circles appear to retain their position when the file is re-opened.
I use the numbers enclosed in circles to annotate fingering as the circles make the numbers easier to pick out from the rest of the score. However every time I open a score in Musescore 2 I have to re-position all my fingering markers. However if I revert back to Musescore 1.3 I lose the repeat playback facility that is proving so useful when I am practicing.
Since the problem appears to have been fixed for the fingering numbers not in circles could not this fix be applied also to the numbers in circles.
I have attached a sample file. Move the position of the circled and non-circled numbers in the first two bars and then save the file. Then close musescore 2. Then re-open musescore 2 and re-open the file you will see the circled numbers have moved away from their saved position, whilst the non-circled numbers have retained their position.
I am using windows 7 home premium.
Kind regards
Johnathan
I can confirm the bug. But I would also observe that using string numbers when you really mean to use fingerings is not a good solution. If you like circles around your fingerings, you can change the Text Style for fingerings to use the circles.
I investigated the cause of this, and it's not what I expected. It seems that the text style for string numbers has the Y offset set to -5sp, but this is being interpreted differently when the file is read than when the string number is initially applied. Positioning for fingering elements - both regular fingerings and string numbers - does not use the text style when the fingering is applied. But when reading a score (from a file, or from the clipboard in a paste), the text style *is* honored.
The immediate fix is probably to change the default style for String Number to have 0sp for Y offset. But we should also consider whether we should either be honoring the position settings (to provide an offset, perhaps) in the text style, or perhaps disabling them. As it is, even if we fix the default for String Number to be 0sp for Y offset, if the user ever changes it himself, he'll continue to get very strange results: the change will appear to have no effect until save/load or copy/paste.
BTW, this also suggests another workaround - see the String Number text style Y offset to 0.
But again, better I think to use the regular fingerings but change the Fingering text style to use circles.
Hello Marc,
Many thanks for looking into this so quickly.
I'm not sure where the -5 offset came from originally however setting it to zero has given me the work-around.
The ability to mark fingering with and without circles is very useful. Whilst I prefer circles so that I can pick out the fingering more easily when I read the score, I also use numbering without circles e.g. to remind me that a bass key is a counter bass.
When annotating fingering for a diatonic instrument such as a melodeon I can use the circles or absence of a circle to differentiate between notes played on the pull and the push. Given a 50 / 50 split between circled and none circled fingering changing the text style for fingering to manage the display of circles would not be practical. So it works better for me to be able to treat both the fingering and string numbering sets of numbers as ways of annotating fingering.
Is it the case that because the two types of numbering are identified in MuseScore specifically as relating to fingering and string numbers respectively, that the two numbering types will be treated in some way differently by MuseScore? Other that is than having separate style settings.
Kind regards
Johnathan
Conceivably, yes, they might be treated differently in some way. That is why I suggest using the "proper" type. But in reality, I don't know that it matters. Note you can invent your own custom text styles and apply them. But actually, right now, the only difference I can see internally between fingerings and string numbers is the difference in text style. So it probably doesn't matter which workaround you choose.
Fixed in 13a58ff57f
Automatically closed -- issue fixed for 2 weeks with no activity.