Lines (crescendo, diminuendo) not very useful: do not survive reformat

• Apr 19, 2009 - 20:10
Type
Functional
Severity
S4 - Minor
Status
closed
Project

Windows Vista Ultimate 32-bit, MuseScore 0.9.4 revision 1753
Write some music, add lines (crescendo, diminuendo) that start left aligned to one of the notes in the middle, that span one bar line and end right aligned before another note in the middle.
Then do anything that causes the measures to be automatically reformatted: the lines are shifted left or right, have a different size and basically need to be all redone.
Lines are not anchored relatvive to notes, during automatic resize they are repositioned at random and their size also seem to acquire a random value.


Comments

I'm not sure you set the anchor positions correctly in the example you attached. You can see the anchor positions by double clicking on the lines and moving the handles with the mouse. The dotted line that appears shows which note the start or end is anchored to.

Also could you share a version of the file before you had problems with the file and then list steps for reproducing the problem.

I do not understand what you mean.
If I double click on the right-hand side of a line (crescendo for example), then I the line becomes blue and a brown oblique dotted line appears, connected, strangely to an unrelated location at the following measure. To me this means that the dotted line that I see does NOT show which note the start or end is anchored to.
What should happen, is that the brown dotted line should instead be a vertical bar that has a tendency to prefer to stick to the stems of notes, and if the user drags the vertical bar in between notes, then MuseScore should remember the proportion / ratio between each note stem.
This way when the music is reformatted, a line (crescendo) that was intended to start at the second note of bar 9 and to finish just before the second note of bar 10 will still indicate that.
At the moment, formatting causes start and end of lines to go at random places not related to the original placement.

Also I do not understand why you ask for steps to reproduce the problem. I have given those steps. Maybe it would be more accurate for you to say that you do not understand what the problem is, and as I have done with the latest file uploads, I would gladly (but slowly as I am busy otherwise) draw the problems in full details with arrows and big text.

Status (old) active by design

The brown dotted line does indicate the anchor note. You can extend the cresc/decresc lines beyond the anchor position (as you have done in this case) using the arrow keys or mouse. However, if you extend it too far then it will look wrong when you reformat the score (as you discovered).

As a solution make sure the begin and ends are anchored to the notes you intend to anchor them to (using shift+arrow keys). You may have to counter adjust the lines (using the arrow keys or mouse) to remove the adjustments you made earlier.

Status (old) by design active

I have tried both manual move of the line start and end as well as using note accurate position using arrow keys.
If this is by design then the design is wrong. When you reformat and then use shift right key (or shift left key) then the line end is confused and moves to the wrong place (does not stick / jump to note stems). Not a feature that helps anybody, hence the title of this bug report: "not useful".
Would you want me to rewrite the code?
I would also like to see the crescendo, diminuendo and dynamics replayed in MIDI, this is not in yet, would you want me to help with them.

I have done what you explained (thanks for that) and my problem is now solved: I have made sure that all brown dotted lines are vertical (the line's start and end exactly start and end where the anchor actually is), and now reformatting stops garbling the lines.
So I will rephrase the issue report:
Having a - mostly - invisible line anchor located any further than a note away is not useful and confusing.
What should happen is that, when the line start or end is dragged using the mouse, then the line anchor should move from the original note to the note nearest where the current line start / end is located. At the moment the line start / end anchor always remains at the same location, unless "Shift Left" or "Shift Right" is used.
There are quite a few features in MuseScore that only really work if you use a non-overlapping combination of menu, keyboard and mouse. For a good non-confusing user interface, all user interactions should be orthogonal: full repeat / duplication of all interactions / features from all possible interfaces (so if you have 100 features in the menu, you should have 100 keystroke combinations, as well as 100 mouse / right-click-menu gestures / widgets).
For example delete measure only works if you Control-Click first the measure, then hit delete; this is really not a good intuitive user interface, not a useful tool. Of course all can be documented away, but documentation itself can be ambiguous. So better stick with a simple orthogonal set of interfaces; the principle of "least astonishment" for the users.

An example of "non-orthogonality": select a note, add a system text, then decide to move the text to the next note (or the previous note): "Shift Right" and "Shift Left" are not implemented, therefore the only way to change the anchor is to delete the text, select the new note and recreate the text.
In object orientation / pattern based software design this can be solved by abstracting all "anchorable objects" and associating the "Shift Left" and "Shift Right" interface to all of them, then have the lines (such as crescendo) and the system text implement this "anchorable" interface, thus forcing the implementor to write code to make "Shift Left" and "Shift Right" work.
How can I get in the MuseScore devs and have a look at these issues?

Thanks for your help so far.

ok thanks, I have managed to get SVN's trunk for a few weeks now, and since I found out about -Wl -S (i.e. removing it) I can now also run gdb with symbols
I will look at how to move the anchor to a more useful nearby note, and also I will look at implementing "Shift Right" and "Shift Left" for all anchorable objects, and I will look to add righ-click menu options for these features.
Any voting system for patch file inclusion, who is the build master, any peer review process?

Merci

If your changes are big, I think it's better to talk about them in the mailing list when you submit your patches. Werner is the lead developer and father of the project and will control your first patches I guess. Several people are able to build from the SVN and review the changes in term of usability.

You can attach your patch to a comment in this issue and refer to if you feel it necessary to talk things through on the mailing list. I believe this issue tracker should be enough to get the discussion started.

I agree that it would be nice if the anchor positions snapped to the notes automatically when you use the mouse (I've often wished it would). I've also wondered (to myself) whether we should make the snapping behavior default for the left and right arrows (the current behavior of shift+arrow). And use alt+arrow for small nudges (similar to Inkscape).

I agree with your comments on Ctrl-click for deleting measures. I made a suggestion about this back in September when MuseScore actually had three types of selection, each with a different feature set. In version 0.9.4 or later MuseScore has only two selection modes with different feature sets (dotted selection for deletion and normal selection for everything else) but a unified selection mode would be much better. http://davidbolton.info/articles/musescore_top_usability_issues_0.9.3.h…

Newbie, so I hope not to be navigation noodle and cross lines badly.
Recently I downloaded MS 1.3 to mac osx 10.8. Two small scores completed to date and both looking quite good, except for a persistent problem. I checked the handbook, gave a little time to browsing around yet so far have not come up with an answer. So I'd be grateful if someone could point the way to a solution or suggest one off the top of their greater experience.

The problem: how do I dot the F note in a G7 chord?

I can't imagine this is a bug since just everything else works fine - there's a niggle about oversized type in rehearsal marks - but I can live with this until I can't [ :-) ].

Help!

thanks for that answer jojo-schmitz.
I checked your proffered links.
As to "new forum topic" I have just discovered that my access to it is denied.
As to the 'note-entry' and 'voices' I had consulted the handbook prior to making comment, with no luck whatsoever.
This morning - having slept on it so to say - I am left wondering if the bass line of note F is masking or obscuring the dot. Else proximate note G is displacing the F dot duly entered per handbook instructions.
If, as you indicate, I am raising a now defunct query in all this allow me to apologise. My quest is sincere and appropriate directions/help most welcome.
Also apologies to other users, though as you see no other access is available to me.
Normanj