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.
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.
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 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?
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.
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).