Hi,
I have been implementing support for the new UMP packets (Flex Data, UMP Stream, etc.) in my library and noticed some issues.
1. On Utility messages, there are Figure 32 for Examples of JR Timestamps and Figure 35 for Examples of Delta Clockstamped messages. Both data fields are sized as 20 bits, but I believe JR Timestamp has only 16 bits.
2. On Set Chord Name messages explained at 7.5.8, I noticed that those example messages at Figure 76 tell that their format is `1`, but those packets are complete in one UMP, so I believe they should be `0` instead.
3. On Lyric Data message (7.5.10) and Ruby Data message (7.5.12), there are some mentions like "Data Continue UMP (Format = 0x1), but according to 7.5.1 (Flex Data Messages General Format), Flex Data Message Continue UMP is `0x2`, just like other format/status.
4. I am skeptical on how Lyric and Ruby messages are interpreted: what if our lyric packet is COMPLETE in one UMP, AND contains a "melisma" `00h` ? How should we represent such a lyric packet without adding extra letters to make it expanded to another packet? Unless I have missed something, there is no way to achieve that.
For potentially better understanding, I have created an example test case for #4 issue above to my library, at: https://github.com/atsushieno/ktmidi/blob/1fe8bf214/ktmidi/src/commonTest/kotlin/dev/atsushieno/ktmidi/UmpFactoryTest.kt#L439
I have been implementing support for the new UMP packets (Flex Data, UMP Stream, etc.) in my library and noticed some issues.
1. On Utility messages, there are Figure 32 for Examples of JR Timestamps and Figure 35 for Examples of Delta Clockstamped messages. Both data fields are sized as 20 bits, but I believe JR Timestamp has only 16 bits.
2. On Set Chord Name messages explained at 7.5.8, I noticed that those example messages at Figure 76 tell that their format is `1`, but those packets are complete in one UMP, so I believe they should be `0` instead.
3. On Lyric Data message (7.5.10) and Ruby Data message (7.5.12), there are some mentions like "Data Continue UMP (Format = 0x1), but according to 7.5.1 (Flex Data Messages General Format), Flex Data Message Continue UMP is `0x2`, just like other format/status.
4. I am skeptical on how Lyric and Ruby messages are interpreted: what if our lyric packet is COMPLETE in one UMP, AND contains a "melisma" `00h` ? How should we represent such a lyric packet without adding extra letters to make it expanded to another packet? Unless I have missed something, there is no way to achieve that.
For potentially better understanding, I have created an example test case for #4 issue above to my library, at: https://github.com/atsushieno/ktmidi/blob/1fe8bf214/ktmidi/src/commonTest/kotlin/dev/atsushieno/ktmidi/UmpFactoryTest.kt#L439
Atsushi
set the type of the post as
Technical Question — 3 months ago
4. I am skeptical on how Lyric and Ruby messages are interpreted: what if our lyric packet is COMPLETE in one UMP, AND contains a "melisma" `00h` ? How should we represent such a lyric packet without adding extra letters to make it expanded to another packet? Unless I have missed something, there is no way to achieve that.
I am also confused about how a melisma is supposed to work, take a look at my post from about a day and a half ago: MIDI 2.0 Lyric Data Message - Melisma questions
0
Undo
Votes
Hi I'll try to answer as best I can 
I believe the example should have been 16 bits in Figure 32 (good spot ). Figure 35 is correct.
I believe you are correct.
Again I believe you are correct.
These points (and your other question, which I don't have the expertise on) will be taken to the Working Groups for review - thanks for the feedback!
1. On Utility messages, there are Figure 32 for Examples of JR Timestamps and Figure 35 for Examples of Delta Clockstamped messages. Both data fields are sized as 20 bits, but I believe JR Timestamp has only 16 bits.
I believe the example should have been 16 bits in Figure 32 (good spot
). Figure 35 is correct.2. On Set Chord Name messages explained at 7.5.8, I noticed that those example messages at Figure 76 tell that their format is `1`, but those packets are complete in one UMP, so I believe they should be `0` instead.
I believe you are correct.
3. On Lyric Data message (7.5.10) and Ruby Data message (7.5.12), there are some mentions like "Data Continue UMP (Format = 0x1), but according to 7.5.1 (Flex Data Messages General Format), Flex Data Message Continue UMP is `0x2`, just like other format/status.
Again I believe you are correct.
These points (and your other question, which I don't have the expertise on) will be taken to the Working Groups for review - thanks for the feedback!
Hello Andrew! Can you also bring up my melisma questions to the Working Group -- they're different from Atsushi's point 4 above. See my post: MIDI 2.0 Lyric Data Message - Melisma questions
0
Undo
Votes
Hello Andrew! Can you also bring up my melisma questions to the Working Group -- they're different from Atsushi's point 4 above. See my post: MIDI 2.0 Lyric Data Message - Melisma questions
Yes I will
4. I am skeptical on how Lyric and Ruby messages are interpreted: what if our lyric packet is COMPLETE in one UMP, AND contains a "melisma" `00h` ? How should we represent such a lyric packet without adding extra letters to make it expanded to another packet? Unless I have missed something, there is no way to achieve that.
For potentially better understanding, I have created an example test case for #4 issue above to my library, at: https://github.com/atsushieno/ktmidi/blob/1fe8bf214/ktmidi/src/commonTest/kotlin/dev/atsushieno/ktmidi/UmpFactoryTest.kt#L439
Atsushi,
Thank you for bringing us these issues. Andrew already answered on your first 3 questions. We will fix these and other errata in forthcoming minor revision to specifications.
Our Melisma Event definition in the specification has several issues. We are already working on a revised definition to be released soon. We are creating an example MIDI Clip File which we can send to you when it is ready.
Mike Kent
Chair of MIDI 2.0 Working Group
A new version of the M2-104-UM Universal MIDI Packet (UMP) and MIDI 2.0 Protocol specification, version 1.1.1, addresses some of these topics. It is now available here: https://midi.org/specifications/midi-2-0-specifications/midi2-core
Thanks,
Mike.
Thanks,
Mike.
- Page :
- 1
There are no replies made for this post yet.
