Awkward pause
I'm writing something and I noticed an awkward pause where it should be a constant flow of sextuplets. The explanation I gave myself was the the beat in the measure:beat:tick is divided only in 1000 parts and somewhere the math doesn't add up, but it feels unlikely that that is the case. Example is included below. Any ideas on how to fix this? I though about doubling the tempo so the note values wouldn't be so small, but, again, that seems wrong in thinking on my part..
| Attachment | Size |
|---|---|
| test.mscz | 5.81 KB |
Comments
1. Opened your score and exchanged voice 1 & 2, then switched them back to show that there is a pause because there is a rest. (Score had stated corrupted measure when opening.)
2. Cut and pasted the final sextuplet onto that formerly hidden rest to eliminate the pause.
See attachment.
Regards.
In reply to 1. Opened your score and by Jm6stringer
What is this magic that you know of! It showed up when I did a double voice exchange. Thank you.
In reply to What is this magic that you by communistkiro
No magic, see step #5 here:
https://musescore.org/en/node/54721
Also, if you look at the Status bar (menu item: View / Status Bar) at the bottom of your score, it shows the note (following that invisible pause) playing at beat 2.825. This is later than it should play, thus indicating a hidden rest. Such hidden rest(s) are often revealed by swapping voices.
The fixed note plays at beat 2.75 - so there's no pause.
Regards.
The fact that MuseScore reports the score is corrupted when you load it is, I think, the real clue. Not sure how you created this, but somehow, a fraction of a beat got lost. Can you remember how you created this measure?
In reply to The fact that MuseScore by Marc Sabatella
MuseScore always yells 'corrupted' when there's an unfinished tuplet, I've noticed. How the beat gets lost I can't tell- I just picked a 8th rest and made a sextuplet via the shortcut, then a triplet, and then two more sextuplets.
In reply to MuseScore always yells by communistkiro
I don't understand what you mean by an unfinished tuplet. All of the tuplets in the corrupt measure are complete. What was weird was that the beaming
On another note, I've used all kinds of weird tuplets, including ones that prevent me from copying a measure, but I've never had a score reported as corrupt.
In reply to I don't understand what you by mike320
to get corruption:
1. Write a whole-note.
2. Create a triplet over this note.
3. Create a triplet again on the last note of the triplet.
4-7. Repeat the third step until when you reach to 64th triplet. (or until a total of 6 triplets)
8. Save it with some name..
9. Close the document.
10. Reopen it.
There is corruption!
Maybe it can be done more easily. But I couldn't find it right now.
EDIT: Note: I adjusted the brackets so that they look easier.
attachments:
3-5 no corruption
3-6 corrupted
In reply to to get corruption: 1. Write a by Ziya Mete Demircan
Ziya, your example is not the same as the seemingly normal note entry that OP used to make a corruption. There were no nested tuplets in the original test score posted here.
In reply to I don't understand what you by mike320
I've had corrupted files may be 4-5 times so far, always when working with tuplets. Only know did I notice a skipped beat, the other times- maybe through re-working- it'd gotten fixed in the end.
This same thing, a hidden 32nd rest, that sparked this thread happened again in the same bar yesterday, although I can't reproduce it at will.
I'm fairly inexperienced in notation, so my scores are illegible to the most of players, maybe I'm doing something the software doesn't expect? I don't know.
In reply to I've had corrupted files may by communistkiro
The most difficult of software bugs are the ones that result from someone using an unexpected key sequence. You obviously did an unexpected key sequence to discover the bug. Others have uploaded similar bugs before and the programmers have been trying for years to figure out what causes this bug. You said that it has happened to you several times, so perhaps one day you will be working with tuplets again and duplicate the bug and be able to explain how to reproduce it.
In reply to I've had corrupted files may by communistkiro
Well you are right that tuplets end up being at the root of a lot of the corruptions we see, and that is has to do with rounding. Although the magic number isn't 1000 - it is 480 (the number of ticks in a quarter note in our implementation). When it isn't possible to divide something up evenly we have a number of strategies for dealing with this, but every once in a while some case slips through the cracks and we don't handle well, leading to corruption. As people report steps to reproduce, we try to fix them for the next release, so hopefully each release had fewer such problems than the last.
In reply to MuseScore always yells by communistkiro
In general, MuseScore should always correctly fill in the rest of a tuplet and the remainder of the measure to avoid corruption. In theory, it should be *impossible* to create corruption. So any time you can find a precise sequence of steps that leads to corruption, we want to know about it.
So far I haven't been able to reproduce this.
Somehow when you made that measure, it became corrupt. If you didn't notice, it was reported as corrupt when it was opened. The 32nd rest there vanished and a tick count was entered into the XML at that point instead. Could you explain the steps you used to make that measure? Perhaps if you can explain step by step how to reproduce it a programmer will be able to fix it and prevent future versions from having this bug. Everyone who monitors this forum is aware this bug exists, but we have not been able to reproduce it to fix it.
I did some experimenting with the file and discovered that it can be copied, corruption and all. Some corrupt measures crash when selected.
In reply to Somehow when you made that by mike320
My guess it's related to this issue, about sextuplets (inter alia) : #202271: Copy-paste sextuplets/octuplets and their removal leads to corruption
Other example:
1) Create sextuplets 32th in a 4/4 measure: tuplets1.mscz
2) Remove the last one: tuplets2.mscz
After save-reload, the file complains as corrupted.
3) Ignore -> add a dot to the 32th rest.
After save-reload: tuplets3.mscz, the same corruption is displayed: expected 4/4 ; found 186/192, as the "original" attached file in first message, ie: test_107.mscz