Wrong number of pre-prepared rests in a bar
There were dissimilar rests in an upcoming empty bar. Some were correct but others were not. It was a 4/4 bar but one line had only a single crotchet rest. This happened just after the entry of a bar with tuplets. I was forced to grey out the bar and make it an 'empty' bar and the pretext for the inclusion of a general time signature using the numerals in your symbol set. Then dispensing with overt time signature in the bar which followed. That allowed me to get past the obstacle.
Comments
Without seeing the score, I fear that corruption is creeping in and more problems may become evident. Hopefully deleting the bad measure corrected it as it sometimes does.
Hi
What MuseScore version and operating system are you using?
For future reports, could you read this ?
Thanks :).
The bad patch corrected itself after exiting the program without a save. I guess the 4 groups of septuplets in the preceding bar were seen by the program temporarily as having a value of 28/32 rather than a full bar of 32/32; and that it then made some kind of deduction from the next bar to make up. In the event it stole a minim from a 3/4 bar in the voices where I had had the septuplets. On re-boot, my septuplets were still there and the ensuing empty bars were all normal.
I spoke too soon: Musescore had reverted to the faulty version by ignoring my last save. But the good news is that I was able to resolve it easily by normalizing bars and deleting old hidden time signatures, and inserting a new 3/4 time signature just after the septuplets bar. I absolutely take Chen Lung's point about formal bug reporting - I guess he is a developer - but I did read the section prior to posting - and realized I did not have time to go into it that deeply, but just wanted to record a glitch. So it was not intended as a bug report in the formal sense.
That turns out to be correct. It is clear that there is a misconception lying at the heart of the program: that misconception is that at all times and in every place, notes need to be deducted from mensurated silence. This is wrong on one count, and of dubious practical validity on another: composers need to create scores calligraphically, not just mathematically; and thus may need an official option of being able to eg draw lines, arrows and so on on the score without these things needing to be underpinned by musical rules, and also an official option to turn of rest-generation if either in a tricky pass metrically or in case of wanting to write eg quasi medieval church antiphons in the manner of an earlier poster. What the program needs to do is implement things like that as workarounds for when things get unorthodox; but also - on tuplets - implement them as metrical entities of defined and varying mathematical import, not just as quasi-decorative add-ons. Because at the moment the program is endorsing the workaround of invisibilizing official rests when using tuplets; but it ought to be allowing tuplets to have similar, although more complex, mathematical effects on how much composable space remains in a bar, to that of official normal notes when entered. Critically, because that does not happen, tuplets can throw wobblies and when this is added into the mix, some part of the program whose job it is to make sure all things tally comes along and finds disparities, and so generates bars with wrong numbers of rests in them, bars into which in fact it is treacherous to proceed, as now, all rules are broken, nothing works. So I quit while ahead, saved the section, and now have to begin the remainder of the piece in a new file. I invisibilized one remaining line so the results will be quite usable, but it will not be a correct score in 1 sweep.
The issues with triplets are fixed in the upcoming 2.0. Once that version comes out in a more stable and testable form I'm sure it will be strenuously tested, esp wrt tuplets. Version 1.2 and previous definitely have issues with copy/pasting triplets.
It is clear that there is a misconception lying at the heart of the program: that misconception is that at all times and in every place, notes need to be deducted from mensurated silence. This is wrong on one count, and of dubious practical validity on another: composers need to create scores calligraphically, not just mathematically; and thus may need an official option of being able to eg draw lines, arrows and so on on the score without these things needing to be underpinned by musical rules.
That is highly debatable. Other notations don't work that way, and for good reason - most people also value playback, and playback needs to understand the intended timing of notes. Timing also affects spacing, and virtually everyone wants the software to calculate spacing for them. MusicXML import/export also assumes a certain set of musical conventions. That's why MuseScore, like virtually all other programs, wants notes to have well defined timings. Like other programs, MuseScore tries to allow you enough overrides to get the look you want (eg, manual positioning via Edit mode, hiding of rests) , but all such programs still have the same basic assumptions about the relationships of notes to time. MuseScore *does* allow you to draw lines wherever you want, and to place noteheads as symbols with no musical meaning (see the symbols palette that comes up when you press "Z"). These are separate from the ordinary flow of meter - real notes take actual time within a voice, symbols do not.
One could debate the merits of this type of approach - feel free to propose an entirely new notation built from the ground up to be graphical only and not adhering to the ordinary conventions of Western music notation in any way, shape, or form - but this issue report is not the place for that sort of discussion.
And in any event, the way the issue tracker works, the "assigned" field is to be the person who intends to fix the bug. Unless you are volunteering to do the programming necessary to fix whatever bug may exist here, you should not be assigning it to yourself. And priority "critical" is reserved for bugs that cause crashes or score corruption. At this point, without seeing an example, it is difficult to tell if you are seeing an actual bug at all or simply a misconcpetion about how MuseScore works, based on your desire for it to be a graphcial program only and not a musical one. As schepers says, there indeed known bugs with tuplets that can lead to corruption, but these have already been fixed in the next release. Posting a sample score and steps to reproduce would be necessary in order to tell if you are seeing an actual bug and, if so, if it has already been fixed in 2.0.
Hi
1. Regarding what critical or assigned meant, I did not know
2 I never said I wanted to change anything just maybe add a more flexible interface for extra text and graphics
3 If you'd like to see a screenshot of the place where the unexpected behaviour happened I can send it. Is it possible to attach a word doc to a comment?
4 It was only a glitch since the new file which I started did not throw up the same error.
5. Comments about how music is imagined or might be were not intended to be construed in the sense that there were significant inadequacies in the program - far from it. But it's by dreaming and questioning that things advance!
Many thanks.
Here are two examples of what I mean. Something throws out MuseScore after a litlte while, and it suddenly has bars without the trademark *correct* numbers of rests. Then it starts making these multiple vertical lines. A real weakness which emerges is that you cannot essentially create a complete score with varying moods and layout demands in one file; everything has to be set up in advance for one scenario. So if you want loose spacing at the start to accommodate complex chords, then later want a normal layout with correct bar lengths, the program will not do it. In general there needs to be more local control of the musical landscape, scorescape, desired.
The Navigator, however, is back! Thanks.
*or to be completely accurate, what the program then does is to create bars too long for the desired context, over whose length the user then has no control...
These appear to show what is general knwon as a "corrupt" score. There are a few scenarios that can lead to this in 1.2; most if not all of the know ones have already been fixed for 2.0. It would be helpful if you could remember how these corruptions occured, or better yet, if you can find steps to reproduce the corruption, that would nornally be the first step to being to identify the problem and fix it. Hopefully, though, whatever led to these corruptions is one of the known already-fixed issues, which mostly involve copy and paste with either incomplete tuplets, empty measures with 5 or 7 beats, and at least ne scenario involving copy/paste in certain multi-voice contexts. The first and third of these seems like they could have been in play.
Not sure, though, what you mean about layout and having trouble getting the bar lengths that you want. In general, this is not particularly difficult if know how. You may wish to start a forum thread showing examples of what you are having trouble figuring out how to do, and someone wil probably be able to show you how it is done.
Well under STYLE>Edit General Style>Measure>you can adjust the spacing from a default of tight. But once it is done, it will apply to the whole file you are creating, so far as I can see. So I do not think you can change from long open spacious bars to tighter bars within the same piece of music if that piece of music is to be created as one single MuseScore file.
Now that I have finished my 3-movement piece (which needed 7 pdf files!) I have a good impression of the program, but think it is very hard to enter text, and that it's frequently easy to spoil already OK stuff from side-effects of other actions. A way to 'freeze' stuff you don't wish to edit any more - as in Excel - might be useful.
Yes, but that dialog is not the only place you can control spacing. There are lots of other options, and in fact, most people probably never touch that setting. You absolutely can have tighter bars in some places and looser in others; it's quite easy, in fact., and I'm happy to help show you how. I just ask, again, that you *start a new thread in the forums* to ask your questions.
Please understand that this issue tracker is *not* the place for general discussion. You should only create an issue in tracker after you have verified that something really is a bug and that you have detailed step by step instructions on how to reproduce it. One bug per issue, and any discussion should be focused on that issue and that issue only. This allows the developers to keep track of the bugs that have been submitted and close the reports one by one as the bugs are fixed. General discussion is better suited for the forums. So that will be the place to ask for help with your formatting questions.
It was a reply to your Point 11 - an aside to you in the context of your earlier helpful remarks. I have followed your useful advice on bar spacing and have already had the reactions of another user. The reason we are in 'issue tracker' is that - as soon as I had finished the scoring itself - I thought you'd like to see the 'corrupt' places in the scores, so I clipped them and put them under the earlier thread about that. Again, many thanks for your detailed and informed input...!
The basic issue here of MuseScore occasionally corrupting a score, leading to situations with the wrong number of beats in a measure - while I am sure there are still cases of this, without an example file creating in a recent build or a way to reproduce the problem, I propose closing this report. New reports can always be opened (or this one reopened) if/when a reproducible cases is found using a recent build.
It's possible better to close.
Please post if you disagree.
Regarding wrong length of bar (or number of pre-prepared rests). Attached here is a file which if you try to load musescore will say it is corrupt. I didn't change the file outside musescore. I'm not very good with interface and might have pressed too many buttons but this what I got. I occasionally made the measure 2 of staff 2 have wrong length. I can't reproduce, I didn't record my input. I tried a lot of manipulations afterwards to fix the issue to no avail. Later I've managed to move the wrong length to measure six. And this is how the file was saved. If I delete this measure now the length will most likely restore. However I'm not sure how it could be that musescore allows the length of any bar be less than a measure. And I'm not sure how to get rid of this error while editing the part. Please advise.
Your score is corrupt, nothing MuseScore can do to fix it for you, you got to fix it yourself, see https://musescore.org/en/node/54721
Is it okay that musescore produces corrupt files?
Of course it is not, and if you provide exact steps how to get to that corrupt score in the latest version 2.0.2, or even better by using a nightly build from the master or 2.0.3 branch, we're likely to fix it.
And if you can, please do in a new issue rather than resurrectins one that got closed 3 years ago.
This score doesn't look like it had first been entered with 2.0.x (ist has last been saved with 2.0.2 though). It contains only one corruption, fixed easily, see attached.