Key Signatures Exporting

• Mar 27, 2017 - 12:55

I exported a MIDI file from MuseScore and tried playing it in Synthesia. The original score had the key signature Bb Major,
Image1.png
but the key signature is changed to C Major (I assume is the default value) in Synthesia.
Image2.png
Even when I import the MIDI back in MuseScore, the original key signature I had is still missing.
Image3.png

Comments

• Mar 27, 2017 - 13:45

If Synthesia changed the key to C, then you would expect MuseScore to keep that key signature. You can insert the correct key signature at the beginning of the song by dragging the key signature to the first measure.

Reply

• Mar 27, 2017 - 15:13

Synthesia is a video game and piano keyboard trainer for Microsoft Windows and Mac OS X, which allows users to play a MIDI keyboard or use a computer keyboard in time to a MIDI file by following on-screen directions, much in the style of Keyboard Mania or Guitar Hero. Additionally, Synthesia can be paired with MIDI keyboards that have illuminated keys, or with virtual player piano on screen, which some people believe makes learning piano easier for beginners. -Synthesia - Wikipedia

How about you try exporting a MIDI from MuseScore and importing that same MIDI back into MuseScore?

Reply

• Mar 27, 2017 - 15:04

Does Synthesia support midi import of key signatures?

Can you attach the score and the musescore exported midi file and the syntehesia exported midi file? Just the first measure should be sufficient if you don't want to share the whole score?

Reply

• Mar 27, 2017 - 15:10

Synthesia doesn't export MIDIs, it reads it then plays back with on-screen directions

Synthesia is a video game and piano keyboard trainer for Microsoft Windows and Mac OS X, which allows users to play a MIDI keyboard or use a computer keyboard in time to a MIDI file by following on-screen directions, much in the style of Keyboard Mania or Guitar Hero. Additionally, Synthesia can be paired with MIDI keyboards that have illuminated keys, or with virtual player piano on screen, which some people believe makes learning piano easier for beginners. -Synthesia - Wikipedia

Here's the MuseScore file, and the exported MIDI.
Glassware.mscz
Glassware.mid

Reply

• Mar 27, 2017 - 17:44

I can verify in musescore's gui debugger that there is only one key sig in that initial pickup measure. From Ziya's png, it looks like there is bug with musescore midi export, if it is exporting unnecessary additional key sigs. So looks like a bug report should be filed. Have you tried exporting from 3.0-dev and/or 2.1-dev?

Does anyone know of a midi file viewer for linux that displays raw events

Reply

• Mar 27, 2017 - 19:24

So what is very stange and I can't figure out, is that if I delete all measures except the first and export to midi, then the midi correctly contains just the single 2-flat keysig. However, if I export the entire score as midi, then the file incorrectly contains the superflous midis.

Attachment Size
Glassware-2meas.mid 268 bytes
Glassware.mid 13.19 KB

Reply

• Mar 27, 2017 - 19:37

So I'm stepping through the exportmidi.cpp code writeHeader(), and I've discovered that it iterates over foreach RepeatSegment. In the first repeat segment it finds key sig and writes it. But then in the next repeat segment, it doesn't find keysig, but for some reason also writes it.

I'm wondering if there needs to be a break or some other way to get out of writing extra key sigs.

Reply

• Mar 27, 2017 - 19:58

In 2.0.3, if I have export-as-midi.mscx :

export-as-midi.png

and export as midi:

export-as-midi.mid

Then when import that exported midi, I get:

import-export-as-midi.png

I did this to see how the export midi key sig code works. I'm thinking it shouldn't export the key sig on repeat if was already same key sig.

Now I figured out how to create a similar score illustrated the problem, by simply having the first measure be a pickup measure and then having second measure repeat itself export-as-midi_pickup.mscz :

import-export-as-midi_pickup.png

Then when export get export-as-midi_pickup.mid which when imported again, I get:

import-export-as-midi_pickup_.png
and there is no key sig at beginning.

Now that I've figured out reproduction steps, I think we can call this a bug.

Reply

• Mar 27, 2017 - 20:07

Actually, it is not the fact that the first measure is a pickup measure that is a problem. I can reproduce with a full measure as initial measure export-as-midi_full-meas-intro.mscz :

import-export-as-midi_full-meas-intro.png

Which when export to midi is export-as-midi_full-meas-intro.mid and which when reimported looks like:

import-export-as-midi_full-meas-intro_.png

If I inspect that midi file in MidiYoda, I can see from the "Event Examiner" that there is a Bb key sig immediately followed by a C key sig.

Screenshot at 2017-03-27 15-04-35.png

So there is a problem in musescore midi export code.

Reply

• Mar 27, 2017 - 20:23

Exporting that in 2.1-dev to midi, I find in ExportMidi::writeHeader() that

KeyList* keys = staff->keyList();

returns just a single key sig of 2 flats at tick 0. Which is correct.

Now the RepeatSegment has two sections. However there is an error when iterating through them and writing key sig. For the first repeat segment, musescore correctly idenfities the Bb key sig and writes it at tick zero, and keysigFound gets set true. But then for the second repeat segment, keysigFound is initialized to false, but then since no key sig was found in that second repeat section, then if (!keysigFound) block is invoked (mistakenly), which mistakenly inserts a C keysig as fall back.

It seems to me that the correct way this code should behave is to break out of both loops (the iterating over KeyList keys and iterating over RepeatSegment when a keysig is found.

Reply

• Mar 27, 2017 - 20:40

Ok, well I'm doing something slightly different...will have a bool initialKeySigFound which is initialized to false when first iterate over each track. And then initialKeySigFound will be set true only if find key sig at tick 0.

Now there is something else I want to do, and that is to remove duplicate key sigs if same as previous key sig.

Reply

• Mar 27, 2017 - 20:49

Now I could remove duplicate key sigs with something like:

                        // only insert if key sig is different from previous key sig                        
                        if (ev != --track.events().end)
                              track.insert(tick, ev);

But now that I think about it maybe I should just leave it...it is not a problem to have duplicated key sigs for each time repeat...and maybe it is desired for some reason I don't know.

Reply

• Mar 27, 2017 - 21:48

But different staffs can have different key sigs. So the way musescore writes a key sigfor each track should be correct. Are you sure that the MIDI file spec says that only the master track can contain a keysig? It could be that the program you are using (what is it?) simply does't like having different key sigs on different tracks. I'm quickly skimming midi spec https://www.cs.cmu.edu/~music/cmsip/readings/Standard-MIDI-file-format-… and I don't see any thing requiring that key sigs or other meta events have to occur only on the master track.

Reply

• Mar 27, 2017 - 23:58

Ok, well sounds like you need to make a bug report. Because the current ExportMidi::writeHeader function will input key sig events on a per-track basis, as you can see here in the loop exporting key sigs "for (auto &track: mf.tracks())": https://github.com/musescore/MuseScore/blob/8ff4a8f95eb5df55fc68e0ae96e…

Let me know if when you write that bug report and I can amend my pull request https://github.com/musescore/MuseScore/pull/3109

But be aware MuseScore DOES support different key signatures on different staffs at the same tick. Just hold down Ctrl while dragging and dropping a key sig onto a particular track, and it will insert a staff-specific key signature. So I have a question for you: if there different key signatures for different instruments, then which key signature should be written to this master track? Maybe should it be the most common key signature?

Reply

• Mar 28, 2017 - 04:12

Keysig, Tempo, and Meter events in a MIDI file are not based on Channel or Track. These are META events and do not contain channel or track information. (This is the general behavior of the software on the market and it is accepted.)

Then; If there are many entries on the same tick (say 1: 1: 0).
Some software selects the first entry, some last, some ignore. We do not know which way it behaves.

If these inputs are not in the first track, they can be ignored. Or quietly moved to first track. Or a warning comes (very rarely).

MIDI is not a score interchange format. It only contains note information. Tempo and Keysig are a kind of notification that is usually applied to all tracks.

At the same time: ab4 and g#4 notes in a MIDI file are no different. If only KeySig is specified, they can be displayed correctly by the appropriate software. Or not.

See attachments:
Tested with: Sibelius, Cakewalk, Encore, Cubase, GP6, Sekaiju.
Also included: Original MuseScore file and exported MIDI file.

PS 1:And yes, I wish that each track could carry these information separately.
And I wish the software on the market would read it like this.
But this is not the real life behavior of other software we are talking about.

PS 2: I just joined the subject and made comments. I'm not the one who opened this topic.
You can do a bug report or if you want to fix something.

Attachment Size
keysigtest-original-MuseScore.png 68.99 KB
keysigtest-sibelius.png 61.18 KB
keysigtest-cakewalk.png 19.61 KB
keysigtest-encore.png 20.4 KB
keysigtest-cubase.png 5.96 KB
keysigtest-GP6.png 14.31 KB
keysigtest-Sekaiju.png 17.24 KB
KeysigTest.mscz 14.47 KB
KeysigTest.mid 522 bytes

Reply

• Mar 28, 2017 - 13:04

If there are different keysigs created in different staves in the same tick, then:
1) can all be ignored (Sigless).
2) Write the topmost data.
3) Data that comes first will be superior to others.
4) Write as it is (let others think).
5) They play Stone-Paper-Scissors. The winner takes all.
6) Ask the user. (Don't do this: D)

It is appropriate to add this option to the MIDI section in Preferenes.

Midi file does not support multiple key signatures in different staves.
Please select one of the following behaviors:

(A) Do not write Keysig.
(C) Using the Keysig in the top line. (Default)
(B) Writing as it is. // (Incompatible with other software)

Reply

• Mar 29, 2017 - 17:14

I disagree with what has been said here. There is nothing in the MIDI spec that prevent to use key signature events in tracks that are not the first one. It's a good way to hint any interested importer for the right keysig to use on a given "staff" and it is ok for the standard.
As far as I know, no a single software package will behave wrongly about having key sig event on different tracks. Sekaiju doesn't pop up an error but a warning.

I will cherry-pick the first commit but mark this issue as "By design" except if someone can demonstrate it's really an error.

Reply

• Mar 29, 2017 - 17:18

I'm fine that you rejected the commit fixing keysigs to 1st track. I had read the wrong specs that Ziya posted and some others. And it appears that those specs were not adhering to the original MIDI spec, which places no such restriction on keysig events. Thank you for pointing me to the orignal midi specs.

Reply

• Mar 29, 2017 - 18:51

@lasconic :
Can you see my tests ?
Almost above.

MS has MusicXML for this job.
No software in the market understands this; Why should Musescore export it like this? (For .mid)

Maybe it can act like that for now.
In future versions, is there an option in the preferences section?
(I wrote in the above messages)

Reply

• Mar 29, 2017 - 19:02

I can already tell you that lasonic doesn't like options in most cases, because they just bloat the code and make the preferences ui too cluttered (and because people don't use options). And for this situation of keysig export to midi, I would agree with that, especially considering it is such an obscure problem to make musescore midi export be compatible with programs that don't strictly adhere to the original midi spec.

I think there is plently of software out there that will allow people to filter out midi keysig events from all but the first track (google midi filter). So I would say to leave musescore exporting key sigs for each track, and let other software worry about making that midi file compatible with whatever software is not adhering to midi spec.

Reply

• Mar 29, 2017 - 19:20

You might want to rerun those tests with the lastest 2.1 nightly, because I had fixed the original bug of superfluous initial C maj keysigs. Nevermind...I see those tests don't have repeats.

But it should be noted that midi is not a score interchange format, and also that I believe any program might ignore keysig events if they want. It appears from looking at those pics:

- sibelius & Sejanku only uses the key sig from the last track it sees that has a key sig
- cakewalk is ignoring keysigs outside of track 1
- encore only seems to care about the first key sig
- cubase & GP6 only gets the first key sig on first track for entire score?

So it seems that is program is sortof doing what it wants to do, as they aren't following the same rules for import.

Reply

• Mar 29, 2017 - 20:29

Looking at other tracks while importing was causing problems.
If we think that importing midi's come from other software, we understand the cause of the problem: No keysig on other tracks!

Other software use a special place for this feature.
It is almost impossible to write keysig into Tracks. (Except Sysex)

In MIDI files exported from Cubase, Cakewalk, Powertracks and similar software, this information is only in the first track.

So when importing, if the other tracks do not contain keysig, it does not change the value it reads first.

For Export (since other software on the market is not important) let musescore behave differently.

Reply

• Sep 26, 2023 - 18:45

Experiencing the same issue. I'm running Version 21278 (1607).

Found a score for some piano exercises I'd like to practice in Synthesia in all keys. The original score is in C.

I export it as well as several of its transposed versions as MIDI. Each file has a different name identifying the key. Synthesia then only sees one of these several MIDI transpositions of the same score, even though they all have different names. When I open it, it plays in the key of C. Any suggestions? Thanks

Reply

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