More folks are raising a concern.
https://www.youtube.com/watch?v=Dykkjy7hEeo
https://discord.com/channels/1120956659825643520/1120956800905265242
Since a ZIP format what chosen, did MMA consider small processor designs that for example write/read from an SD card, (un)zipping will cause a lot of complexity for such devices that normally don't have support for compressing data or zipping/unzip files. Zip libraries may have bugs or become obsolete as well. it would be helpful to have a single file uncompressed container file format such like legacy MIDI 1.0 has.
Attached a proposal for binary file format. As you see this can be very simple.
I'd be interested in your thoughts around the DAW Project XML proposed by Bitwig that also uses ZIP as a container format (IIRC).
I'm also curious what container you are considering that can contan any number of media types? That most likely need to be stored as a number of files.
thanks 🙂
guess the Bitwig proposal is on higher level and scope than just MIDI. Why would a MIDI container file need to contain any other media than MIDI ?
Perhaps it takes such a long time to define the container spec because of the scope creep ? No need for video, audio, excel and powerpoint files in a container file IMHO. 🙂
> No need for video, audio, excel and powerpoint files in a container file IMHO
Then the MIDI Clip file should then be enough for this kind of simple use case, I would imagine?
I think the industry has certianly grown a lot from just using MIDI though, and various members want functionality that extends - especially in the area of notation.
Then the MIDI Clip file should then be enough for this kind of simple use case, I would imagine?
Not if you want just have multiple tracks stored in one simple file. Such MIDI clip container format could fit into the Bitwig DAW format.
IMHO, let the DAW and other larger application take the notation, sound, video and and other information from there.
For anyone interested, here is a editable MIDI container format proposal . This is not endorsed or proposed by MIDI.ORG.
https://docs.google.com/document/d/1x2_juMiRrwX0yrsbR_UMYrNWgLv92NUWuVFlV3n8Qzc/edit?usp=sharing
it an extremely simple format that could be transmitted over UMP to another UMP stream/device.
When it comes to binary representation... this might be better fitting with CBOR removed link (Concise Binary Object Representation) which also offers extension support when necessary (although maybe not needed for this use case that likely can fit within the CBOR basic data model).
Your `midi2bc` or `midi2bincon` might be written up in CDDL format (.cddl file) for better review and generating and validating instances programmatically.
I think in general that CBOR and CDDL should be used more when describing Midi 2.0 structures through binary representation. Graphics vendors and IoT vendors are already using it, so it makes sense for music devices as well.
A single MIDI Clip file <a href=" removed link " target="_blank" rel="noopener">alone is great for basic use, but for storing multiple tracks, you’d need a more complex format, ideally integrated into the Bitwig DAW.
The MIDI Container File specification is currently under development, with expected release in 2024.
that's less than 2 months left..:-)