Disappearing Staff Text
This issue is related to the 'jumping' that I've noted in my original post to this forum. Note from the first MissingText.jpg image (attached) that the word 'Chorus' which belongs over and to the left of the third staff is completely missing. Now, examine the other attached image, MissingText1.jpg, you can see that after a little 'pushing' of the measures (back to where I had originally set them), part of the text appears, but seems to be also partially obliterated by what I'll call the 'page canvas.'
First issue: why does the UI permit items which have been properly inserted *into* the page to move *off* the page onto the page canvas, at least if the user does not perform this move manually? I have never worked in any sort of photo editing, desktop publishing, or word processing application that does this. I would venture a guess that since the MS page canvas obscures the the text (instead of simply 'parking' it), then this is where my Staff Text 'disappeared' in the first screen cap.
MS does this kind of thing regularly. Note that I did *not* move the Staff Text in order to make it appear, I simply rearranged some of the measures on the page.
Second Issue: the 'moved' text doesn't stay where it was if I navigate away from the window or move the page around. You can see in MissingText2.jpg that the measures have remained where I had dragged them in order to capture MissingText1.jpg, but now the text is gone entirely. *I have made no changes to the score other than to navigate away from the position where the text had appeared.*
Third issue: when I finally got the text to partially appear again (I really don't know how I did it this time), I grabbed it with the Cut command, selected the first note of the staff it belongs to (the way I always insert the Staff Text), and right-clicked and selected Paste. Nothing (see attached image with selected blue note). (This is an example of this mysterious Copy & Paste malfunction that I spoke of earlier.)
From the attached image MissingText4.jpg, you can see how I end up resolving this issue. I have copied the Staff Text from measure 30 over to measure 14, creating a fresh entry. (At this point, I've given up figuring out where the old Staff Text has disappeared to.) I edit this fresh entry to say 'Chorus,' then save the file.
Because of the issues I'm having with saving and reopening, the attached MS file may appear completely differently to whomever chooses to open it. This is why I've provided the step-by-step evidence to show you how this is behaving for me.
| Attachment | Size |
|---|---|
| MissingText.jpg | 126.83 KB |
| MissingText1.jpg | 47.16 KB |
| MissingText2.jpg | 40.5 KB |
| MissingText3.jpg | 45.19 KB |
| MissingText4.jpg | 143.35 KB |
| He Was There All The Time (K-Synth).mscz | 4.62 KB |
Comments
Staff text is attached to a specific note or rest. So if you attach text to a note or rest then manually position it way to the left or right, or way above or below, that default position, then any change to the layout (eg, "measure wrap" to use my word processing analogy) that causes the note/rest to whch the text is attached to move will obviously result in moving the text as well, and might indeed. Ove it right off the canvas. Seems that is the answer to your first "issue" - you positioned a staff text far to left of the the element to which you attached it, then when that element moved close to the left edge of the page, the staff text kept its relative position to that note/rest, which took it right off the page - just as it should. You should attach elements to the note/rest you want it appear near, not attach it somewhere else then drag it into position. MuseScore takes attachment seriously.
Hard to say without exact step by steps to reproduce, but it seems likely that everything you describe here is a simple by product of this. But if not, it may well be a bug, and getting it down to a reproducible series of steps wold help in getting fixed.
In reply to Staff text is attached to a by Marc Sabatella
This is fine, but then if the music layout shifts, how/why does it kick the Staff Text off the page entirely? Each time I've inserted Staff Text, I've endeavored to select the first note of a measure or the measure itself before Inserting (CTRL+T). If I've copied, then I've selected my insertion point then pasted (CTRL+V). If the insertion point has somehow 'moved,' then I have no idea how it has moved.
The only time I have ever varied from this procedure is when I have been creating Guitar tablature - I haven't decided exactly how this can easily be done. I create the Staff Text for the tabs and continue pasting on top of the same item in the bar (the invisible rest) until I have enough to cover the measure, then I copy and paste from those to insertion points in additional measures. The worst-case scenario of this practice is that the tab numbers should get crunched or spread out throughout the individual bars they have been assigned to, but - as is the case with the other Staff Text, they tend to 'follow' other points on the page besides their original insertion points.
Another way to look at this is in reverse: if MS permits the user to drag Staff Text to a new location on the page, but will "take attachment seriously" otherwise, then why allow this practice at all? It just gives the user the wrong impression that the dragging operation was successful and the text will now be faithfully relocated. If it is going to 'return' to its original insertion point, then I don't understand why it can be dragged somewhere else without either snapping back in its original placement or forcing the user to relocate the anchor insertion point.
In reply to Visual Results by greg.winters.10
There is a known issue that sometimes you need to reload the score (and sometimes restart MuseScore) in order to get some items to display after editing.
May I suggest you try that and see if it helps?
In reply to Visual Results by greg.winters.10
Well, as I said, without specific steps to reproduce this, it is hard to say, but the effect I am describing is just common sense: if you attach a marking to a note, then drag that markng three inches to the left, then that marking is now set to be three inches t the left of its default position and that relationship will be maintained as the score is reformatted. So if the note to which the marking is attached ever gets moved to less than three inches fom the lef margin, that obviously would push the marking right off the page. How could it not, other than MuseScore ignoring your manual positioning?, which surely would be a terrible thing?
Again, without specific steps to reproduce, I can't be sure that this is what is going on here. But it seems consistent with what you are describing. It is also possible it will turn out to be a simple bug, so again, steps to reproduce will help.
In reply to Well, as I said, without by Marc Sabatella
From what I gather in the Properties areas of Layout options, the message to the user is that the objects on the Page are constrained to working areas. I know this because the application uses terms which were common to the 'paper' world long before computers ever came on the scene.
One of these terms is 'margins.' A margin is something that constrains the data elements to a particular area of a working space. Well, since Staff Text has to be assigned to an element on the staff - something which, by definition, is confined within the margin parameters, then the user expects that it, too, will be constrained by those margins. It should take a deliberate manual override on the part of the user to get that object off the workspace.
You asked for steps and I thought I provided them clearly: I did *not* do any 'dragging' of the Staff Text to associate it with a different insertion point. I only moved it slightly (just a couple of sp) above the staff since the default comes in too low blending it with chord symbols. The condition I described happened in two different scenarios: 1) I used the Stretch tools on the affected area or somewhere else in the score; 2) I simply closed and reopened the file. In the first case, the Staff Text should simply 'follow' the insertion point around the score, and even if a collision occurs, it should stay faithful to margins. If it's out of place or crunched or the like, then fine - the user can see the 'damage' and modify the text's position according to the new positioning of the insertion point. But what logic would be behind the notion that the text should simply run off the page outside of the margins and disappear into oblivion? How is a user supposed to work with something that s/he cannot see?
This is what happens when feature/functions are assigned the responsibility of making their own GUI decisions. Obviously, whoever developed the Staff Text tool paid no attention to the standard defintion of 'margin' and instead created something that acts wholly on its own without regard to the layout parameters. Anything created or edited in a GUI is understood to be in context, not outside of the general env var settings of the layout and user preferences. All tools should answer to these by default and if exceptions are to be made, then *these* would require specific user intervention to override the configuration settings, not the other way around. Requiring that tools develop to this common standard would eliminate the necessity to 'debug' Tool A's product disappearing, Tool B's product disappearing, Tool C's product disappearing, etc.
In reply to Manual Positioning by greg.winters.10
My understanding is that the margin settings apply only to the actual staves. Text and other elements can freely be placed in the margins, and in fact I rely on that. If text, segnos, and codas could not extend beyond the boindaries of the staves themselves, you rwally would be pretty severely constrained. A moment's reflection should convince you of this. Maybe there could be two different groups of margin settings - one that affects only the staves, and one that also prevents oter elements from extending into them. But the current model is more or less exactly as it is done in every other notation program, as well as every deaktop publishing program I have ever used. Contrary to your claim, the diea of being able to place elements in the margins is practically universal to ebery profram in the world *except* for word processors, and even those allow headers, footers, and certain other elements like graphics or tables to exist in the margins.
As for instructions to reproduce, your instructions certainly give the general idea of what you did well enough, nut I've followed that same general procedure hundreds of times and never seen the result you describe. So there has got to be something more specific going on in your case that hasn't yet been adequately described. In order to reproduce a bug, there needs to be something specific enough that anyone could follow thos exact steps and see the same results. Something like, "open the attached file, click the bar line at the end of measure four, hit Enter". See many other threads here and in the issue tracker for examples of this type of format. It's got to be something *reproducible* following those exact steps produces the described result every time - in order to guarantee anyone would be able to identify and fix the bug. That's always what one should strive for in a bug report - assuming this does turn out to be a bug and not simply a case of what I am describing of an element being pushed off the page because of reformatting.