I am not a member of the MIDI Manufacturers Association, but here is my understanding of some of your questions:

[quotePost id=18835][2] 7.1.1: Any subsequent Set Tempo messages in the Clip Sequence Data should only occur where MIDI clocks would be located.
Please elaborate on that this practically means ? Should SetTempo always be joined with a MIDI clock message ?[/quotePost]
This statement is recommending that the time position of a Set Tempo message should match the time position of a Timing Clock message. When Timing Clock messages are used, they are sent at a rate of 24 Timing Clocks per quarter note. In other words, the statement is recommending the time position of a Set Tempo message should be some exact unit of 24ths of a quarter note.

If a MIDI playback device is sending Timing Clock messages* and sending Set Tempo messages** to the output MIDI device, and if the MIDI file is following the recommendation that the time position of a Set Tempo message should be some exact unit of 24ths of a quarter note, then when the player gets to the time position to send the Set Tempo message, I presume it will send a Timing Clock immediately followed by the Set Tempo message.

* More information about sending Timing Clock messages: Timing Clock messages are not stored in a MIDI file. However, the software or device that is playing the MIDI file may have a user-selectable setting to send Timing Clock messages to the output MIDI device. If that setting is enabled, the MIDI file player will insert Timing Clock messages into the stream of messages being played from the MIDI file at the rate of 24 Timing Clocks per quarter note.

** More information about sending Set Tempo messages: In MIDI 1.0, the Set Tempo meta event was not capable of being transmitted to an output MIDI device. (In a MIDI 1.0 Standard MIDI File, meta events are informational data that is only visible to the software that accesses the MIDI file, they are not MIDI messages that can be transmitted to a MIDI device.) In MIDI 2.0, the Set Tempo message is now a message that can be transmitted to an output MIDI device. I presume a MIDI file player may decide if it wants to send or not send Set Tempo messages to the output MIDI device, perhaps by providing a user-selectable setting to let the user decide if it should send them.

[quotePost id=18835][3] 7.1.2 Any subsequent Set Time Signature messages in the Clip Sequence Data should only occur at the time when one
bar ends (according to the previously set time signature) and the next bar begins with the new time signature
This time signature's DC must exactly match the time of the end of the bar (time of next bar) based on the time signature ?[/quotePost]
This statement is recommending that the time position of a Time Signature message should be at a time position where a new bar would begin.

In my experience with MIDI 1.0 MIDI file software, if you put a Time Signature message in the middle of a bar, some software will show that as a short truncated bar, but other software will delay the new time signature to the beginning of the next bar. When people are having a discussion about a MIDI file but they are using different software, it will be confusing to discuss the positions in the MIDI file because their software will use different bar:beat:tick position labels after the mid-bar Time Signature. To avoid this kind of confusion, the specification recommends a Time Signature should not be put in the middle of a bar.

For an example of a problematic MIDI 1.0 Standard MIDI File with a Time Signature in the middle of a bar, go to the following post Re: Midi File Problems, Does Anyone Know How to Fix This? and scroll down to the section "Time Signature in the middle of a measure".

Additional information about the Set Tempo time position recommendation: This recommendation also appears in the MIDI 1.0 Standard MIDI Files specification, along with an explanation of why it is recommended. From the Set Tempo description on printed page 9 (PDF page 11):

Set Tempo [...] Ideally, these events should only occur where MIDI clocks would be located — this convention is intended to guarantee, or at least increase the likelihood, of compatibility with other synchronization devices so that a time signature/tempo map stored in this format may easily be transferred to another device.

Thank you for the feedback. I wrote my own player back in the days that also inserted clocks to the device. The question was place here because as stated "Timing Clock messages are not stored in a MIDI file." and therefore would like to have clarification on this if this is now the case if UMP MIDI clocks (Section 7.8 UMP spec) are now in scope of the MIDI 2.0 file (unlikely) It may help to define which message could and which should/may/cannot not be in added a clip file in the clip data and in the configuration header , since as per the current clip spec , in theory, any UMP message could be inserted. The MIDI 1.0 spec clearly defined which events are part of an SMF file. (implicitly defining and which are not)

Any comments for these four question from the MIDI specification writers ?

[quotePost id=18835]
Using this post to discuss MIDI file questions

[1] UMP versus Clip file specification
The clip file specification (3.2) refers to "DCS" in text and graphs, but the UMP (7.2.3.2) specification refers to this is "DC". This seems inconsistent. The clip spec writes "stamp" as lower case as well.

[2] 7.1.1: Any subsequent Set Tempo messages in the Clip Sequence Data should only occur where MIDI clocks would be located.
Please elaborate on that this practically means ? Should SetTempo always be joined with a MIDI clock message ?

[3] 7.1.2 Any subsequent Set Time Signature messages in the Clip Sequence Data should only occur at the time when one
bar ends (according to the previously set time signature) and the next bar begins with the new time signature
This time signature's DC must exactly match the time of the end of the bar (time of next bar) based on the time signature ?

[4] 6.2.1 .The sequencer should perform this process those immediately upon loading the file
Should this requirement not be a bit relaxed and be before starting to play the clip ? Sequencer may load the file long before actual playing and devices get connected. In case device does not support the profile, it will be up the implementation of the the sequencer (DAW) to still play the data to the receiver or not, correct?

[5] When can the container file specification be expected ?
[/quotePost]

[1] Thanks for the catch. We have added this to our errata for a minor update to be published in the near future.

[2] This is true for SMF1 and SMF2: Most MIDI Files do not include MIDI Clock messages, although it is not prohibited. It is most often best not to include them. The sequencer generally calculates its clock based on a SetTempo command or the sequencer's own preferred tempo. But there is a specific times (1/24th of a quarter note) where MIDI Clock would be placed if included. SetTempo should be placed at that time. We might add a small clarification in a future revision.

[3] Yes

[4]a] We believe this rule is okay as stated. This is a "should", not a "shall" statement. The specification explains the difference between should and shall.
[4]b] Yes, it is up to the sequencer.

[5] I think the container file specification will not be published in less than 1 year from now. All work is done by volunteers, so schedule is just a guess.

Mike Kent
Chair of MIDI 2.0 Working Group

Dear Kent,

Thank your for the clarification

[6] Both the UMP and Clip file spec states: If no MIDI message has occurred during the previous 1,048,575 ticks, then the application which creates the MIDI
Clip File shall insert a Delta Clockstamp followed by a Null message to restart the delta time count. Then the next
Delta Clockstamp in the file declares the ticks since the previous Null message.
Where is the definition of this Null message documented ? Is it UMP NOOP or a DC with value zero ?

next batch:

[7] Time signature messages, should GROUP field be 1 and CHANNEL be 0 ? (in a CLIP file)

[8] Page 73, the copyright notice example uses STATUS bank 0, while the spec defines that copyright text must use STATUS bank 1

[9] 7.5.8 Chord name message, the FORMAT field is not defined. Should it be 1 ?

[10] 7.4.13 Registered Controller (RPN) for Sensitivity of Per-Note Pitch Bend . Would it not be clearer to move the clarification for index #7 under section 7.4.7.1 ? with all the other RPN messages (0 to 6) ?

[11] in MIDI 1 files, the channel clearly defines a different voice, In MIDI 2. there is additional of the field group. What would be the practical interpretation of GROUP in the context of clip files as the sequencer will select the GROUP / interface anyhow ? Could a clip file have messages for different GROUPS in the same clip ? if yes, would that mean that de message from GROUP x should be a interpreted as a different channel (voice) from GROUP Y even the channel number is the same ? Could a clip file have messages for different GROUPS in the different clip data ?

[12] The text states "In a Standard MIDI File, Set Tempo messages shall only occur at the timing of 1/24 of a 1/4 note" . Assume this means clip data (notes), though per the clip spec, the Set Tempo messages may also occur in the MIDI clip file configuration header. (section 6)

[13] In TEXT messages, should group be always "1" ?

[14] Page 80: The "number of valid bytes in this chunk" field is 16 bits. Does this means that the maximum payload is (much less) than 64KB (removing overhead)
If yes, this is would be very limited for firmware updates. Would it not be better to implement mixed data using the START / CONTINUE / END method which would allow for larger payload. Most manufacturers use SYSEX anyhow the send firmware and data like JSON,. Wondering what the use case is for this mixed payload. Now that there is also SYSEX8, it makes non-midi data even easier to transport over SYSEX.

[15] Was it given a thought to add a UMP checksum message ?. This would be handy to check if the data is valid, specially for firmware code.

[16] Mixed data uses the same type as SYSEX8 (0x5). But it is a very different type of message ?

[17] Message between START and END. UMP spec defines: The Sender shall not send any other Message or UMP on the same Group between the Start and End
Would it be allowed to have different GROUP messages between START and END messages (SYSEX & FLEX) in a clip file ?

[18] Could it be explicitly be defined which message should/must be used in a CLIP file, for example. Rules may have limitation but it could also clean up and simplify code:
MIDI-CI; SET PROFILE only
UTILITY: DC and DCTPQ only
SYSEX8: All
SYSEX7: All
SYSTEM: None
CHANNEL: All
FLEX: All

[6] I think this is the answer:
7.2.1 NOOP
A NOOP (no operation) message is provided in the Utility Messages Message Type, using opcode zero.

[6] Yeah, NOOP is what the specs intend to say I think.

There'd actually be no problem in simply having multiple consecutive DCs I think? The parser would recognize the DC and increase the tick counter.

I guess so too, though it would be better if the document explicitly defines it to take the guess out of it. For the moment simple a confirmation of the authors would suffice. Though adding a zero DC could be also an option, right?

Happy, I'm happy to answer a few questions here. But it seems like you are developer and you should join the MIDI Association for more access.

[7] Time signature messages, should GROUP field be 1 and CHANNEL be 0 ? (in a CLIP file)

Group field can be any Group. The time signature is common to a whole Group. A different Group may use a different time signature. Channel field is unused/ignored.

[11] in MIDI 1 files, the channel clearly defines a different voice, In MIDI 2. there is additional of the field group. What would be the practical interpretation of GROUP in the context of clip files as the sequencer will select the GROUP / interface anyhow ? Could a clip file have messages for different GROUPS in the same clip ? if yes, would that mean that de message from GROUP x should be a interpreted as a different channel (voice) from GROUP Y even the channel number is the same ? Could a clip file have messages for different GROUPS in the different clip data ?

Yes, a MIDI Clip File can contain data from more than a single Group. A MIDI Channel of value X in one Group is a different address from a MIDI Channel of same value X in a different Group. UMP Format has 256 MIDI Channels. Those 256 are organized into 16 Groups mostly for backward compatibility to MIDI 1.0 data format.

[12] The text states "In a Standard MIDI File, Set Tempo messages shall only occur at the timing of 1/24 of a 1/4 note" . Assume this means clip data (notes), though per the clip spec, the Set Tempo messages may also occur in the MIDI clip file configuration header. (section 6)

That rule does apply in a MIDI Clip File Header. Inclusion of a Set Tempo in the MIDI Clip File Header asserts the potential location of MIDI Clocks. That rule in the UMP & MIDI 2.0 Protocol specification is supported by the following rules in the MIDI Clip File specification:
“The Clip Configuration Header may contain a Set Tempo message as the first event following the DCTPQ message.”
“The Clip Configuration Header shall not include more than one Set Tempo message…”
In Figure 3 of the MIDI Clip File specification, you can see Set Tempo at DCS=0, which is the beginning of the first 1/24th of the following quarter note.

[13] In TEXT messages, should group be always "1" ?

No. Text messages can be unique for each Group and each Channel.

[14] Page 80: The "number of valid bytes in this chunk" field is 16 bits. Does this means that the maximum payload is (much less) than 64KB (removing overhead)
If yes, this is would be very limited for firmware updates. Would it not be better to implement mixed data using the START / CONTINUE / END method which would allow for larger payload. Most manufacturers use SYSEX anyhow the send firmware and data like JSON,. Wondering what the use case is for this mixed payload. Now that there is also SYSEX8, it makes non-midi data even easier to transport over SYSEX.

"number of valid bytes in this chunk" is not found on Page 80. It is on Page 81 and 82, so I assume you are asking about Mixed Data Set. Up to 65,535 Chunks may be in a Mixed Data Set. Each Chunk may have a payload of up to 65,535 bytes. Mixed Data Set supports huge payloads with a numbered chunk mechanism.

[17] Message between START and END. UMP spec defines: The Sender shall not send any other Message or UMP on the same Group between the Start and End
Would it be allowed to have different GROUP messages between START and END messages (SYSEX & FLEX) in a clip file ?

Yes.

Thank you for reply. wish to join, but unless I have a product ready to enter the market (*) that should provide ROI, it is a bit hard to justify such annual expense.
(*) SYSEX ID, USB VID:PID among other annual recurring fees

[6] Is it NOOP or Zero DC or remove the requirement for a a DCS preceding any message if the DC is zero. ?

[7], [11], [13] and [17] Should have added: "should the group be the same for messages between a START and END of a clip message event ?"

[12] I misinterpreted the spec. Thanks.

[14] Apologies, also here misread the document,. Now understand there can be multiple headers and messages are tieds together with the msdid.
Perhaps an illustration with multiple header would be nice
[14.1] VID and PID should be mandatory ? if, yes an application (DAW) may needs to get this from the device first.
Could think of a situation where two applications (local or external network) that wish to exchange data with each other.
[14.2] For all messages belonging to one DCS#, should group always be the same ?

[16] Found that it was much easier to code if the parsing of UMP data if the MIXED data had it's own ID.

[8], [9], [10], [15] OPEN

[18] Profile ID

Suggest remove the MIDI-CI set profile requirement from MIDI clip file . A host needs to perform all the (UMP) bidirectional MIDI-CI discover process anyhow to find out what profile are supported and can be used. Selecting a profile is optional of-course.

Created a discord server for MIDI (2.0) questions. Perhaps it fun for folks (member and non members) to exchange knowledge and ideas, though discord is not a great issue tracking tool. 🙂

MIDI on Discord

P.S The forum locks marks posts as spam very quickly once you make a few edits.

[19] Why does the Set Tempo message have a Group? Shouldn't the whole orchestra play in the same tempo?
What group should I specify in a MIDI file for the Set Tempo and alike?

Thanks!

[quotePost id=18965][19] Why does the Set Tempo message have a Group? Shouldn't the whole orchestra play in the same tempo?
What group should I specify in a MIDI file for the Set Tempo and alike?[/quotePost]

Yes, Set Tempo is per Group. If you have a MIDI File with data spanning multiple Groups. Then you should include a Set Tempo message for each of those Groups.