Bad Splits -- A better way?
hi
tried load a midi file into muscore and the result is not what one would have expected.
the piece is very simple, in Bb minor, 4/4 at 100bpm - the first bar is -
a whole note triad (just the root and fifth) comprising of a A#3 and F4
also on the same stave there are passing tones, 1/2 rest and 1/8th notes C#5, C5, G#4, G#4.
What's surprising is that muscore splits the stave into two treble clefs, but puts one whole note on the primary clef and one whole note on the secondary treble clef, with passing tones in 3 voices, on the primary clef.
It does not seem to figure out that both whole notes would be better off on the secondary clef, and the passing notes on the primary, this way there is no need for multiple voices, and it would give a significantly cleaner representation.
One would think that the rules might need to be changed to always if possible move whole notes to the secondary clef, this way multiple voices may not be needed (as there is no intersection, and the whole note duration obviously is the length of the bar). Certainly a cleaner engraving would be produced, which would be definitely more understandable to musicians than as it stands.
Excuse that I just mention the note names, without attaching, but this is a real job and the work is copyrighted. I thought I'd send this in, in this form, so at least the developers can review and see if there is a better way of muscore handling these cases.
Comments
If you could make a sample MIDI file with only these notes. Feel free to change the pitches if you are concerned about copyright. That would be very helpful.
In reply to If you could make a sample by [DELETED] 5
The copyright is the whole item, so that's why I didn't send in the midi file.
Since it's only a few notes, my reasoning is that it should be very easy to manually enter.
I did though give you the first bar, which did badly split, and I think it may show if or where the algorithm of splitting may be improved.
I've given the original data, as I thought that a real example is better, for the reason below.
The pitches given define where it actually happened in a real world scenario, rather than pitches modified that may, or at least have the possibility of not showing the issue. As algorithmically, for all i know, muscore may approach it's splitting differently dependent on the pitches. Which is someways is similar to what i'm saying muscore actually should do, plus combined with the length of those notes. Thus the modified pitches would not really be testing muscore's algorithm and it's internal branches and decisions with known data that does cause the bad splits. Which is why I thought you'd prefer the real data.
Humor: I know 6 notes (especially in Bb minor ) can be hard to enter manually - but after doing it - remember you can take a long 'rest'.
Not Humor: Best of luck in making muscore better. Which personally was the reason I posted this, if someone wanted to use it for making professional scores that are handed to musicians, the splits would cause major headaches for all artists concerned. And if a new young composer were asked to re-work some 313 bar work like i've described, not only would take a very large amount of time, it would bring into question the effectiveness of the person as well as the product which not withstanding may severely and negatively impact on people's perception of muscore's role in the music world.
In general, there is no foolproof way of deciding which notes should go into which hand if your MIDI file oes not already separate this. So MuseScore uses a variety of heuristics, including taking into consideration things like how closely spaced the notes are (to see how viable it is to play them in one hand), etc. But it's seldom going to take the place of an intelligent human making these decisions. Every case is different.
In reply to In general, there is no by Marc Sabatella
Actually I disagree, because of the note length, and the chordal structure of them both.
it would be clear that in this case the algorithms need looking at, which is why i posted the case.
The way I see it, is i'm happy if the developers want to revisit it, not necessarily for me, but for a new composer who might not understand the constination that this may cause when handing it out.
If they want to take that route and look to see if it can be improved, then good for them, if they thing that it's okay as is, that's fine with me too.
As least now they have the information to make an better decision whatever decision they choose to make.
In reply to Actually I disagree, because by chris_I
Yes, this particular our algorithm might not produce the optimal results, but my point is, each case is different. The same algorithm produces very good results in other cases. But there is no single algorithm that procudes ideal results in all cases. Which is but one reason (among very many) why MIDI import should be thought of as a last resort, not as a generally good way to enter music into a notation program.