Multiple rests
The attached file has a number of instances in the band parts where two adjacent rest bars are refusing to condense into one two-bar rest. I have tried cancelling and reaffirming the command.
| Attachment | Size |
|---|---|
| I Saw Three Ships Ab Transp.mscz | 400.15 KB |
Comments
Which part(s) exactly and which measures in those?
I can't find any, there are some where the time sig changes, those can't collaps into a Multi measure rest
The only places I see where adjacent empty measures don't combine into multimeasure rests are bars with time signature changes (eg, bars 12-15 in the Eb cornet part). I see a couple of places where a measure that *appears* empty is not combined, but closer examination shows the measure is not in fact empty. Eg, measure 62, which contains text. Delete the text and the measure gets combined with measure 61.
If you are having a problem you think is *not* just a case of a misunderstanding like this, please tell us exactly which measure in which part to look at.
In reply to The only places I see where by Marc Sabatella
Thank you. It happens also in the three horns, Glock, Xylophone and Drums. I believe the text you refer to is in the Eb Tuba marked 'SOLO" (in the score) in which case I think I'll have to accept the problem. Thanks again, JM.
In reply to Thank you. It happens also in by John Morton
As I said, I was talking about the Eb Cornet part, measure 62. The text is "Cresc. through to E", which you have dragged to make it *look* like it goes with measure 63, but it's actually attached to measure 62. Just delete it and re-add it in the correct measure.
In reply to As I said, I was talking by Marc Sabatella
So, because the text is System text not Stave text it affects everything in the score. In my experience of various notation programs this problem is unique to MuseScore. The notation content of bars and instructions to the player should be independent. I'm puzzled by the need for the text to be dragged and how this wrong location occurred in the first place but we'll never know now.
In reply to So, because the text is by John Morton
From the handbook:
The distinction between system text and staff text matters for part extraction in ensemble scores. System text will extract to all parts. Staff text will only extract to the part to which it is anchored.
See:
https://musescore.org/en/handbook/text-basics#staff-and-system-text
System text is never hidden by the "hide empty staves" feature, which is why the 'Cresc. through to E' (system text anchored to measure 62) caused the multimeasure rest to not condense into one two-bar rest.
(I also noticed an errant 'Cresc. through to E' text at the very bottom of page 7.)
Regards.
In reply to From the handbook: The by Jm6stringer
I understand how things work, Jim. I didn't use 'hide empty staff'. The errant text you refer to would not erase so I had to drag it outside the print area, which worked.
In reply to I understand how things work, by John Morton
instead of dragging it somewhere to hide it: select, hit 'v' to make it invisible
In reply to instead of dragging it by Jojo-Schmitz
Yes, Jojo, I could have done that, too. In fact I've done it many times.
In reply to I understand how things work, by John Morton
FWIW, text can be deleted by selecting it and pressing Delete, same as other elements. This works just fine on the text in question (the "Cresc. through to E" on page 7). If it appeared to not work, one thing that occasionally happens is that you might have accidentally placed two identical texts directly on top of each other, so pressing Delete only deleted the top one, leaving the one underneath and fooling you into thinking nothing happened. Hard to say without precise steps to reproduce, though.
But in any case, FYI, dragging something off the page area is normally a bad thing to do that causes problems later, as the object may reappear on another page and become impossible to select.
In reply to FWIW, text can be deleted by by Marc Sabatella
Once again, selecting and pressing delete is something I've been doing for many years. I just did it again and it worked. Something strange is going on. Surely, if I had two instances, one on top of another, which happens in graphics programs also, I would only have moved the top one, leaving the other in place.
Re: the bad thing you speak of, I was happy that it worked on this occasion, that's all.
The playback is hideous because of transposition probs. I created this score layout from scratch because it doesn't use the traditional layout. Unfortunately, MuseScore used the F tuba (brass bands use the Eb) and, although I made necessary alterations on 'paper', the playback is still wrong. Although, in the USA, low brass players use bass clef in 'concert' pitch, you will know how things work in Britain. There were other strange problems affecting playback but I'll have to note them properly for you next time it happens. The Bb tubas are written two octaves and a tone higher and, although there's a suitable clef for the Eb tuba, there doesn't appear to be one for the Bb.
Please play the concert pitch version, if you wish, file attached. I made no attempt to mix since this was done in Logic Pro.
In reply to Once again, selecting and by John Morton
If there were two copies of the text, and you tried to delete, the top one would be deleted, leaviung the bottom. You;d then conclude the delete didn't work, so you'd try moving it instead, and sicne now there is only one copy, the move would work. So, this *could* explain what happened. Again, impossible to do more than guess without precise steps to reproduce the problem, but this is the most plausible explanation I can think of.
Your transposition problems are the result of a misunderstanding as to how it works. You are perfectly welcome to use the British brass band tradition of treating tubas as transposing instruments, but you need to tell MuseScore you wish to do that, and if you wish to enter notes at written pitch rather than sounding pitch, you need to tell MuseScore the desired transposition *before* you enter notes. And you need to make sure you are *not* in concert pitch mode if you wish to enter notes as transposed. If you wish to enter notes while in concert pitch mdoe, you need to enter them at *sounding* pitch.
MuseScore actually provides correctly configured Bb and Eb tubas for British brass bands - simply type "tuba" into the search box in the isntruments list and you will see both "Bb tuba (treble clef)" and "Eb tuba (treble clef)" available. So when creating a score from scratch, you can simply let MuseScore set that up for you.
If however you are importing a score from MIDI or some other source, or have already created a score for the standard tubas rather than the transposing versions, then you will have the standard non-transposing tubas, but you can still fix this yourself. So I guess this was the case. What you could have done was go to Staff Properties right away and change the Play Transposition to down a major sixth plus 2 octaves (I think that is correct for Eb tuba in British brass bands?). Then, check the status of the Concert Pitch button before entering notes to be sure you are entering notes at the correct pitches. If you wish to enter them at *sounding* pitch, make sure Concert Pitch is *on*. If you wish to enter them at *written* pitch, make sure Concert Pitch is *off*. Also, be sure to get the clefs right. Concert pitch mode still would generally want bass clef of course, because the sounding pitches really are low, but changing ther clef to treble while concert pitch is *off* will let MuseScore know you want to use treble clef while in that mode.
As it is, it looks like you entered the notes at the desired written pitches without ever setting the transposition, so indeed, the pitches are now wrong. When you go to tell MuseScore the correct play transposition, it will transpose the written pitches and keep the current *sounding* pitches, because normally, when used correctly, this is what you'd want. In this case, however, you are starting off with the wrong sounding pitches, and they will remain wrong after changing the play transposition. So, you will need a second step to correct the pitches - you will need to actualy select the contents of the staves and transpose them via Notes / Transpose.
In reply to If there were two copies of by Marc Sabatella
Thanks you for your considerable time. The text was ascribed to the wrong bar (not guilty) so I had dragged it about anyway. If your theory is correct why did the image underneath not disappear when I clicked and deleted it again and again and again? I've just opened the file and the errant text at the foot of the page has reappeared! And the correct text, above the top staff (stave) won't select, no matter how I click on it.
I always assemble my scores in concert (I understand how all that works) and then transpose. Thank you for the info on all this re correct sequence of steps etc., there are are some pointers there that will be useful.
Eb Bass is up one octave and a major sixth. (Men were often absent due to industrial injury, illness, shift work or trade union activity so musicians would swop around the instrumentation and needed a familiar setting, hence the treble clef everywhere [except bass trombone], used also with tenor trombones - despite the fact that they are slide instruments, usually.)
Another complication is caused by the tradition in brass bands of referring to 'Basses' not 'Tubas'.
Thanks again, JM.
In reply to Thanks you for your by John Morton
You're welcome. It was of course just a guess about the overlapping elements. I syupposed it's possible you had, say, 9 of them, and you pressed Delete exactly 8 times before giving up, so you had exactly one left. Or it's possible a speck of dust was temporarily interfering with the operation of your Delete key. Again, all we can do is guess right now, best to just not worry abut unless you ever find steps to reproduce the problem reliably. Since no one else has ever reported any similar problem (all other cases of someone having difficulty deleting an element turned out to be perfectly understandable cases, like the overlapping elements, or an element dragged to another page and hence no longer selectable at all, or someone trying to use the Backspace key instead of the Delete key etc), it seems pretty unlikely that you'll run into this again unless it really does turn out to be a hardware problem.
In reply to You're welcome. It was of by Marc Sabatella
The problem has worsened. I checked on the printed, bound, finished score and found that the text in question had not printed . I inserted fresh text but now this text is refusing to accept attributes. I want 12 pt bold italic but I can only get 10 pt regular (not bold).
I agree we should draw a line under this for your sake. Despite the various problems MuseScore is still a joy to work with in terms of the way the user interacts with notation on the page, especially cutting and pasting etc.
I wonder if the page break tool I had used at one point might be to blame for the ghost image of text. (It destroys the bar numbering scheme.) No need to reply and thanks again, JM..
In reply to The problem has worsened. I by John Morton
Text that cannot be deleted and does not print is absolutely the tell-tale sign of exactly what I said before - dragging a text (or other element) so far away from its true position that it goes right off the page. And yes, adding page breaks can exacerbate this - you might drag an element four inches to the right and it might still be on the page, but after changes to the lcoation of line and page breaks, that same four inches to the right might move it right off the page. That is why it is vital *not* to do what you did in the example above - drag text a long ways from where it is actually attached. It simply leads to problems later. Again, that is *not* the case with the text on the bottom of page 7 right now - if it were, you wouldn't be able to select it in order to have dragged it there.
So it is very important hat you correct all these errant texts - any place you dragged an element more tha a fraction of an inch, you are asking for trouble. If you *really* want to fix this, you should do Ctrl+A to select all, then Ctrl+R to rest all positions of everything back to the defaults, and then revisit all the manual adjustments you made. Any time you feel inclined drag anything horizontal more than the distance between two notes, or vertically more than the distance between two staves, this means you attached the element to the wrong note or staff in the first place, so you should delete it and add it correctly.
Not sure what compeltely unrelated problem you might be having chaing font size - should be as easy as editing hte text, Ctrl+A to select the full text, changing the size in the toolbar. My guess is you are skipping that second step - you are editing the text, but you haven't actually *selected* any of the text, so the change you are making isn't being applied to anything. MuseScore works the same as most text editors / word processors in this respect. If selecting the text before trying to change the size doesn't solve your problem, please open a new thread in the support forum, attach the score, and tell us precisely swtep by step how you are trying to change the size, and we'll be able to show you what the problem is.
In reply to Text that cannot be deleted by Marc Sabatella
Again, I've been selecting text for many years and know how it works. I've just opened the score and the text is correct; 12pt bold italic. I have printed evidence it wasn't correct late yesterday. The file has been lying, untouched on the computer, since then. Now that IS strange. MuseScore doesn't behave like other programs at all. Firstly, I have never had this problem with any other program (including earlier MuseScores) and secondly the way MuseScore handles text is a nightmare, with so many avenues and different windows to do the different types of edit. I didn't drag text far away, either, just a short way to account for the fact that it was two bars out of place, for reasons I don't understand. I'm going to duck out of this now. I'm a practical man and it's easier to find workarounds than to spend so much time on here but THANKS for your considerable, even tempered time!, JM.
In reply to Again, I've been selecting by John Morton
you don't need to drag text very far away, even one measure can be enough, if then, possibly at a later time, a system or page breaks at that spot comes into play, moving the draged text to outside page boundaries.
In reply to Again, I've been selecting by John Morton
Well, I'm sorry I couldn't help. If you ever can find steps to reproduce a problem, feel free to post them here. But for now, the only logical assumption is that somehow you did something wrong, since this really does work when things are done correctly, and presumably you are finding it is working correctly for you now too. Do be careful about finding "workarounds", though, as often time the workarounds that appear to solve one problem just cause others down the road later, as we have already seen seen here. it really is better to udnerstand and actually solve the problem by learning how to do things correctly.
Dragging text two bars *is* a long ways. It means if those two bars end up *not* on the same line later because of some future edit or some future change to the layout algorithms, that drag will be completely inappropriate. That is, measurs 45 and 46 might be adjacent *right now*, so moving two inches to the left might move the text from 46 to 45, but at some future point, measure 45 might be at the end of one line and 46 at the beginning of the next. So now, that same "two inches to the left" starting at measure 46 won't put it anywhere near measure 45 - it will move the text right off the page. Leading to exactly the problems you have been experiencing. That is why, again, it is crucial to attach text correctly in the first place and not move text from one measure to another - it just won't work reliably over time.
In reply to Well, I'm sorry I couldn't by Marc Sabatella
I didn't introduce the idea of 'a long way' into this discussion. If the fact that the file printed out incorrectly and yet was correct the next day, without intervention, doesn't convince the developers that text is a problem in the program then nothing will.
In reply to I didn't introduce the idea by John Morton
Your example shows at least two exaqmples of text that were in fact dragged a sufficiewntly long ways from their true position to cause *exactly* the type of problem you are seeing (text that appear on screen but won't print, text that cannot be deleted), text that causes otherwise empty measures to not be included in multimeasure rests). it is quite clear from your posted exampe that you *have* in fact dragged text far enough from its true position to have caused all three of these problems.
As far as I can, the issue with a file printing differently than it looks on screen could well be just another symptom of this exact same problem. That is, a text dragged so far out of position that it ends up on another page will casue *exactly* what you described above: it will look one way on screen, another way on the print (the "ghost" element that might appear on screen definitely won't on print).
If you believe you have a case that can *not* be explaiend by this - and *also* cannot be explained by the fact that you are also having an issue where you apparently have a file that is being saved in two different locations - then what we would need in order to investigate further is what we always need: a sampel score and *precise step by step instructions to reproduce the problem*.
In reply to Your example shows at least by Marc Sabatella
This is turning into a squabble. I didn't deny moving text. I wondered why I had to do this (blaming the page break tool, which affects page numbers also) and commenting that MuseScore is complicated in its approach to the various types of text editing.
I inserted NEW text, because the text in preview would not select. It was the NEW text that refused to accept attributes, printed incorrectly and yet was correct the next day when I reopened the file.
The present problems do not occur in other programs, justifying my criticism, I believe.
In reply to So, because the text is by John Morton
All programs I know have the equivalent of system and staff text. it is up to you to use the proper one. if you want it to apply to just one staff, use staff text; if you want it to apply to all, use system text. That's the whole point. It's not a "problem", it's the way it is supposed to work, and needs to work. If text attached to a staff - whether because it is staff text attached to that part alone or system text attached to all parts - didn't break multimeasure rests, that would be a bug.
In reply to All programs I know have the by Marc Sabatella
I appear to have misled you. Yes, I understand about staff/clef and agree it's normal and very useful but the program's failure to allow multi-rests because of adjacent text is surely inconvenient, to put it mildly. I'd rather lose the text (which happens in Encore) and drop it in again. I can't recall this happening in earlier versions of MuseScore.
In reply to I appear to have misled you. by John Morton
if so that was a bug that got fixed ;-) staff text is supposed to Interrupt multimeasure rests for that staff, system text is supposed to interupt multimeasure rests for the entire system, all staves