Automatic Bar/Measure Correction when importing old files
Hi, Gang!!!
I wonder if the development team could add an automatic bar/measure correction, when we are importing files from MuseScore old versions and/or MIDI files.
Because some reasons... Sometimes we get the infamous message: "Corrupted file. Measure Nr. xxx is not into expected size".
Why not to fix it automatically, with the nearest value? ???
Just an idea!!!
Blessings and Greetings from Chile!!!
JUAN
Comments
@jotape1960 - nice idea!
I frequently use MusicXML import in order to get a score transferred from Sibelius to MuseScore, and corruption is a frequent problem. Fixing one corrupted measure in a single instrument in a large orchestral score is not easy, and sometimes I have to remove the entire measure for all instruments and then insert the missing measure. That involves a lot of data input in order to repair the gap.
It would certainly be useful if the MusicXML import dialogue had an extra option:
Delete content from all corrupted measures? Yes/No
And of course we should then be able to copy the confirmation message with all the measure numbers + stave numbers of the emptied measures. Re-inputting the notes into the empty measures is much easier than trying to repair corrupted measures.
In reply to I frequently use MusicXML… by DanielR
@DanielR,
When possible, I insert a measure, copy & paste all but the corrupt instrument, then reenter the notes to fix the corruption then delete the offending measure. This usually works and speeds up the fix a corruption problem. You don't have to fix slurs that start before and end after this measure, but you do have to fix the slurs and ties with an end point in the measure.
BTW, I like Juan's idea, you should submit a suggestion at https://musescore.org/en/node/add/project_issue?pid=1236
In reply to @DanielR, When possible, I… by mike320
Hi, Mike320!!!
I uploaded the suggestion. Thanks a lot for your thoughts!!!
In reply to Hi, Mike320!!! I uploaded… by jotape1960
See suggestion #284274: Automatic fixing of "corrupted" measures/bars when importing MIDI and/or old MuseScore version files
In reply to See suggestion #284274:… by DanielR
I wonder if you can add the automatic inspector to avoid any kind of corruption whatever the process is (create a new score, editing and/or saving an score).
I'm talking about an automatic testing of the measures/bars lenght (size), testing all voices (because this issue is always related with some voice with more or less times per bar).
In reply to I wonder if you can add the… by jotape1960
There is work being done under the hood to fix these issues. The problem is with rounding. They are changing calculations to fractions so there will no longer be rounding errors. Once this is done, most corruptions should be eliminated.
In reply to There is work being done… by mike320
I'm not a programmer. I wish to know about that!!!
But... Isn't a basic mathematical issue here???
I mean... Let's say we are working on a 4/4 score. Well, we know we only can have, per bar:
1 whole note
2 half notes
4 quarter notes
And so and on...
I think the program just have to add and compare with the possible maximum length of each bar!!! Simple (to say, hi hi hi).
if that future automatic inspector found some bar with an out-of-range rhythm figures... Very simple, folk!!!
The program could change the figures to "put" all of them "inside" the maximum possible value.
That's all!!!
Well, I know it is very easy to think and write. I repeat, I'm not a programmer, so I don't have any clue about the necessary algorithm to get this.
In reply to I'm not a programmer. I wish… by jotape1960
Problems mostly arise when you have tuplets like a 6th-let where each note is worth .1666666667 beats, 2 are worth .3333333333, 3 are worth .5 4 are worth .6666667, 5 are worth .83333333 as you can see there are different rounding errors introduced when you take them 1 at a time versus 3 or 6 at a time.
In reply to Problems mostly arise when… by mike320
I can figure that, mike320.
But, I guess there should be a way to "fool" the system when we have those tuplets issues.
When I was in college, I learned a 4/4 measure will be able to have just 128 "tics" (spanish word related with the clock ticking sound, I don't know which is the right English word to this).
So, the program has to know that value: 4/4 measure maximum length = 128 tics.
Any summary above or below that value will be... A corrupted bar!!!
If we use tuplets, each tuplets group full length is equal to some major "normal" value figure. And that final "normal" figure can be divided by 2 (avoiding the .3333333333333 values)!!!
So... I guess there should be a way.
You can do it!!! You always can do it, man!!!
In reply to I can figure that, mike320. … by jotape1960
Tic (tick) is the same word used in the program. A measure is divided into 480 ticks in MuseScore. As you say, there is always a way to work with the rounding issues. There are so many special cases to help with the corruptions issues that they start contradicting one another, so someone came up with the idea of using fractions since in my example, 2/6 is always = 1/3 and there are no issues with rounding. The hope is that this will fix a lot of problems.
In reply to Tic (tick) is the same word… by mike320
Interesting data!!!
Why MuseScore divides measures into 480 ticks??? Which is the "cryptic" math here???
In reply to Interesting data!!! Why… by jotape1960
120 ticks per beat. 120 = 234*5 for what it's worth.
In reply to 120 ticks per beat. 120 =… by mike320
mmm... I can not to follow that math...
Yes, 24 * 5 = 120, And 120 * 4 = 480.
But... Why to chose "24" as base number???
It seems "32" is a more "computing world" number, so...
32 * 4 = 128 ticks per beat, and 128 * 4 = 512 ticks per bar.
Whatever... The human limit is around 96 ticks per beat, at 120 quarter notes per minute. (as I read somewhere).
In reply to mmm... I can not to follow… by jotape1960
Also some auto formatting happened when I tried to type 2x3x4x5=120 rather than 24x5. Jojo can correct me if I'm wrong, but I think 480 ticks is what midi uses.
In reply to Interesting data!!! Why… by jotape1960
480 ticks per beat is nice because is allows a quarter beat to be divided into eighths, sixteenths, thiry-seconds, etc but also into triplets, quintuplets, and sextuplets. But we didn't invent this - it's very common in the MIDI world.
In reply to Tic (tick) is the same word… by mike320
Not quite, a quarter note/rest is divided into 480 ticks