I'm not directly involved, but I don't see how MIDI 2.0 can't affect the file specification fairly significantly.

There was an early thread wher someone replied that the file specification was now being worked upon.
I shouldn't hold your breath though, by past experience it will take many, many monhs before it's ready to be published.

Perhaps the MMA will respond.

JohnG.

Further to John's comments, the following web site does shed some light on some (?) of the changes that may be required:

https://www.musicradar.com/news/what-is-midi-20-and-what-does-it-mean-for-musicians-and-producers

But note that an important plank of Midi 2 will be 'backward compatibility' so the current midi files should continue to work, also the many midi 1 devices should continue to work, even with midi 2 files (assuming such things ever appear).

Geoff

It'll certainly be interesting to see whether a MIDI 2 SMF will be read within a MIDI 1 sequencer or DAW.

Somehow "I hae me doots", but living in hope!

JohnG.

Hi,

Yes, there is a SMF2 working group that has been working on a new file format. It's a big project, but we are making good progress.

The original formats of Standard MIDI Files (there are 3 types) cannot contain MIDI 2.0 Protocol messages.
SMF version 2 will support both MIDI 1.0 and MIDI 2.0 messages.

But it is a new format and sequencers or DAWs will need to be updated to use the new format.

Have you considered putting the MIDI 2 data in a SMF as a huge meta event? This would allow a SMF to contain both MIDI 1 and MIDI 2 versions of the same content. New software can read the MIDI 2 version, while old software can still read the MIDI 1 version.

There may be drawbacks to this I haven't thought of 😉

The trouble is, Geir, that MIDI 1 messages are encapsulated within the MIDI 2 UMP.
This would make them potentially unreadable to a MIDI 1 sequencer/DAW.
See below from the MIDI 2 protocol specification.

That's not a problem.

It's possible to add any data to a SMF file, using sequencer specific meta events for example. So a SMF could contain UMP messages.

MIDI files could contain both an UMP version of the data, and a traditional (non-UMP) version. The latter would be a dumbed down version of the fancy MIDI 2 music. UMP aware software would read the UMP version, while old software will read the traditional version.

Again, I'm not saying introducing a new (incompatible) file type is a bad decision per se. But it has drawbacks: users might choose to stick to MIDI 1 because 'it just works everywhere', for example. I'm curious whether alternatives have been given serious consideration.

Putting MIDI 2.0 data into the existing SMF format as Meta Events doesn't deliver all the features we envision for SMF v2. Doing so would not really solve compatibility. MIDI 1.0 messages and MIDI 2.0 messages would be encoded in different formats. Sequencers would still require updates to support MIDI 2.0 messages. Then Sequencers would also need to be updated to find the Meta Events and convert them to MIDI events.

UMP is designed to be the standard data format for all future transports and file formats. SMF v2 will use the new Universal MIDI Packet (UMP) to encode any MIDI event, whether MIDI 1.0 or MIDI 2.0, as "first class" events, not meta data. The UMP format has lots of space for huge expansions in the future. We want a design that automatically supports any new messages that we design in the future.

SMF v2 will probably also support other data types including notation. It's not impossible that it could support the original SMF format as a data type or file inside. But older sequencers would still need an update to know how to find that inside the new format. Instead of that update, I think it would be better for the long term if sequencers update to find MIDI 1.0 data inside the UMP format packets.

If developers and manufacturers have opinions or requirements for the design of SMF v2, we really welcome all to join as corporate members of the MIDI Association. Your input to the design would be helpful.

Thanks for your comments. DAWs/sequencers are probably the first to update. But there's also hardware (keyboards), karaoke players, old computers with old media players etc. that read MIDI files. It could be a good idea to let new-style MIDI files work no matter what.

For the record, here's how this could be done:

- Define a new "UMP" manufacturer ID
- The UMP data is stored as a sequencer specific meta event in the first track (*). The event uses the new "UMD" manufacturer ID.
- The events that map to MIDI 1 also appear in the file the traditional way.
- UMP aware software reads the first track. It there's an "UMP" meta event it reads the UMP data and ignores the rest of the file. If not, it reads the file the old way.
- Old software will either ignore the "UMD" meta events altogether or store them in memory. The legacy data is read.

You could simply take your new file format and wrap it in a SMF this way.

(*) Perhaps the event size should be limited to say 256 bytes in order to not upset older software.

Thanks for replies! So I have another one question. Is it possible to "touch" new format before it's officially released? I'm developing a library to work with MIDI and I'd like to support new features as soon as possible. Maybe you have something like Insider Preview program of Microsoft for new Windows builds?

Unfortunately my latest question remained unanswered 🙁 I have also another one: is there any movement on the SMF2 format?

Max,

The last I heard was that there was a committee still setting the standards for MIDI 2 SMFs.

Mike, the forum administrator, works on this committee, I believe.
I suspect we'll hear something from him when there's something to be heard.

Having worked on international committees before (in the data and telecommunications arena, not MIDI), I'm aware that there can be a great deal to resolved before an agreement can be reached between the various interested parties.
The various proposals also have to undergo some testing before they can be released even as a draught specification.

I strongly suspect we'll see something before the end of 2021.

[sarcasm]
But now it's holiday season, so all the French delegates (at least) will have departed for the coast, going by past experience! 😉 😉 😉
(Did you see the pictures of vast queues of traffic on the French autoroutes?)
[/sarcasm]

JohnG.

Is there any update in regards of the SMF2 specs? It seems to be still quite a gap not having an SMF2 format specified. Looking beyond hardware manufactorers towards software synthesizers there is a strong need having a file format for holding newer events. I already have proprietary support for MIDI 2.0 Pitch Bend Messages in my music notation software containing a software synth, but not being able to export and exchange midi files outside my software is a pain.

Looking at synths like FluidSynth, Timidity and a wide range of Music Notation Software available on Android, iOS and many websites using web technologies, not having a SMF2 spec hurts not only software manufacturers but also avoids that MIDI 2.0 gets the market push it deserves.

Greetings
Daniel