Copying Objects
I'm only going to include one example here, but it happens with other objects, as well. From the screen cap provided, you can see that I've just copied the music and lyrics from Staff 2 to Staff 1. Everything went fine with the exception of the slurs - not how distorted they are in Staff 1. This (again) points to the notion that the Copy & Paste function as well as the Slur tool is not 'aware' of what the user sees and instead perform arbitrarily on their own, forcing the user to edit the results.
First of all, even if the tools were designed to 'suggest' a default condition based upon the notes being positioned differently on the staff, who has ever seen a slur in a piece of music with such a bizarre angle assigned to it? If a user would indeed wish to display such an animal, then that user alone should be forced to do the editing. For the rest of us, the standard angle parameters based upon the intervals of the notes and their distances apart should be the default setting.
Secondly, if the user is performing a Copy & Paste, the general default condition is that s/he is expecting to receive what was originally copied *as it appeared* in the original. After all, why bother inserting, editing, etc., prior to Copy & Paste if the tool is simply going to arbitrarily change what work has been performed?
| Attachment | Size |
|---|---|
| CopyTies.jpg | 181.28 KB |
Comments
Posting actual scores and steps to reproduce always beats screen shots. But i',s reasonably clear in this case what is happening. The copy operation tried to copy the slur, but since the dirction of the stems differs because of the clef difference, the specific shape of the slurs differs as well, and any manual adjustments made to the initial slur ended up being inappropriate to the new one. So copying it *as it appears* makes no sense - you'd have upside down slurs. But enhancing the program to detect cases where attempting to copy the slur too literally would cause problems and to therefore just reset to a reasonable default sounds like a nice feature request. That is, you made manual adjustments to create an incorrect slur according to the ordimary rules of music typesetting, and it tried to copy your manual adjustments literally, but of course you woild not jave wanted to make those same manual manual adjustments given the difference in stem dirction. Seems like a straightforward enough enhancement request.
In reply to Posting actual scores and by Marc Sabatella
What you're saying is that the Slur tool is designed to relate the lines to the notes as they appear (stems up or down) and not necessarily *where* they appear. Again, this is a little off when it comes to intuitive use. Traditional composing techniques keep *both* of these elements in mind when the composer has to choose how to display a slur or tie.
I guess the 'enhancement' would be for the tool to first comprehend that not only must it indeed 'oppose' the direction of the stems, but that the calculations that it uses to figure angle have to be more in line with how the line would normally appear. In the example I provided, it seems as though the tool couldn't 'understand' the initial adjustments to the Line 2 slur in terms of remembering them, and instead used them to recalculate the bizarre angle of the pasted lines.
Here's where the interface issue creeps in again, however. The user is placed in the rock-and-hard-place situation of using the defaults of the tool (requiring editing of each line), or performing the editing first then having the tool either not 'remembering' what editing has taken place, or 'remembering' and performing the re-draw based upon what it calculates in lieu of what it should be observing on the screen. In the case I provided, if the original line's notes were X-distance apart and at Y-slope angle, then I believed the Paste process utilizing the Slur tool (again, which is the culprit?) would also see that same X/Y factor and respond accordingly. (This is why I painstakingly waited until I positioned the measures on Line 2, spaced them properly, and included all the notes and lyrics prior to performing the Copy & Paste. I wanted to give the Paste/Slur function the least excuse possible for changing the angle of the slurs.)
Interestingly, the Tie tool seems to have no such intelligence built into it. It routinely inserts the ties bowed in the unorthodox direction, requiring the user to fiddle with them to get them to point them in the more normal direction. An enhancement here, in place of the 'stem intelligence' that is built into the Slur tool, could be to offer a popup menu option offering the user to 'flip' the tie 180 degrees without having to reposition the four edit points on the line. (I see that someone else has already written about this in a previous post.)
Screen 'awareness' has been a part of applications for many years now, and most folks have not only gotten used to it, but have come to extensively rely upon it. When copying and pasting in MS Word, for example, the Paste tool for a long time has offered the user two fundamental options: insert what you copied *as you copied it* or insert the raw data and permit it to be formatted based upon the environment it's going into. The former forces the environment to conform to the Paste material's format; the latter forces the Paste material's format to conform to the target environment.
When lacking such a choice (and it's OK if it *is* lacking), the user has to fall back upon what s/he sees on the screen. Interestingly, this concept works perfectly when copying and pasting notes in MuseScore. No matter what 'key' I'm pasting notes in, not matter what clef, etc., MuseScore faithfully copies the pitches into my insertion point * as they are*. Sure, I might like more robust functionality allowing more 'intelligent' pasting of the notes, but as long as MuseScore remains consistent with its note-pasting function, as a user, I can make plans as to whether to Copy & Paste, or simply create new notes. Since the consistency of the note pasting is great, I've gotten more and more skilled at using it resulting in more efficiency and a better overall experience.
Trust is a huge issue with an application, and the interface is a user's primary means of exercising it.
In reply to OK, I see this... by greg.winters.10
"It routinely inserts the ties bowed in the unorthodox direction, requiring the user to fiddle with them to get them to point them in the more normal direction. "
X flips the direction of any selected tie, note or slur.
No need to fiddle with the Bezier curve.
In reply to OK, I see this... by greg.winters.10
There are indeed a number of issues already psted - many of them already resolved for the next major release - regarding default tie direction. So the need for manual adjustment will go lessen! Thankfully.
But your adjustment was to a slur, not a tie, and the default shape was correct - you modified it to be non-standard. That's fine, but as Michael said, you should have done that with a simple flip, and then MuseScore could have reproduced this more simply. It still wouldn't know if you'd want it flipped in the new position, so whatever it guessed, it would have only a 50% of being what you wanted, but at least, correcting an imcorrect guess would be a single click. As it is, MuseScore doesn't really know how to intelligently copy actual curve adjustments in the presence of change of direction or other differences in the default shape. Seems there is a pretty low chanc of ever being able to guess what the user intended, which is why I suggest the enhancement be to *ignore* manual adjustments when copying in cases where the default slur would have differed.
In reply to There are indeed a number of by Marc Sabatella
Yes, the logic of doing the flipping first makes more sense - reduces, but does not eliminate, the need to change the angle. The point of my post was, however, that my ignorance of the tool and its sequence caused me to do all the work for the tool - positioning the music, spacing the measures, etc. What disturbed me was that after I had set things up to do what amounts to a virtual mirror copy, then the curves of the slurs went all over the place.
This 'gradual' approach to copying slurs seems to get around that, but after performing a few tests, it seems that there still indeed are cases where adjusting the music first is easier than tweaking slurs, especially in composed passages where there is a number of like figures.
In reply to X is good by greg.winters.10
The thing to keep in mind is that as far as I can tell, manual adjustments to a slur are probably stored as simple numeric adjustments to the control points - X mm horizontally by Y mm vertically (or perhaps using sp as the unit, so the adjustments will scale more easily). Copying a manually adjusted slur seems to just copy those adjustments quite literally. In order to turn a slur upside down. You probably dragged the middle control pojnts way far up, and perhaps pulled the outer poonts down a bit. Reapplying those adjustments to a slur that was already curving downward is what presumably produced the shape shown in your picture. Indeed, not what you'd want hardly ever, and it would probably be possible to come up with a "smart" algorithm that was based more on the *results* of the original adjustment than the specific way those results were obtained. Strikes me as a pretty good idea, probably implementable, should this ever rise to the surface in priority, but I still figure it's only 50//50 that it would guess right. For instance, in this case, is the desired result to have a slur turned upside down - meaning it should appear below the noteheads and curve upwards in this case - or is the desired result a slur that is fixed above the noteheads regardless of notehead position? One could conceivable expect it either way. So I still figure any such smart algorithm is unlikely to be much of an improvement over an alogirthm that simply ignores manual adjusts if there are differences in stem direction.
In reply to The thing to keep in mind is by Marc Sabatella
The idea behind the default choices in a Copy & Paste situation would be the understanding that the original appearance would be the preferred first choice. I don't understand why a default condition would choose otherwise. For example, there's only one way to copy the appearance of something, but an infinite number of ways to deviate from it. How could the user complain if the application pasted what the user sees, providing only the automatic flipping if the note stems had to change? The curve angles would remain the same since the insertion area with all its layout spacing would remain intact.
In the abstract, this might sound rather far-fetched. In a word processing application, for example, the layout of a particular block of text is obviously of secondary importance to the text itself, therefore, a paste operation seeks to 'transplant' the text information into a single insertion point and 'write it out' from there. In music composition, however, the horizontal and vertical layout of the score is just as much a part of the musical 'text' itself as the notes and rests. One would figure that after a manual re-adjustment of the original insertion, that when the application is asked to Copy the new configuration, it would Paste it, as well.
The reason the example I provided is curious is because in the original line of music (Line 2), all I did was *collapse* the angle of the curve somewhat, but when I pasted the notes into Line 1, the angle of the curve dramatically *increased*. Nothing else had changed between the Copy & Paste operation in this case, including the direction of the stems.
In reply to Keeping traditional composition standards in mind by greg.winters.10
I am confused. Are we talking about the same example? In the example you posted, it appeared your adjustment In bar three was not to flatten the slur - it appears you stretched it so far it move from its natural position below the staff to a new position above the noteheads, and also turned It upside down! Normally, that slur would have appeared *below* the notes, curving upwards. Are you saying that was not the case? If so, then that seems like a bug right there - that slur never should have shown up above the noteheads. Can you get *that* to a reproducible case? But also, the stems are very clearly different: the source has stems up in that measure, and the destination has stems down - this is indeed the whole reason the issue exists.
Anyhow, I thought my description of the ambiguity very clear. In your example, I can see the source slur in either of two ways:
1. It is a slur that has been moved to the opposite side and flipped upside down from the stamdard position and shape
2. It is a slur that is above the note heads, curving downward
In the destination, both of those cannot be true, because the stem directions differ. So an algorithm would have to choose which of those two properties to preserve. It appears in this case, you wanted to preserve #2 and sacrifice #1, but someone else may have wanted it to preserve #1 and sacifice #2. And in any case, simply reverting to the default in cases where stems differ - whch is what I have been proposing - would have produced the desired results in this case with less effort.
In reply to I am confused. In the by Marc Sabatella
Yes, I changed the angle and the position of the slur to show that the Paste function did not remember the new positioning of the slur. You can clearly see that even though the stems have changed direction, the curve of the slur remains in the same direction as relative to the top-bottom of the score ('bent upwards'). What I had expected to happen was that the Paste function would 'see' the original modifications and mimic them in Line 1, but when that didn't happen, my original question was to ask why the Paste function overrode the changes I had made and even ignored the change in stem position. Looking at the pasted music, the user can't see any reason for those awkward looking curves - they don't seem to conform to any consistent positioning *or* changes made.
I don't see this as a case of setting one aspect of the slur against the other, but capturing the essence of the position as a whole. Thus, in Line 2 of my example, the position of the slur has been changed from 'outside' the stems (the proper default insertion to 'inside,' and (obviously) curving away from the notes (the way that slurs are normally created). One would expect that instead of the default Paste result (see attached Slur-before.jpg) that it would be instead as illustrated in Slur-after.jpg: a complete mirror based upon the flipped stems. Note that the spacing of the notes in the measure as well as their relation to one another was perfectly preserved by the Paste function, thereby giving to 'reason' for the slur to be mis-shapen.
In reply to Yes, same example... by greg.winters.10
You don't want much, do you! ;-)
Music notation is quite complex, in that there is a lot of meaning packed into a few symbols, and very few hard and fast rules. It's hardly surprising that a software developer doesn't think of everything that thousands and thousands of users might do. Which is why there are a number of bugs which can be seen as "sins of omission", not just coding mistakes.
Imagine you are setting out to specify a new music notation application. You have to understand not only current good practice, but many variations, as well as obsolete conventions (which are still in use for medieval music). Then imagine you are designing the code. It has to be flexible enough to handle all "expected" user behaviour and ideally a lot of "unexpected" behaviour. All this is before you even write a line of actual code - and there are many lines, with complex interactions between the various functions.
MuseScore has come a long way in the past two or three years. It is now a serious option which compares quite well with the alternatives. It is way ahead of the notation software I started out with about 15 years ago (Music Works 2.3, which was at least as buggy, much harder to use, and nowhere near as capable). Please keep on pointing out potential bugs and realistic feature improvements, but I am not convinced that MuseScore is as poorly thought out as you seem to think. I agree it could do with a bit more consistency, and no doubt there are some more oddities lurking, but there are plenty of people using it happily and effectively. It will be interesting to see how version 2 turns out - I haven't had an opportunity to play with the nightlies yet.
In reply to You don't want much, do you! by Jon Foote
Well put.
Regards,
In reply to You don't want much, do you! by Jon Foote
...you're missing the point of my posts. Granted, there are indeed cases where things can go either way in the function and interface based upon user preferences, but then again, the art of music composition is far older than computer technology. The question you would ask yourself is: Who would want a slur in the shape of a boomerang?
Each issue I posited had to do less with the hard-core function of the tool and more with the display of the results that the user would see to base his/her following work upon. I believe the questions about disappearing text, 'jumping' scores, and unusual alignment are valid: not because I don't believe that the tools should not offer these variances, but that the tools seem to force them upon the user *by default*.
If I would be designing my own music application, I would first start out by researching as many scores of classical, jazz, and pop music that I could find and gain a general understanding as to the general layouts of the music artifacts. In the case of our slur, for example, I can guarantee you that you will have to search long and hard for one in the shape of a boomerang. Then, I would code the slur tool to default to certain curvatures and positions when the user has specified none, then next apply the curvatures which were modified by the user when the user copies and pastes.
If there was someone who insisted otherwise, say, s/he wants a boomerang-shaped slur, then *that* person would be the one who would have to perform the additional editing. To a programmer ignorant of musical objects and motifs, a slur is simply a mathematical algorithm, and any and all variables that would/could be submitted to the equations are fair game. This kind of thinking is in error. In music, there is a range of curvatures of slurs which are recognizable to experienced composers and readers of music and all of the others are simply 'unusual,' at best.
The other issue I raised has to do strictly with user interface, and I've described the detail of this extensively already. Text disappearing or not disappearing may programatically be the stuff of equal binary choice, but in the world of humans users and common sense, these conditions are not even close to being equal. In what use case could there be a deliberate condition that if a user has deliberately created something that they would wish the application to automatically cease displaying it? If such a use case were to exist, common sense would demonstrate that it would be a *manual* process or at least a pre-configured auto-process known to the user in advance which would determine this behavior, but certainly not a default condition rendered by the code.
Any code which is designed to 'handle' every possible usage of the musical objects and treat all conditions as peers is not very intelligent code. 'Possible' is not the same as 'normal,' or even 'rational.' The very fact that Western music has time-honored practices of writing and reading demonstrates right from the start that the coding behind the musical objects should not treat them as simply as 'shapes' to be manipulated at whim, but as real objects constrained to standard composition practices - by default, then permitting the gradual introduction of variance as users present good cases for them. 'Free form' out of the box only confuses people, makes them clamor for their own 'improvements' and presents a general free-for-all in the development realm. Sooner or later, somebody's 'fix' breaks somebody else's 'feature.'
The reason I'm stating these things is precisely what you point out in your post: there are indeed complex interactions between the various functions. Without considering the consequences of these interactions - in terms of music and WYSIWYG - prior to development of the features themselves, there is no guarantee that the inconsistencies of behavior in the UI will ever be eliminated.
In reply to Yes, same example... by greg.winters.10
Ok, but then did my explanation not make sense? It seems MuseScore simply copied the *actual X and Y adjustments* you made, not the end result. Which might not be want you wanted in this particular case, but that's only because of the very special corcumstances: one is the huge and very non-syamdard nature of the changes in the source (turning it completely inside out instead of simply hitting X) combined with the change in stem direction. In the vast majortiy of cases, this would never come up - just as it wouldn't have here had you used used X instead of the extreme non-standard slur adjustments. In most cases, MuseScore's algorithm works just fine.
Even if one wanted to discuss the issue of "what if" someone had really needed to make such slur adjustments, it's still the case that once stem changes are involved, there is basically no possible way to predict how you would want that slur to look. Which is why I'm proposing manual adjustments be cleared on copy/pase if stem directions don't match. Becuase for the reasons I already explained, there is just no way a program can guess how you'd want the slur to look in the presence of stem changes. Here at least both stems changed; it's even worse if only one had. The general case - when more than two notes are involved and stems are mxied in the source as well - is going to be completely unsolvable. So again, just have it reset to defaults on paste and that's really the best one can reasonably hope for. Which of course you can get right now by simply hitting ctrl-R immediately after the copy.
So this all seems much ado about nothing - this almost never is an issue in practice, and even in the cases where it is, it normally still works fine unless stem changes are involved, and in the cases where stem changes are involved, a simple reset positions is all that is needed - again, not a total redisign of the UI.