Just trying to render a MIDI file as sheet music. Yeesh.

• Feb 3, 2015 - 17:49

I have music that was composed in a MIDI software environment to begin with (as opposed to being played live on a keyboard, for example). Hence, note durations and so forth are already the way I want them. I'm interested in displaying it and printing it as sheet music. (The original composition software has a piano-roll interface instead).

Downloaded a demo of a product called Finale 2014. Installed. Went to open file. Crashed. Restarted. Went to open file. Crashed. Repeated enough times to convince me next time wasn't gonna be the charm. Found an old downloadable copy of Finale 2007 demo. Opened file. It changed my tempos all round — "quantizing" them. Poked around, found a setting for "minimum note duration", another batch os settings for whether or not to reduce rhymical complexity, eliminate grace notes, etc. Adjusted them. Set minimum duration to 4 (four somethings... some three letter acronym starting with E)... started to open file, didn't crash but hadn't opened it as of 2 hours later, killed it, retried with that setting set to 32 (the default is 256). Better than original time that it opened, but it's still mucking around with my timing, and it now comes to an abrupt halt long before the end of the piece. (That may be a limitation of demo mode, somehow affected by the low setting for minimum note duration, don't know for sure).

Asked around, was pointed towards Muse. (Hi, Muse folks!)

Musescore can open the MIDI file. It wants to know a minimum duration, defaulting to 1/64; there's only one finer option, 1/128, I choose that, only to find that it is rendering each individual note as if there were three of it (2 32nd notes followed by a 64th). Close file, import at default setting of minimum dur = 1/64. Now I am seeing it correctly as indiv notes, 16th notes, interrupted by an unfortunate barrage of 32nd and 64th rests (I'd prefer it to think of the notes as staccato eighth notes). It has the weirdest damn array of key sigs imaginable for a D# minor piece. Change that...hmmph, it's still expressing that note as an E flat Default time sig is 4/4, I want 6/8 (or 18/8 but let's go with 6/8 for now). That changes easily enough. The measure is cut after 7 notes play; I want it to change it's sense of how long a measure lasts (I want 6 of these notes to constitute a measure, not 7). Can't figure out how to instruct it to do that. Leaving that for now.

Play the piece... it's made a complete hash of what's in the original MIDI file, changing it, it does not sound at all the same. It's no longer my piece. Reimport at the higher setting 1/128. Play. Ok now it sounds as it's supposed to. But the nomenclature...yeesh... If I change the time sig it changes the actual notes (not merely the way it represents them onscreen). So I have to leave it in 4/4 with approx 7 notes per measure, with one part (staff #1) in g flat minor, one correctly in D sharp minor, one in B flat minor, one in E minor, and one in C# minor.

What I expected first measure to look like.

What I got, first measure.

and...

it ends up looking like this...

Comments

• Feb 3, 2015 - 19:49

Indeed, you can expect night and day improvement from 1.3 to 2.0. Well, night and dusk, anyhow. But that MIDI is *very* limited in the amount of information it retains - it can't even tell the difference between C# and Db, for instance. Nor does it have information about multiple voices, so it's pure guesswork if you have overlapping note durations in a single track. And so on and so on and so on. So expecting to get a perfectly notated rendition of a complex piece imported via MIDI is simply not realistic, even if the durations themselves are quantized. MusicXML is much superior as an interchange format, so if your composition software can export that (and provide you with the means to distinguish between C# & Db, or staccato 8ths versus 64ths, etc) in the first place, you'll get much better results.

But even with 1.3, yu can improve the results simply by choosing a more appropriate duration. What you call a "staccato eighth note" is going to be indistinguishable from a shorter note value, so how is MuseScore supposed to *know* you wanted eighth notes rather than what you actually created, which was shorter? Answer - 2.0 tries to guess, but provide an option to turn this off. But in 1.3, you could simply tell it to use 1/8 notes as the shortest duration. Or maybe 1/16 if you use them elsewhere. But you *asked* it to give you 1/64 notes on import, and apparently you created them in your originakl MIDI file; you shouldn't be so surprised *you* got them in MuseScore :-)

Reply

• Feb 4, 2015 - 04:44

Getting short notes with rests instead of staccato 8th notes isn't much of an issue for me. Minor preference for the former over the latter.

Getting notes other than where I put them to begin with is a problem.

And while I don't expect it to know the difference between D flat and C charp, I expect it to render that note as C# if I assign the key sig to a sharps key especially if it specifically contains C#.

And I do expect to be able to tell the system "this is where the first measure ends" and have it assume an identical duration for subsequent measures up until I change the time sig or something. The piece was composed in MIDIgraphy, a piano-roll interface. The durations were lined up with the vertical piano-roll divisions, and hence splitting it into measures should be a lot less messy than if I'd hooked a MIDI keyboard to a computer and just played something, yes?

Look, if I can open the MIDI file in a half dozen pieces of software that each read MIDI files and have it sound the same, seems like the MIDI file has enough info to denote that sound. I should be able to import that and tell the notation software DO NOT CHANGE MY SOUNDS and have it restrict itself to how to display it in conventional musical notation.

Sorry, you can no doubt tell that I'm cranky about it at this point.

I'll look for MuseScore 2.0

Reply

• Feb 4, 2015 - 05:02

Yes, do try it. As we said, it's greatly improved. Including automatic reflowing of notes across barlines if you change the time signature.

Still, even in 1.3, you *should* be able to get better results than what you describe. Posting the actual MIDI file would enable us to help you more. I already pointed out that choosing a better vaue than 1/64 would help. If we saw the actual file, wer might be able to suggest other things that could help. In particular, it shoudln't have changed your sounds; not sure what you mean by that. Unless you mean that changing time signature did - that's true in 1.3. If you want the music to reflow itself, you can use cut & paste. But if the MIDI file already contains the proper time signature info, then 1.3 shoudl read it correctly. So you might want to check the documentation for your composition software to see if there is some way to get it to incldue that information. I'm not an expert on how this works, but I did verify that if I exprt a MIDI file from a MuseScore 2.0 score in 3.4, it does import into 1.3 in 3/4 as well.

Reply

• Feb 12, 2015 - 20:31

Been away on vacation and hence from computer etc...

I downloaded MuseScore beta of ver 2.0 and yes, it does import MUCH more nicely.

Screenshot 1st measure: http://home.earthlink.net/~ah3files2/much%20nicer.jpg

compare to what I expected: http://home.earthlink.net/~ah3files2/expected.jpg

The original MIDI file itself is here: http://home.earthlink.net/~ah3files/Stuff/The%20Runner%20Movie.mid

The Muse 2.0 "mscz" score file generated from it is here: http://home.earthlink.net/~ah3files2/The%20Runner%20Movie.mscz

I had Muse 2.0 export the scorefile BACK out as a new midi file which is here: http://home.earthlink.net/~ah3files2/The%20Runner%20Modified.mid

---

Issues at this point:

a) I can't figure out how to change the nomenclature of the key signature from E flat minor (6 flats) to D sharp minor (6 sharps)— it's the same actual notes just expressed differently, but not obvious how to inform Muse that I prefer it to render them in 6 sharps

b) Muse thinks that the second "voice" is a percussion part:

http://home.earthlink.net/~ah3files2/Thinks%20voice%202%20is%20percussi…

The MIDI was composed in MIDIgraphy (long enough ago for me to have been using MacOS 8). In MIDIgraphy, using built-in OS-level QuickTime Musical Instruments as the playback MIDI device, voice 2 is a second piano part. It also plays back sounding identical to that in (semi-modern MacOS 10.6.8 version of) QuickTime Player, clearly treating it as a piano part; likewise in RealPlayer; to get a crossplat perspective and get away from the world of Apple's QuickTime, opened it in Windows 7 Windows Media Player: same result, it plays those notes using a piano sound. Anyway, I don't see how to tell Muse that this track is piano, not percussion.

Similarly, voice 6 was some type of electronic synth keyboard in the original but has been reassigned to a grand piano in Muse.

Aside from the Voice 2 and 6 assignment problems, it's mostly treating my file nicely. A few discontinuities:

• at approx 3:30 it is doing something different with the tempo than what the original file has; listen between 3:27 and 3:34, it's as if Muse has shoehorned an extra beat in there that wasn't in the original; same section in the original occurs between 3:40 and 3:46 for comparison.

• it has made a complete hash of subsequent short section 3:36 thru 3:48 (Muse-modified ver) compare to 3:49 thru 4:00 (original). (This is where Voice 6 comes in, but the issue I refer to as "complete hash" isn't the misassignment of instrument but what it's done to the timing). This is at measure 96 in the score.

• Muse has done a very good job of handling the syncopation that begins at 3:49 (Muse modified version) / measure 101+ in the score / 4:00 in the original MIDI. This is usually where things fall apart really badly in other software products, they try to remap the notes to much blockier occurrences and destroy the syncopation. (The rhythm is an 18/16 mapped to the same velocity as the previous 6/8 or 6/4: four sequences of "ONE two three" followed by three sequences of "ONE two", yielding "ONE two three FOUR five six SEVEN eight nine TEN eleven twelve THIRTEEN fourteen FIFTEEN sixteen SEVENTEEN eighteen"). Muse has it, spot-on!

• But as I add back in other instruments on top of that beat, things still unravel: some discrepancies around 4:04 (Muse modified MIDI); the grand piano reenters several halfbeats early at 4:24 (measure 117 in the score) and chaos ensues from there. Comparison point in the original: 4:10= 4:04, 4:37 = 4:24

Reply

• Feb 12, 2015 - 20:52

You can change key signatures by dragging a new signature in. The spelling of pitches will probably disappointing at that pioint, but is you select all then hit "Down" followed by "Up", that should respell things favorinng sharps. Or, if the spelling of notes was especially good in Eb minor key, you might be better of using Notes / Transpose to transpose from Eb minor to D# minor, that way it should make the appropriate adjustments and keep the good thigns about the origina spelling.

There was a bug involving treating some staves as percussion inappropriately that I think was fixed recently, so try a current nightly build instead of the beta and see if it goes away. If not, then you should file a bug report and attach a copy of the MIDI file (feel free to cut it down to just a few measures).

Reply

Do you still have an unanswered question? Please log in first to post your question.