MIDI export: the first track should not contain note events

Can you be more specific about which language in those sections you are referring to? Reading it I don't see anything quite so specific as what you are saying. I'm not saying it isn't so, just that it isn't *obviously* so to me, and presumably wouldn't be to others. The fact that I don't recall anyone pointing this out before, and the fact that the MIDI files created by MuseScore are readable by most MIDI software, is what makes me doubt.

I think best to keep seperate issues separate.

Regarding (1) having Track 0 be the "conductor" track with no note events, I have heard about this from other people too. I vaguely remember a discussion on the forums regarding a MuseScore midi export file that was having problems loading into Synthesia (I think) because MuseScore did not adhere to this "standard". I'm no midi expert...and to be honest I'm not sure that is exactly an official MIDI standard or if that has just been a defacto standard. I can't seem to find that issue. And nor have I been able to find definite midi file format standard, although I do find a lot of stuff online saying that Type 1 must have no note events in Track 0. But regardless, maybe it is a good idea to adhere to this "standard" regardless of whether it is official or not, so don't get complains from programs that adhere to it.

Regarding (2) to separate voices into separate channels per track, I'm not sure this is the most desirable, since voices are nothing more than separate voices. They aren't separate instruments, and they might not even be for separate musicians....for instance in the case of voices of a piano part, so I would lean to not putting voices on separate tracks. Having each voice on a separate channel might just complicate things, and make it harder for ordinary 99% use case where user wants all voices of same part to be synthesized the same. Again, I don't know of any definitive official standard...this is just my personal opinion.

Ok, if that link was official MIDI standard, then sounds like MuseScore needs to not have any notes in track 0.

There are only a few git operations you need to understand. See https://musescore.org/en/developers-handbook/git-workflow

Or #211351: short note cuts off long note in other voice on same staff, which is a duplicate of #12971: Same note in different voices and lengths plays only the length of the shortest note

Separate channels for staff voices would be incorrect for all keyboard instruments (not just piano), or instruments with one sounding-element per note (e.g., harp, and classical guitar, as noted in other threads). Separate channels for voices would be very useful when "flute 1 and flute 2 are on one staff". So that has to be an option. Even this, though, will not solve the extremely common case of short/long note coincidence on keyboard instruments, classical guitar, etc. It is not a matter of convenience or formal correctness, but sounding two channels at coincidence is simply incorrect; real pianos, harpsichords, and organs do not do that (although sometimes organ music intended to be rendered on two manuals (keyboards of the same instrument) is notated with independent voices on one staff, i.e., the "two flutes" case).

It is to be noted that mechanical-action (tracker) organs from hundreds of years before midi implement a policy on this -- when one manual is coupled to another, or the pedal coupled to a manual, the actual keys of the target depress when the source keys are depressed; that is, coincident shorter notes on the target are not re-sounded, but "silenced"/ignored.

Then real pianos, organs (voices on a single manual) and harpsichords "do not track polyphony properly". Real pianos do not sound twice as loud when one voice crosses another. Midi explicitly allows for more than one note to be sounding in a channel at the same time. This is precisely the way performance on keyboard instruments is represented, as well as what the result of transcripting a performance on a midi keyboard looks like, as can be verified with any midi-recording instrument or software. Midi keyboards create output for one channel, not one per note. MuseScore does not manage coincidence within channel properly; it is not about failure to use multiple channels.

There is a "keyboard model" and a "multiple instruments model" of what multiple voices on a staff mean, predating computation and midi, and MuseScore ought treat them differently. One midi channel is "one keyboard-model instrument". Right now MuseScore is "always keyboard model", but note coincidence within that model is not now handled properly.

I've been writing contrapuntal music for over 40 years (check out my profile). I work with midi keyboards (virtual pipe organ, and I write MIDI software for it) every day.

I agree completely that the ability to assign voices on a staff to separate channels is a fundamental one that MuseScore currently lacks, and one that would solve many problems and open many possibilities not now available. But it would not solve the single-instrument note coincidence problem. Please reread what I wrote about the two possible (and both necessary) models.

Were your Kunst der Fuge example to be rendered with separate "piano" channels for each voice on the grand staff, it would not play correctly, that is, note coincidences would sound like "two pianos". That is absolutely incorrect. The way the texture should sound on one piano is different than the way it would sound on four separate instruments, or four pianos each playing one voice. Single-keyboard reduction of polyphony involves notes occasionally disappearing, and this was true 300 years ago, 400, as well as now.

Midi is NOT a representation of a score, but a schedule for what notes are to be rendered upon the instrument(s). Channels represent instruments, not logical voices of polyphony, and in the case at hand, these two notions differ.

There is no reason why it should be possible to retrieve or reconstruct polyphony from a midi keyboard score. That is not its purpose. Its purpose is to produce the same sounds on a midi-controlled keyboard instrument as would a human performer.

Being "trackable" is not a goal of the "musical instrument digital interface". That is the purpose of Music xml, msc(z), and other score-representation formats. Nor is midi a reasonable technique for reducing a four-staff score to a single-instrument performance.

What do you think a midi-controllable pipe-organ (most new ones with electric action are) should do when confronted with your score in which voice-crossings on the same manual are given in two channels? Sprout new pipes in real time?

Polyphonic voices are "trackable" in MuseScore, and every other score editor, but not in keyboard midi files or midi recordings of keyboard performances. Saying "Bach Midi files" is deceptive: Staves don't exist in MIDI. Midi files in which polyphonic voices are separate channels, as in orchestral or choral score/performance, must exist as well as ones on which they are on one channel, as on a keyboard. There is no "correct" choice here for both cases -- one is for keyboards, and another for separate instruments.

"Mute doubled notes" is the whole deal. MuseScore ought have that as a per-staff checkbox, and that is all that is needed to solve the problem. The option of separate channels/instruments for each voice on a staff is also extremely desirable, but solves a different problem.

Thank you for your kind remarks on my recent composition (do check out older ones) -- you will note, as it were, that the last top-voice note is clobbered by a shorter note in the next voice as posted (and this is on Hauptwerk driven by (processed) MuseScore midi) (I haven't corrected it yet).

Yes, I've been programming computers for 50+ years (40+ professionally), details of my career not relevant here, but writing MIDI-processing software (for myself, in Python these days) is about all I do since I acquired Hauptwerk a year ago, so I, too, know what I'm talking about.

"Importing MIDI files" is a kludge for reconstructing scores (and believe me, I've done it enough times) when you don't want to type them in over again. It is no substitute for a score representation. As I just added to the previous letter, the note coincidence problem troubles not only the internal synth, but other midi instruments (e.g., Hauptwerk) driven by MS midi output.

I think the goal of using MIDI as an exchange format in this day and age is misguided, and there is no reason why the representation of a keyboard reduction of polyphonic music should be optimized for this. Midi keyboards (and divisions of virtual pipe organs) listen to ONE channel, like all other instruments, not many. A keyboard-reduced score cannot at once serve the two goals of driving one keyboard instrument and comprising a "trackable" source for reconstruction of polyphony.

(if you missed my update to my previous posting, thanks for your kind remarks about my work, and note that the very last note of that composition has been hit by this problem, rendering on Hauptwerk).

MIDI stands for "musical instrument digital interface": i.e., it is a "hardware model". "Representation of a score" to me means "exchange medium". MIDI files are designed to be performed, not imported. As a result, notes are shortened or otherwise articulated by their authors, enharmonic distinctions are completely discarded (as you have surely noticed), in all cases I know (despite the MIDI standard) lyrics and textual annotations and indications are lost, etc. It is a performance medium, not a score medium. The correct solution to the clipping problem is "mute duplications in same channel", as you yourself have implemented in your own software (and other systems I have heard of offer), not requiring authors of polyphonic keyboard music to direct their voices to distinct channels.

I urge you to look at the (wonderul) G# minor prelude of book II of the Well-Tempered Clavier, first few measures. Here is an indisputably polyphonic composition for keyboard (at least that's what the title of the collection alleges), which is not a fugue, and not a reduction from a multi-staff original. Can you tell me how many voices there are, which notes belong to which voice, and which channels they ought be assigned to, or why it is reasonable that someone ought be forced to make that determination in order to deal with this work in MuseScore? What do these chords and third/sixth doublings mean in your "one channel per note" model? Where lies the boundary between "polyphonic keyboard music" and "other keyboard music" in your model, and how can others discern it?

Feels like maybe this a discussion best suited for a new forum thread, to get other user input.

Staves routing to one channel and staves routing voices to separate channels (latter not currently available in MuseScore) are two different cases with different sets of use-cases and different problems. One is not the solution to the other.

Staves routing to one channel, as single instruments, including keyboards, are properly represented, demand special care on the part of score-editing programs which, without taking such care, will generate (on)(on)(off)(off) for the same note. This is not a problem in the definition of MIDI, or in instruments, or the use of one channel. It is a problem in score-editing programs not knowing how to play polyphonic music on a keyboard the way men and women have for five hundred years. The sequence of on's and off's sent to an instrument should represent when you want the notes turned on and off, not running adjustments to the their instantaneous "polyphonic depth".

Staves routing individual voices to different channels would be a very wonderful MuseScore feature, and you say that other apps have it. The "double sounding" of a coincidence is not an error, or a problem, but exactly what you want if you have Flute I and Flute II (orchestral instruments) on the same staff, or a hymn-book staff with two parts on a staff, or even multiple violin-strings. This is exactly the correct and desirable behavior. But if you attempt to use this to render keyboard music, you will indeed create problems. One instrument per channel is the midi standard, isn't it? Staves routing individual voices to different channels is a necessary facility to represent multiple instruments (including multiple orchestral "sections") on the same staff. It is not a substitute for a midi generator knowing how to play polyphonic music on a keyboard instrument.

Saying "MIDI files parse correctly" is not objective language; it means "I can more easily recover the score from the MIDI file."

I have encountered the overlapped on/off problem myself. See mm. 33-34 of https://musescore.com/user/1831606/scores/1608616 . The correct solution is MuseScore learning to play such passages on a keyboard the way humans do.

(And while we're here, one staff routing ALL its notes to many channels, i.e., colla parte, is something I have wanted for years).

I have listened to a bit of your music in SoundCloud, by the way, and it is quite wonderful.

I would like to hear, as it were, some other voices here ...

As I said above, this discussion is better suited to the forums. Far more people will see it there.

Yes, I agree with this; sorry if I misunderstood your intent. Again, the missing element in the current stack is "keyboard technique for playing polyphonic music", 500-year old info, absent because the (to-)midi renderer sadly does not realize when it puts two digital fingers, as it were, on the same key as people do; it is not implicit in the (correct) use of one channel per keyboard or keyboard instrument.

But if you do what I say, MIDI files will "parse correctly" in this respect, but still will not produce the original score easily, just as with careful recording of the keyboard actions of a human performer.

I change the title to reflect that 1) should be fixed to mark this issue as fixed. 2) is totally different and should be address in another issue. Please try to create issue with a single focus.

The way you worded the other issue, it*is* a duplicate. The issue is that short notes cut off long ones on the same channel. There are multiple possible solutions. The original report focused on a different solution than the one you favor. Feel free to respond there in that original issue. But as I keep saying, it really seems like this needs to be discussed with users on the forum first.

So, exactly as I said, there are multiple solutions. And some of the others *are* perfectly viable. And ideally, I think we should design a solution that both *allows* a user the *option* of having different channels for different voices if that suits his use case, but *also* givers the correct playback if he elects to use the same channel for different voices if that suits his use case better.

It is clear which use case you personally encounter, and thus which part of the solution you are focused on. No need to insult the people concerned with other aspects of this problem. I realize you are mostly accustomed to working solo on small projects where you get to determine the use cases you want to support as well as implement the solutions. But in a larger open source project like this - one with dozens of developers and a user base in the *millions*, we need to seek user input to understand the different use cases that we may need to support - often these are very different from our own - and to respect the opinions of our fellow developers and engage in meaningful dialog with them.

*As for "rookie MIDI software problem", let us know if you really want to compare our collective resumes to see which solution should "win". Personally, though, I'd rather actually discuss the technical issues objectively.

Exactly. FWIW, I concur 100%.

Asking questions for clarification is not being "oppositional". I am sorry that it seemed to upset you so much though. If you would like to objectively discuss the actual technical issues, please do so, but I ask you leave out the personal insults.

@.function_ as someone not involved with any of discussions you have been involved in, I've got to say the rudeness you have introduced yourself with in the MuseScore community has been painful to watch ever since you reported your problems with building the programme.

The use of the passive voice ("the problems were stated with solutions") is irresponsible here. You stated the problems, and you proposed possible solutions. There is no agreement that your solutions solve the problems at hand, or are reasonable solutions. Disagreement, dispute and critique is not "pointless blathering". In fields other than mathematical proof (in particular, engineering) unilateral assertion of correctness comprises neither correctness nor consensus. There are plenty of people here who have done midi programming. You also say you are new to MuseScore ....

My questions asking for clarification in my first response were equally to the point. But I agree things went downhill quickly from there.

Which part of the instructions are out of date? There might be some old instructions still accessible, however, if you find the latest compile instructions and follow them to the letter, then it should work. If not, then maybe let us know exactly what is wrong with the instructions so they can be fixed. (it is very easy to make a slight mistake that will cause compile to fail)

See https://musescore.org/en/node/208621. As far as I can tell the issue has to do with attempting to build 2.x branch on older / unsupported versions of macOS. Not really relevant here of course since all new development should be on 3.0, but probably trying to build *any* version of MuseScore on unsupported version of macOS will be problematic.

You need to implement refcounting (and then emitting only the very first start and the very last stop event for multiple notes) to fix the playback problem in the simple keyboard model.

This should be not too hard to do, perhaps even performantly.

Independently from that, the second change necessitated is the option (per staff) to split the voices into separate MIDI channels (or even an option to leave the complete assignment to channels up to the user), to allow for the multi-instrument model.

I don’t think restriking is feasible with MIDI and oooo00000OOOOh sounds, so people wishing restriking will probably want the multi-instrument model instead.

Thirdly, channel 0 apparently needs to be not assigned an instrument.

These are three unrelated changes which, combined, fix most of the problem, and which individually fix problems for a subset of users (the first for keyboard model users, the second for multi-instrument model users, the third (and the first, to a lesser amount) for stricter MIDI file parsing.

Couldn't agree more. I wish this problem had the priority to see itself fixed.

Ok, if that link was official MIDI standard ...

The Problem with that link is that it's not the official MIDI standard proper.
Form the pdf:
This document was originally distributed in text format by The International MIDI Association. I have updated it and added new Appendices.
© Copyright 1999 David Back.

You wrote:
Musescore assigns note events of the first Instrument (staff) to Track 0. This is wrong.

Track 0 is supposed to be a "conductor" track, which only includes the meta events: all meter and tempo changes. It is not supposed to include notes or other data. Instruments (staves) are supposed to be separated into tracks, starting with Track 1 (not Track 0).
....
The points above can be verified in the MIDI File specification, sections 2.2 and Appendix 2

as well as:
Track 0 is supposed to be a "conductor" track (also called a "tempo map"), with no note events.

I just double-checked with the original MIDI Specs (btw. the official standard is available at midi.org) and reassured that your reading is simply wrong: the standard mandates that all
timing related "meta" events shall be in the first track (this is a clever requirement since it
enables grouping notes into bars during the file parsing phase). Nowhere does it require
that the first track only contains meta events.

Still the wrong-ish post, but the one with the most information on the topic asides from the https://musescore.com/groups/3642106/discuss/3663846 group posting, so I’m presenting it here after realising BSG is right (thanks man!):

I just wrote a shell script that checks a score for note collisions. This is Unix(Linux)/OSX only, sorry Windows® users (well you might be lucky with Cygwin, but that counts as Unix in my book).

http://mirsolutions.de/music/resources/chkcoll.sh has the script, it’s published under the Ⓕ Copyfree MirOS Licence so everyone can benefit from it.

On Debian, you need the packages musescore (of course), perl (perl-base is probably enough), mksh, midicsv installed to be able to run it.

Other people will have to retrieve the appropriate packages themselves:
- perl is https://www.perl.org/
- mksh is http://www.mirbsd.org/mksh.htm by yours truly
- midicsv is http://www.fourmilab.ch/webtools/midicsv/
- I assume stuff like grep, sed, tr, … is available

The scipt will, unfortunately, not run headless because MuseScore is written in Qt5 and so, by Qt’s design limitation, requires a connection to an X11 display even when running in nographics mode (although xvfb probably suffices).

To use the script, run it like this:

$ mksh /path/to/chkcoll.sh path/to/file.mscx # or file.mscz or file.mid

To clean up afterwards:

$ mksh -c /path/to/chkcoll.sh path/to/file.mscx # or file.mscz or file.mid

complete_midi_96-1-3.pdf
page: 142 / 334


...
A format 1 representation of the file is slightly different.
First, its header chunk:
4D 54 68 64 MThd
00 00 00 06 chunk length
00 01 format 1
00 04 four tracks
00 60 96 per quarter-note
Then the track chunk for the time signature/tempo track. Its header, followed by the events:
4D 54 72 6B MTrk
00 00 00 14 chunk length (20)
Delta-time Event Comments
00 FF 58 04 04 02 18 08 time signature
00 FF 51 03 07 A1 20 tempo
83 00 FF 2F 00 end of track
Then, the track chunk for the first music track. The MIDI convention for note on/off running status is used in this example:
4D 54 72 6B MTrk
00 00 00 10 chunk length (16)
Delta-time Event Comments
00 C0 05
81 40 90 4C 20
81 40 4C 00 Running status: note on, vel = 0
00 FF 2F 00 end of track
---page---
Then, the track chunk for the second music track.
....
Then, the track chunk for the third music track.
....


The quote you give is from the programming examples section and describes how the music fragment given one page before can be encoded. As the text preceeding the score fragments says "... then, a format 1 file is shown with all data separated into four tracks: one for tempo and time signature, and three for the notes.".
But nowhere does it say that the first track has to be an exclusive meta event track.
The lack of clear terminology (OP calls the first track "conductor", the example section calls it
"time signature/tempo track") indicates that the standard doesn't limit that first track.
I'm not saying that it doesn't make sense to have such a special track, just that the wording of the standard doesn't doesn't mandate a meta-data exclusive first track.

I still have doubts that many of these documents that people are emphatically claiming are *the* midi standard are indeed part of the original midi standard. From Wikipedia article on midi:

MIDI technology was standardized in 1983 by a panel of music industry representatives, and is maintained by the MIDI Manufacturers Association (MMA). All official MIDI standards are jointly developed and published by the MMA in Los Angeles, California, US, and for Japan, the MIDI Committee of the Association of Musical Electronics Industry (AMEI) in Tokyo. In 2016, the MMA established The MIDI Association (TMA) to support a global community of people who work, play, or create with MIDI, establishing the www.MIDI.org website as the central repository of information about anything related to MIDI technology, from early MIDI technology to future developments.

So maybe someone needs to dig up the original 1983 standard. Maybe midi.org has it. I have a strong suspicion that the industry has made up their own defacto standard about file format which isn't necessary.

I'm still not convinced that the first track is prohibited from containing note events.

This is still minor considering that major is reserved for crashes or dataloss in musescore.

I vaguely recall reading that either only track 0 is used or that tracks 1–n are used while track 0 is used as a conductor track (newer, recommended). I don’t have a reference for this, though. Might be better to be conservative about what we send… so perhaps a change might be in order, even if minor.

Good news, I’m able to build MuseScore (2.1, but I can prepare a fix for the 2.x branch which someone can then forward-port to 3.x) and thus likely able to take care of the refcounting bug soonish.

page 134: (The original is a single paragraph, I put line-breaks for easy reading.)

...
In a MIDI system with a computer and a SMPTE synchronizer which uses Song Pointer and Timing Clock, tempo maps (which describe the tempo throughout the track, and may also include time signature information, so that the bar number may be derived) are generally created on the computer.

To use them with the synchronizer, it is necessary to transfer them from the computer.

To make it easy for the synchronizer to extract this data from a MIDI File, tempo information should always be stored in the first MTrk chunk.

For a format 0 file, the tempo will be scattered through the track, and the tempo map reader should ignore the intervening events; for a format 1 file, the tempo map must be stored as the first track.

It is polite to a tempo map reader to offer your user the ability to make a format 0 file with just the tempo, unless you can use format 1.
...

Again, we have agreed that yes, it would be wise to make track 0 contain no note events; but it is not a strict violation of the standard.
Resetting the priority to normal, as compared and balanced against other issues and MuseScore's core functionality (being a score engraver, not a sequencer).

Part of the "Not being a sequencer" responsibility is being able to transmit scores to "yes, I'm a sequencer indeed" tools.
On a very related subject, my own tools have noted that if the "real stuff", i.e., notes (which don't belong there) and time signatures in whatever-happens-to-be track 0 end sooner than the tick-end of the whole piece, the end-of-track element is time-tagged for the former, not the latter, requiring me to scan all tracks to determine how long the piece really is. This is surely wrong.

@.function_: Instead of argueing, how about you take a deep dive into the code and fix it? You were talking about this back in May, seems enough time has passed to familiarize yourself with the code meanwhile? Scratch you own itch, that's the Open Source nature of things.

Geeting MuseScore to build shouldn't be the big problem, if you get stuck search for help in IRC.

@BSG would you mind creating an issue for the end-of-track timing being wrong?

@.function_ Stating a fact is not misleading, especially not when agreeing with you on the desired behavior in the same paragraph.
As for the priority setting, I'll leave it as it is now, because far too much time has been spent on discussing this; Just note that I did not change the setting without consideration. Indeed read back into the instructions you've linked to; it is not because an issue is of major importance to a few, that is so balanced out against the full project. Exporting MIDI is far less common than entering notes for example...

I believe we've had a conversation about compile instructions a couple of months back already; Are you still attempting to build on a non-supported OS and is that the reason you think the instructions are an out-of-date mess? Or are they an out-of-date mess because you and your friend haven't been able to figure things out and as a consequence have not updated the instructions yet?
Once again you are invited to join the developers chat on IRC concerning compile issues.

Last time you were developing on macOs 10.9, for which Apple stopped support. So you probably won't get the 'latest XCode' for it, as the developers' handbook asks for. Following the discussion of your build problems that page had been updated. It still is a moving target though, meanwhile Qt 5.9.1 is the latest (but using 5.8 still is OK for master and 2.x branches still ned 5.4).
You consider MIDI file I/O a basic feature, I personally don't. Much more important is PDF / print, i.e. sheet music, and, for exchange with other score writers, MusicXML.
Please stop complaining and agruing, instead dive into the code and fix it, I'm sure you can do it. At one time you even claimed it to be a 5 minute fix.

I think we are all wasting way to much time on this non-topic. It seems like the OP wrote some software that violates one of the most basic rules of data handling: "be strict in what you create but be lenient in what you accept". That's unfortunate but definitly not a major bug of MuseScore (probably more so one in miditapper). As for Industry Best Paractices: I just did a small test with some mainstream software on Mac and Linux. DAW: Garage Band, Logic X, Ardour, Reaper and QBase import a MuseScore-generated Type-1 midifile without any problems (notes from all three tracks get loaded, tempo changes are honored (except in Ardour which seems to ignore tempo changes)).
Notation software: both Finale and Sibelius import without any problems.
Algorythmic composition, MIR software: both music21 and CommonMusic import without any problems.
All tracks get imported.
N.B.: none of the software showed even a warning during import ....

XCode would be the least problem - Qt5 support for OSX (http://doc.qt.io/qt-5/supported-platforms.html):

macOS
macOS 10.10, 10.11, 10.12   Clang as provided by Apple  

https://musescore.org/en/node/249736#comment-778501

Hate to argue against myself, but, in fact, the software that had trouble was my own software, so I can and did recode it (and it will forever have to do that to handle unfixed files already written), but MS should clearly be fixed in this regard, as well as keeping notes out of track 0 for what my opinion is worth.

How are we supposed to handle local time (or even key) signatures, if they all “have to” be moved into the first track? (Caveat: midi2csv labels the first track as 1, not 0; mind that to avoid confusion.)

I decided to not work on this and focus on the collision problems for now. Both the code and the MIDI format are hard, and MuseScore is, first and foremost, about notation, according to lasconic. Then, playback, and finally MIDI export.

The decision not to move to the first track right now is fine with me. I don't understand what issues of local time (!?) and key signature you are talking about. AFAIK everything but notes gets moved, time signatures, key signatures, and all. The file cannot be understood without interpreting the first track. You can prove it by doing it (in secret) and re-importing the result and prove that it's fine. I have done this with external code, and everything works well (with MS and Hauptwerk as interpreters).

Mh, I just said I personally wasn’t working on it. Perhaps someone else will, but probably not in time for 2.2; I am currently trying very hard to get the collision problem at least fixed for 2.2.

You can have different time signatures in different staves, and one stave is exported as one MIDI track, so time signatures can NOT generally be moved to the first track (from a MuseScore PoV; I do not know enough about MIDI to comment from its PoV).

Eeek. There certainly can be different time signatures on different staves (easy case 9/8 against 3/4 etc.) and I don't know what the MIDI standard expects there. That is a serious issue. On the flip side, perhaps the reason I forgot about that is that MuseScore, as far as I know, is incapable of expressing that. You can change the way a time signature appears on a staff, but not its real content (am I wrong?). But, clearly, there is an issue of what should be moved, and leaving it as is seems sane for now. (I misparsed "local time .... and key signatures", sorry!) OTOOH, @Demircan above shows us a message box from Sekaiju COMPLAINING about time and key signatures not in track 0!

MuseScore does support local time signatures (eg 3/4 and 9/8 simultaneously). See the Handbook under Time signatures for more. There are lots of limitations with this, so.I wouldn't be overly concerned about the MIDI aspect In particular.

Local time signatures are midi-illusory. I did a little experiment (attached file), and local time signatures entered with control-drag do not go into the midi file; the meaning of ticks in every track is identical, and determined by time-signatures entered in the conventional way. Even dropping a local time-signature onto the first track (which seems to expose a bug, i.e., I can't enter the last eighth) does not change the meaning of ticks in that or any track.

It's easy to imagine that chaos would result if a midi-player required potential different click-clocks, as it were, for different tracks. Ergo, time signatures appearing in multiple tracks can be ignored, if gathered from the first/control track.

Local time signatures are an amazing feature, but (thank goodness) seem not a MIDI one.

OK, good to know, thanks for your experiments. So I^Wthe person who’d implement it would just discard any time signature information from all tracks but the first?

Ja. Fröhlichen Bachs-Geburtstag!

Like accurate enharmonic notation, MIDI cannot represent "enrhythmic" exchange; both (on an equal-tempered instrument) are about how the music looks, not how it sounds.

Came up again in https://musescore.org/en/node/273557

So is everyone now agreed that, from a pragmatic perspective, MuseScore should not include notes in track 0 of its MIDI exports?

IMHO it's not important whether including notes in track 0 is or isn't technically a violation of the MIDI standard. The practical advantages of adhering to a long-established and generally accepted best practice (i.e. compatibility with other software) seem clear and of far more relevance to users than what may or may not be written in, or intended by, a document from the last millenium.

In the duplicate issue linked by @Jojo-Schmitz immediately above, I think @joeshirley summed it up best (https://musescore.org/en/node/273557#comment-840828):

"The question I cannot find an answer to is, what advantage does MuseScore gain by putting note information into Track 0. If there is no compelling advantage, it would seem best for the greatest number of users to consider this a bug to be fixed in a future update. Perhaps the resistance to updating the practice has at least partly to do with the fact that MuseScore's implementation of midi import/export is convoluted enough that this is not a simple fix?"

So I'm hoping that the only thing blocking resolution of this now is finding someone sufficient motivation and patience to actually change the code?

You’re kinda late to the party, this was already resolved into that direction some time ago.

Understanding is also needed. I tried to look into this some time ago but couldn’t even figure out how to disentangle things that should and shouldn’t be in track 0. MuseScore internally is not exactly built as MIDI software; rather, it’s got a sound renderer whose byproduct happens to be standard MIDI files.

"You’re kinda late to the party"

Yes, this is inevitable in FOSS projects where anyone is free to join at any time ;-)

"This was already resolved into that direction some time ago."

I thought there was probably consensus, but it's not really clear from reading this issue, which is why I asked for clarification. Thanks for helping provide that!

Meaning case closed.

If I understand right, it is not fixed so the case is not closed. We are agreed on the right way forward, but code needs to be changed and merged before the issue is actually resolved.

See https://github.com/musescore/MuseScore/pull/7523

Came up again in https://musescore.org/en/node/320291

Came up again in https://musescore.org/en/node/322145

According to Sekaiju, though, some other events like KeySignature and so should also be in the first track, not just timing.

For clarification sake, does Musescore export MIDI files in SMF format?
If not, this could explain issues I am having playing MIDI files exported from Musescore on my digital piano.

https://musescore.org/en/node/322950#comment-1087911

Yes, the files are Standard MIDI, they just don’t conform to some additional “commonly agreed-upon conventions” that aren’t mandatory (even if they mostly make sense).

No more fixes for 3.x

It is part of https://github.com/musescore/MuseScore/pull/9000 though, so you could use the artifacts of that