fbpx


The MIDI Forum

  Monday, 12 June 2023
  6 Replies
  2.6K Visits
7
Votes
Undo
  Subscribe
First of all: thanks for the updated MIDI 2.0 specs!

M2-116-U_v1-0_MIDI_Clip_File_Specification.pdf (page 12) says the MIDI Clip File uses big-endian data formatting. Why is that? PC, Mac, iOS etc. are little-endian, so it seems like an odd choice.

Not saying it's wrong, just curious.
3 days ago
·
#19907
0
Votes
Undo
One downside to requiring big-endianness for clip files is that it means every implementer that uses native-endianness for its packets where "native" is little endian (which is the sweeping majority of contemporary computers) must byte-swap the packets as they are read. This also means you can't use zero-copy semantics to stream clip files, which eliminates memory-mapped file I/O (which is the lowest latency way to read bytes off disk into a program on modern computers).

It's also inconsistent with the UMP specification which allows implementers to choose their endianness. To be consistent the file format should support both little and big endian, perhaps by using different magic numbers. (`SMFCLIPB`, `SMFCLIPL`, just as an idea).

There is prior-art for this, for example ELF files (the executable format on many systems including Linux) embed their encoding into the magic number at the start of the file to allow for loaders to identify if its encoded in big or little endian format. This is actually a critical feature for allowing ELF files to be read/written on platforms where either read/write performance can be traded off (for example, writing a big-endian file on a little-endian system for a target architecture that is big-endian).

ELF file reference: https://man7.org/linux/man-pages/man5/elf.5.html
3 months ago
·
#18927
0
Votes
Undo
Hi, sorry to bother, did the specification for midi 2.0 files come out?

Hello Carlos. Check out the following articles on this midi.org site that were posted or updated around the beginning of this month (June 2023).

What Musicians & Artists need to know about MIDI 2.0
Details about MIDI 2.0, MIDI-CI, Profiles and Property Exchange (Updated June, 2023)

These articles announced several updated and new MIDI 2.0 specifications. One of the new specifications is about "MIDI Clip Files" which is like a MIDI 2.0 version of a MIDI 1.0 Format 0 Standard MIDI File (a single-track stream of MIDI events). That specification also mentions a "MIDI Container File" which will be like a MIDI 2.0 version of a MIDI 1.0 Format 1 Standard MIDI File (a multi-track file), but the specification for that format apparently isn't publicly released yet.

After those articles were posted, people have been reading the new specs and asking questions and discussing them on the forums here.
3 months ago
·
#18925
0
Votes
Undo
Hi, sorry to bother, did the specification for midi 2.0 files come out? :o :o :o
3 months ago
·
#18805
0
Votes
Undo
I did (do) have some implementation code for a UMP-based SMF alternative format in my MIDI 2.0 library, and it is also based on big endian. https://github.com/atsushieno/ktmidi/blob/main/docs/MIDI2_FORMATS.md

It is better than little endian when inspecting what we actually load the file on some binary editor, or in memory on some debugger. If everything is in big endian, then we can easily understand the UMP contents like `40 90 30 00 F8 00 00 00` as a MIDI 2.0 Note On message. It would have been `00 30 90 40 00 00 00 F8` if it were little endian (I found it quite annoying).

The same could go for Flex Data text messages (`EMOS` `IRTS` `\0SGN`).
3 months ago
·
#18786
0
Votes
Undo
OK, thanks for your answer.
It's a bit unfortunate that most if not all software that deals with the files will run on little-endian systems, so all UMP dwords have to be byte-reversed all the time.

Otherwise the file format seems nice and simple BTW :)
0
Votes
Undo
Historically, MIDI files have always used big endian, and this has always been the more common byte order for interchange and network protocols.
Giel set the type of the post as  Technical Question — 3 months ago
  • Page :
  • 1
There are no replies made for this post yet.