Does MIDI 2.0 affect MIDI file specification? How MIDi 2.0 data can be stored to a MIDI file? Is there any spec about MIDI 2.0 files?
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.
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.
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.
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.
0
Undo
Votes
Unfortunately my latest question remained unanswered 
I have also another one: is there any movement on the SMF2 format?
I have also another one: is there any movement on the SMF2 format?
0
Undo
Votes
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?
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.
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.
0
Undo
Votes
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.
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.
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.
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.
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 ;-)
There may be drawbacks to this I haven't thought of ;-)
0
Undo
Votes
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.
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.
0
Undo
Votes
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.
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 MIDI ASSOCIATION (TMA)
The community of people who work, play and create with MIDI
The community of people who work, play and create with MIDI
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
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
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.
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.
- Page :
- 1
There are no replies made for this post yet.
Be one of the first to reply to this post!
Be one of the first to reply to this post!
